Title: Quick Cache problem
Last modified: August 21, 2016

---

# Quick Cache problem

 *  Resolved [wpconvert](https://wordpress.org/support/users/wpconvert/)
 * (@wpconvert)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/)
 * Hi
 * I’ve just encountered a problem (although I don’t know why it’s occurring all
   of a sudden as everything has been working fine).
    The first symptom was that
   my latest posts thumbnails (using timthumb) were not displaying – this led me
   to discover that Quick Cache was not able to cache the files, giving an error
   in the page source <!– Quick Cache: failed to write cache, unable to obtain a
   mutex lock at the moment. Quick Cache will try again later. –> as opposed to 
   the usual success message.
 * If I enable default .htaccess and clear the cache, caching works again as expected.
   As soon as I re-enable bulletproof mode, Quick cache fails to write to the cache
   resulting in the above error message.
 * Does this make any sense? Understanding that Quick Cache has not been supported
   for some time (though it still seems to work weel) – perhaps I should update 
   to Supercache or similar?
 * Thanks for your help
 * [http://wordpress.org/plugins/bulletproof-security/](http://wordpress.org/plugins/bulletproof-security/)

Viewing 7 replies - 1 through 7 (of 7 total)

 *  Plugin Author [AITpro](https://wordpress.org/support/users/aitpro/)
 * (@aitpro)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299050)
 * 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](https://wordpress.org/support/users/aitpro/)
 * (@aitpro)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299055)
 * 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.
 *  Thread Starter [wpconvert](https://wordpress.org/support/users/wpconvert/)
 * (@wpconvert)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299124)
 * 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.
 *  Thread Starter [wpconvert](https://wordpress.org/support/users/wpconvert/)
 * (@wpconvert)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299126)
 * 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](https://wordpress.org/support/users/aitpro/)
 * (@aitpro)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299132)
 * 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](https://wordpress.org/support/users/aitpro/)
 * (@aitpro)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299133)
 * There is a solution for the FastCGI problem, but it would require that the Host
   make the Server config change explained in the link below.
 * [http://www.ait-pro.com/aitpro-blog/4349/misc-projects/wordpress-tips-tricks-fixes/php5-3-x-php5-4-x-user-ini-file-does-not-work-known-php5-3-x-user-ini-fastcgi-wordpress-zend-issue/](http://www.ait-pro.com/aitpro-blog/4349/misc-projects/wordpress-tips-tricks-fixes/php5-3-x-php5-4-x-user-ini-file-does-not-work-known-php5-3-x-user-ini-fastcgi-wordpress-zend-issue/)
 *  Thread Starter [wpconvert](https://wordpress.org/support/users/wpconvert/)
 * (@wpconvert)
 * [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299139)
 * 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.

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘Quick Cache problem’ is closed to new replies.

 * ![](https://ps.w.org/bulletproof-security/assets/icon-128x128.png?rev=1731938)
 * [BulletProof Security](https://wordpress.org/plugins/bulletproof-security/)
 * [Support Threads](https://wordpress.org/support/plugin/bulletproof-security/)
 * [Active Topics](https://wordpress.org/support/plugin/bulletproof-security/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/bulletproof-security/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/bulletproof-security/reviews/)

## Tags

 * [thumbnails](https://wordpress.org/support/topic-tag/thumbnails/)

 * 7 replies
 * 2 participants
 * Last reply from: [wpconvert](https://wordpress.org/support/users/wpconvert/)
 * Last activity: [12 years, 7 months ago](https://wordpress.org/support/topic/quick-cache-problem/#post-4299139)
 * Status: resolved