Your Members and Caching

One of the questions that keeps cropping up is does Your Members work with caching plugin X. Unfortunately, answering it requires people to understand more about what caching plugins do and how Your Members handles it.

TLDR version

We suggest you look carefully to see if you require caching in the first place, if you do we first suggest simply offsetting files to a CDN. If you need some form of object/page caching then you have to be careful when setting up and be aware problems could exist!

• Disable caching of database and objects for logged in users
• Disable caching of any sort on your wp-login.php
• Surprisingly even if you have don’t cache logged in users, several plugins still cache the user object as it’s being created on login. Which will cause issues with registration
• Make sure no caching is being done on http://www.example.com/?ym_cron_do=1 and http://www.example.com/wp-cron.php
• Disable caching when creating packages or any registration based modifications and flush cache when restarting

What is caching?

Caching comes in two flavours; browser caching (which most people have heard of, occasionally to fix a glitch you might be asked to “clear your cache”) this is where the users’ browser stores files locally so it doesn’t have to ask the server for the page contents, instead it asks for content that may have changed. Server caching (Database and Object/Page Caching) does something very similar, but instead of it being a browser talking to the server, it’s the server talking to the database or to PHP itself. These are known as database and object caching. Often when dealing with caching plugins they will also include file caching, normally this is not true caching but rather offsetting the HTTP connections by moving files to another server called a CDN. This type of offsetting is very effective and moving your theme assets to a CDN will see a massive performance hike with almost no drawbacks (barring financial that is).

So why does Your Members have an issue?

When a user visits a page or performs an action the server, when it has a caching plugin enabled, will look and see if there is a cached version of the page or action (such as returning a list of posts). If there is, instead of making database calls it will simply return what’s in the cache. If there isn’t anything in the cache it will call the database or object, and when the data is returned it will show it to the user and store it in the cache so it’s there for the next person.

Now imagine we have two YM users one is under the basic package and another the premium package, both visit the page but both should see different content. If caching is not configured properly both users will see the same content, as both would get the version stored in the cache even though they should be seeing different content!

Why is this happening?

The current WordPress plugins were never really designed with the idea of interactive users, instead they are meant to offset a lot of visitors hitting your site. The assumption is the visitors will see one thing and so try where possible to reduce the number of queries made. This doesn’t just effect Your Members or WordPress Membership plugins, but any plugin where a visitor or user should see something that’s unique (geo-targetted adverts via a plugin like adApere for example).

How do you solve members being cached?

First off, see if you should be using caching. While anyone researching the subject will find a wealth of commentary about the need for caching, in the vast majority of cases caching is not needed. Most caching articles assume you are trying to protect from traffic spikes, on a fairly static WordPress site. While every site is unique, most membership sites have a continual level of traffic meaning the server they are using will be correctly proportioned to any load. Cleaning out unused plugins (including YM modules you are not using) will also have a noticeable effect on performance. As will looking at well optimised themes. Look for themes which use the Transient API and who have been designed for WordPress 3+. Next rather then looking at caching Database and Objects first look to offset file assets via a CDN (MaxCDN seems to be everyone favourite choice including ours recently). If you can try to manage without object or database caching.

We cannot survive without it!

If you are still hit by performance woes then you’re next step should be looking at how your server is setup. Normally if using file caching, when the file assets are offset the issue is more likely to be not enough RAM or to many simultaneous connections to your database server. If you are on a shared DB you might wish to look at moving away. Also discuss with your host what other performance improvements they can make, including changes to your database server configuration.

“It’s no use we need to cache the DB and objects!”

This is the stage we recommend clients look at new hosts. However if you must cache database and PHP objects then we recommend the following:

• Disable caching of database and objects for logged in users
• Disable caching of any sort on your wp-login.php
• Surprisingly even if you have don’t cache logged in users, several plugins still cache the user object as it’s being created on login. Which will cause issues with registration
• Make sure no caching is being done on http://www.example.com/?ym_cron_do=1 and http://www.example.com/wp-cron.php

In addition disable caching when updating plugins (not just YM) even with the above you may still have issues and it’s important to test before putting caching live. You may also find issues occur when editing or creating packages, where the package doesn’t show or packages vanish all together it’s important to turn off caching while editing packages and when you restart to flush the object cache.

Summary

While caching is an effective way to gain performance boost on a WordPress site, it is not designed to be used with sites running personalised content delivery, so you may run into issues.

So to recap here are a few do’s and don’ts when it comes to caching and Your Members:

• Do worry about performance
• Do use a CDN to offset files and theme assets
• Do clean out plugins not active, and minimise plugin use including YM modules
• Do talk to your host about server settings and DB server settings
• Don’t object cache or DB cache logged in users
• Don’t cache the wp-cron.php and ?ym_cron_do=1 pages
• Don’t cache the wp-login.php page
• Turn of Caching when editing Packages or users

If you are having issues with caching do report them on the forum and the team will be happy to help.

If you are having strange issues with users reporting wrong content/blocked access and have caching enabled, please try disabling caching before reporting the issue.

Caching Update

Since this article we have had a range of interesting issues for up to date list of “problems” visit our forum.