WpW: Conflict-free Cookies and Tags on Multi-app Sites
Welcome to another installment of WordPress Wednesday!
Today we’re going to discuss the conflicts that arise on multi-app sites, specifically login vary cookie conflicts, and cache tag conflicts. These issues can pop up when you have multiple-WordPress installations with the LSCache plugin enabled on the same root (as in www.example.com/ and www.example.com/store).
We’re going to be focusing on WordPress for this article, but you can sometimes see these types of conflicts with other apps that have LSCache enabled (Magento and XenForo, for example). If you want to know more about cookie and tag conflicts involving multiple types of applications, this wiki will point you in the right direction.
Let’s look at a WordPress blog installed at www.example.com and a separate WordPress storefront installed at www.example.com/store. This is our current example, but be aware that the same concepts will apply to any situation where one (or more) WP sites is installed in a subdirectory of any other WP site.
Here are two possible problems you can have:
- Login Vary Cookie Conflict: A page may be served from cache when it shouldn’t be.
- Purge Tag Conflict: Pages may be purged from cache when they shouldn’t be.
Let’s chat about both of these scenarios, what causes them, and how to fix them.
Mmmmm. Login Vary Cookies.
Before we explain how to fix this problem, it’s handy to understand how this is all supposed to work.
As of this writing, LSCache for WordPress will only cache and serve pages for non-logged in users. (Remember this. It’s important.) This behavior is controlled by a vary cookie called _lscache_vary. Once users have logged in, the cookie is set, and their page requests will always be processed by WordPress. The pages they visit will not be cached, nor will cached pages be served to them.
You can see why it’s important, then, for the _lscache_vary cookie to be set correctly. It’s the key to determining which users get pages served from cache, and which users get pages through WordPress.
Ok, so let’s say your domain serves Example Blog at www.example.com/ and Example Store at www.example.com/store/, which is a subdirectory of Example Blog. If you log into Example Blog, the _lscache_vary cookie will be set to indicate that you are logged in, and your requests will not be cached. They will always be sent to the WordPress backend. This is normal behavior.
You then visit Example Store without logging in. Since you are a non-logged in user, LSCache steps up and caches the page you requested. This is also normal behavior. However, the logged in _lscache_vary cookie is still set from your visit to Example Blog, and so this page is cached for logged-in users . Uh oh. This causes future logged-in Example Store users to get a “cache hit” on this page and be served the non-logged in version of the page. This is decidedly not normal behavior.
Besides the fact that logged-in users are now being served cached pages (which they should not be), they are being served the non-logged-in versions of those pages (which is also wrong).
Why does this happen?
Think about it from the browser’s point of view. As far as the browser is concerned, Example Blog (www.example.com/) and Example Store (www.example.com/store/) are the same website because the store is actually a subdirectory of the blog. When the browser visits either one of those addresses, it will use the cookies for www.example.com. Even though the store is an entirely separate WordPress application, to the browser it looks simply like a part of the blog.
How can we fix it?
We need to tell the browser to use distinct cookies for Example Blog and Example Store. This requires a simple change within the LSCache plugin settings.
By default, the cache will use _lscache_vary as the login cookie in any WordPress installation. We can avoid conflicts by renaming some of the cookies. Any place where we have one WordPress installation in a subdirectory of another WordPress installation, we will need to set unique cookie names.
So for our two-app scenario, you could log in to the WP-Admin panel of Example Blog, navigate to LiteSpeed Cache > Settings > Advanced Settings, and set Login Cookie to _lscache_vary_blog (or whatever you would like it to be).
You could then do the same in Example Store’s WP-Admin panel and set Login Cookie to something different, like _lscache_vary_store. (Technically, you don’t need to change both cookie names, because the act of changing just one of them has already given you two unique cookie names. For example, if you only change the cookie on Example Store, you’d have _lscache_vary and _lscache_vary_store.)
If you had more installations running off of this same root, you’d want to repeat this process for all of them.
Achievement unlocked: eliminate login vary cookie conflicts!
Cache Tag Prefix
—
September 2017 UPDATE: in the latest versions of LSCache, this is no longer an issue. Cache Tax Prefixes are automatically generated and given a unique string for each installation, thereby eliminating the possibility of conflicts. We’re keeping the information in this section for historical reference, but this is not an issue you should encounter anymore.
—
Here is another problem you may run into when you have Example Blog and Example Store running together on www.example.com: excessive purging of the cache.
Note: This is not relevant for a single multi-site WordPress install. This issue only occurs in two (or more) distinct WordPress installations that happen to use the same cache root.
So here’s the issue: LSCache for WordPress has a default cache tag prefix of b1_, and this is the same on every WordPress instance you install. In addition to being a prefix, every page is also cached with the tag b1_ to denote that it belongs to that blog. The cache tag is used to inform LSCache which pages to purge from cache. So, for instance, in a situation where you might want to purge your entire Example Blog from cache, and you press that button, LSCache interprets the command as “purge everything with the cache tag b1_” and out goes your entire Example Blog cache (which you wanted) and your Example Store cache as well (which you did not want), because it also has the b1_ tag.
To solve this, you need to give all of your sites unique custom Cache Tag Prefixes in the same Advanced settings screen as before.
For Example Blog, you could set it to b, and for Example Store, set it to s. Those strings would then be added to the beginning of the relevant app’s cache and purge tags. A command to purge Example Blog would then be interpreted as “purge everything with the cache tag b_b1_. ” Example Store would be left alone, because its purge tags begin with s_b1_ .
Achievement unlocked: eliminate cache purge conflicts!
In a nutshell…
Using LiteSpeed Cache on your WordPress (and other) sites can lead to dramatic improvements in performance, so it pays to spend a minute or two working out little kinks like these! For more information on how to deal with cookie and tag issues as they relate to apps other than WordPress, take a look at our wiki articles .
—
Have some of your own ideas for future WordPress Wednesday topics? Leave us a comment!
Don’t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:
- Subscribe to the WordPress Wednesday RSS feed
- Download LiteSpeed Cache for WordPress plugin
- Learn more about the plugin on our website
Comments