Top Nav

W3TC CDN – Updating Plugin Or Theme

If you’re using W3 Total Cache with an origin push CDN like RackSpace Cloud Files, then you may encounter problems when updating plugins or themes. After the new files are synced to the CDN there is a propagation delay before all nodes receive the new files. During this time the site may be broken for some users. Here’s a procedure to deal with this situation:

1. Install and activate the new plugin or theme.

2. In W3TC, syncronize the Custom files to CDN. (Performance -> CDN -> Upload Custom Files)

3. Add plugin or theme folder to the CDN exclusion list:

Performance -> CDN -> Rejected Files

Add this line:




4. Save and clear the page cache.

Now the site will pull the plugin or theme from the server instead of the CDN. But the new files will be propagating through the CDN.

5. In 24 hours or whatever the TTL for your CDN container, after the files have had a chance to propagate, remove the plugin or theme folder from the Rejected Files list and clear the page cache.

Now the site will pull the plugin or theme from the CDN.


Updating W3TC Media Query String In WordPress Clusters

W3 Total Cache includes a feature to append a “media query string” to end of Javascript and CSS stylesheet URLs. By selecting “Performance -> Update Media Query String”, the WordPress admin can force the media query string to change. This in turn causes browser to fetch new copies of the JS and CSS files. This is very useful when browser caching is turned on with a long Expires value. Instead of waiting for the Expires timeout for a new change to become visible, the admin can force the change immediately.

But problems arise in a clustered environment with multiple web servers. The update works on the master server but the change is not reflected on slave servers. Here’s why:

  1. W3 Total Cache generates the media query string from the browsercache.timestamp configuration value which is stored in wp-content/w3tc-config/master.php.
  2. To optimize performance, W3 Total Cache stores a parsed copy of the master.php file in wp-content/cache/config/master.php.
  3. Typically we exclude wp-content/cache from replication to slave servers as the cache folders can be very deep and slow replication.
  4. When the media query string is updated the slaves do not know that they need to regenerate the cached version of master.php.

In fact this problem occurs with any config change to W3 Total Cache. The changes will not be seen on slave servers unless the wp-content/cache/config/master.php file is deleted.  After deletion the next request will regenerate the file with the new settings.

In our sync script we use a line like this to clear the config if needed:

No each time the sync script runs, if the W3 Total Cache config has changed then the cached copy will be deleted and regenerated on the next request.



Fixing CORS Issues With RackSpace Cloud Files CDN, W3 Total Cache and WordPress

A resource makes a cross-origin HTTP request when it requests a resource from a different domain than the one from which it was served.  For example, an HTML page served from makes an <img> src request for Many pages on the web today load resources like CSS stylesheets, images and scripts from separate domains.

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. The solution to allowing cross-origin requets is the new Cross-Origin Resource Sharing (CORS) mechanism.

If makes a scripted request for then the server hosting must include an “Access-Control-Allow-Origin” header. This header signals to the browser that it is ok to use the resource. The value of the header can be “*” which allows requests from all domains or it can be the name of an individual domain like “”.

If you’re using WordPress with the W3 Total Cache plugin to host static content on RackSpace Cloud Files, then you may need to add the Access-Control-Allow-Origin header to the object in Cloud Files. Let’s take an example … maybe your theme use a font at:


After you’ve activated the CDN features in W3TC, you may notice that myfont.woff is not loading and you’ll see an error in the console log in your browser indicating the cross-origin problem. The solution is to:

a. Login to

b. Go to Storage -> Cloud Files and drill down to the file in question

c. Click the gear icon next to the files and select “Headers”

d. Add the “Access-Control-Allow-Origin” header with a value of “*”.

e. Wait a little while for the change to propagate.

Now your font should load without problems.



Turn off Keep-Alive for directory

Recently had a problem where Chrome browsers were not fully downloading a large PDF document. The first few 100KB would download but then the document would stop loading.

After some debugging we concluded that Keep-Alive in Apache was creating the problem. We didn’t want to disable KeepAlive for the entire server so instead we added this line to the .htaccess file containing the PDF files:




Mysqldump TRIGGERS Only

Here’s the command to dump the triggers and stored procedures for a database: