Plugin Author
AITpro
(@aitpro)
I am not aware of any problems with BPS and Quick Cache. Are you using any additional custom .htaccess code besides the standard BPS .htaccess code? I will retest Quick Cache today and see if I find any issues.
Plugin Author
AITpro
(@aitpro)
I tested Quick Cache and do not see any errors or problems. I also tested the Mutex File Locking option with Semaphore and Flock and did not see and errors or problems.
The timthumb image problem may be another problem altogether. Check your BPS Security Log and post an error that is directly related to a timthumb image file. Most likely a skip/bypass rule needs to be added or if the timthumb file name is not whitelisted then it would need to be whitelisted. All of this information will be logged in the BPS Security Log file.
Hi AITpro
As always – I have to commend your support for this plugin. Prompt responses and going that extra mile to test various scenarios to deliver a qualified solution.
You were quite right, the Timbthumb / Quick Cache issue seems to have been a result of something in the custom .htaccess code.
After removing all custom code – everything seemed to operate as expected. I added bits of the custom code back – and the problem appears to have been with the gzip code:
# BEGIN Gzip enable
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>
#END Gzip enable
.htaccess file without this code works as expected.
The bizarre thing is that this started happening out of the blue – nothing has been changed and this has been working for months and months without a problem?
Anyway – problem now solved and was NOT an issue with Bulletproof security – still one of the plugins that I rely on the most.
Thanks again for your time in testing and supporting the plugin.
Just a quick update.
In fact – the problem was with PHP 5.4.17 – not the gzip code (this line had made it into the gzip code earlier and I hadn’t noticed).
Rolling back to 5.2.7 got everything working.
Out of interest, although using the gzip code in .htaccess does reduce initial page size – Pingdom reports the website loading consistently faster without it (average of 1.4 seconds for 1.7MB page) as opposed to average 1.6 – 1.8 seconds for 1.5MB page with it – so that was a revelation…
Clearly, Quick cache on my host with PHP 5.4.17 does not play well (all of a sudden). Perhaps it’s time for a change after all – although caching seems to be introducing more problems than it solves!
Thanks again.
Plugin Author
AITpro
(@aitpro)
A logical guess would be that PHP5.4.x has FastCGI bundled into it. FastCGI in general does not play nice with WordPress or any php applications. We are still using PHP5.2.x on all our sites since upgrading to PHP5.3.x or higher would mean we would have to use FastCGI bundled into those php versions. We did extensive testing and the results were things like this – site intermittenly hang for several seconds – intermittent 500 Internal Server errors and other undesirable things. At some point PHP5.2.x will no longer be available so we are really not sure what we will do when that time comes. 😉
Plugin Author
AITpro
(@aitpro)
Thanks again for the detailed response – I have mentioned this to the host (who are actually very good). Maybe it’s something that they haven’t implemented yet? They do specialise in WordPress hosting though…
A new version of Quick Cache should be released in the near term, apparently – I’ll give that a go before considering Supercache or similar (I’ve read some pretty alarming things recently regarding Supercache).
Thanks again.
