This page is dedicated to fixing w3 total cache errors. It’s full of so many errors that I’ve decided to dedicate one page to list almost all of them so that those who’re searching for it can find some fix.
Fixing w3 total cache errors on Nginx
Before proceeding, if you’re having w3 total cache errors on nginx server make sure:
- you have nginx.conf file generated by w3 total cache (after saving settings) in your websites root directory
- your nginx server configuration for current site have included this root folder configuration file
1. Recently an error occurred while creating the CSS / JS minify cache: Url/Filename is too long: 5/dashicons.min. Max length is 5.
This error was found on one of the sites using w3 total cache with configuration:
Legend Installed
: Functionality will work properly.Not detected
: May be installed, but cannot be automatically confirmed.Ok
: Current value is acceptable.Yes / No
: The value was successful detected. Server Modules & Resources: Plugin Version: 0.9.4.1 PHP Version: 5.4.35; Web Server: nginx FTP functions: Installed (required for Self-hosted (FTP) CDN support) Multibyte String support: Installed (required for Rackspace Cloud Files support) cURL extension: Installed (required for Amazon S3, Amazon CloudFront, Rackspace CloudFiles support) zlib extension: Installed (required for compression support) Opcode cache: Not installed Memcache extension: Installed HTML Tidy extension: Not installed (required for HTML Tidy minifier suppport) Mime type detection: Installed (Fileinfo) (required for CDN support) Hash function: Installed (hash) (required for NetDNA / MaxCDN CDN purge support) Safe mode: Off Open basedir: Off zlib output compression: Off set_time_limit: Available Additional Server Modules New Relic PHP version: Supported Operating System: Supported Web Server: Supported WordPress Resources /home/checksfun/public_html/nginx.conf: OK /home/checksfun/public_html/wp-content: OK /home/checksfun/public_html/wp-content/uploads/2014/12: OK Fancy permalinks: /%postname%/ WP_CACHE define: Defined (true) URL rewrite: Enabled Network mode: No
Server was a dedicated server with some 24gb ram
OS: CentOS release 6.5 (Final)
Error was because: gzip
wasn’t installed on the server.
How to check if gzip is enabled or not via PHP / WordPress
You can check if gzip is enabled on your server or not via PHP in WordPress by adding <?php phpinfo(); ?>
WordPress theme file or somewhere (make sure it’s not a production site as it’ll be shown to all visitors) or you can make it secure by showing to admins only by using: if(is_admin()){ phpinfo(); }
. This will show the phpinfo to admin on frontend on which ever page you’ve added it to in theme files.
Search for “gzip” in the output of phpinfo(); and you’ll see if it’s turned on or not.
Another way is by using:
<?php if(function_exists('ob_gzhandler') && ini_get('zlib.output_compression')){echo "available";} ?>
It will show “available” message if both gzip and zlib.output_compression is available. You can check one of them at a time if it fails.
After checking that gzip is enabled, still it gave error on this server though, saying:
Minify Auto encountered an error. The filename length value is most likely too high for your host. It is currently 150. The plugin is trying to solve the issue for you
But after saying “solving” for a while it fails without anything.
Solution to this was in this particular case was to goto: w3 total cache settings (Performance) > Minify settings (main page for minify from left menu) and:
- disabling the first option: Rewrite URL structure
- in advance section : select:
- and give value to 200 for filname length
Clear all cache from main page for w3tc and check the frontend.
3. Everything works fine except “Rewrite URL structure” in minify
I was working on a clients site and everything worked fine with them while I was configuring w3 total cache, except that whenever I enabled “rewrite url structure”, boom! everything broke!
I checked nginx access logs for that domain and they showed a 404 for the file being called.
Upon long and tedious investigation and testing, solution was to:
- create w3tc folder in wp-content directory
- make cache folder 777 (not the content inside it)
- make w3tc-config 777 (not the content inside it)
- give these and all folders ownership of www-data
- restart nginx (don’t forget this one)
- and voila!
Let me know if it didn’t work, you don’t know how to do any of the steps in it.
Let me know if you still have issues and we’ll fix it for you.