Top Nav

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.