Over the last few weeks I have been helping with the rather splendid Mr Spooner’s blog.spoongraphics.co.uk. Aside from the obvious problems with database load on such a high traffic website, cache was also playing a big part in problems. Cache is a very important tool in any database driven application, but it must always be used with caution. For those who do not know what cache is, simply it is a way of keeping commonly used content in its short term memory. Imagine every time you had to look for your phone, keys, wallet, etc. you would have to hunt them down around the house. The house is your database and doing this each time you need it takes a lot of time, so cache is in effect your bag/pockets. Cache allows you to keep comments, content and even objects such as images in the faster loading memory. This keeps the page load down, server queries and resources down and smoothes out the process when a higher load is on the server.
This all sounds rather good, and it is! However, setting the cache to only work on certain rows will increase the efficency of the cache usage and solve some problems in the long run too.
Chris’ blog encountered a problem that when a member had signed up using the Wishlist Member plugin, they would not be able to complete the join as the cache was running. This meant that any writes to the database would not be available to the user. This is a common problem and surprisingly very little written about.
As some of you probably found this via google (eventually?!) I’ll cut to the chase below:
To fix the W3 Total Cache and Wishlist Member plugins, use the following rules.
In your admin area, follow through to your cache settings and click into the settings for database cache. There should then be a box for entering the name of query stems you don’t want cached, as a rule of thumb, the following is worth putting in. The names may not the same as what you may see as you should have a prefix such as wp_xxxxx simply, if needed add the prefixes you use. This should now fix your woes.
On another note, if you are using the WP_ prefixes, it may be beneficial to move away from the default wp_ as it is a small security hole if someone is trying to tinker with your site.
I hope this helps anyone who has encountered this problem.