Archive | Web

Add this code to wp-config.php to stop redirect loops caused by SSL termination on a proxy or load balancer:

WP-CLI is a great tool for managing WordPress sites from the command line. As an example you can quickly change a WordPress user’s password with WP-CLI. This can be very handy on sites that you don’t have a WordPress admin login. First, if you don’t already have WP-CLI installed then follow the instructions here:

http://wp-cli.org/#installing

Then “cd” to the root of the WordPress site and run the following command:

Where <user> is the username and <pass> is the new password.

Here’s an example:

You can actually update other user parameters with the “user update” sub-command. See the full docs here:

http://wp-cli.org/commands/user/update/

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:

{plugins_dir}/plugin_folder

or

{wp_content_dir}/themes/theme_folder

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.

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.