{"id":7199,"date":"2017-06-07T06:00:48","date_gmt":"2017-06-07T10:00:48","guid":{"rendered":"http:\/\/blog.litespeedtech.com\/?p=7199"},"modified":"2017-06-07T06:00:48","modified_gmt":"2017-06-07T10:00:48","slug":"wpw-conflict-free-cookies-and-tags-on-multi-app-sites","status":"publish","type":"post","link":"https:\/\/lswp.store\/index.php\/2017\/06\/07\/wpw-conflict-free-cookies-and-tags-on-multi-app-sites\/","title":{"rendered":"WpW: Conflict-free Cookies and Tags on Multi-app Sites"},"content":{"rendered":"

\"\"<\/p>\n

Welcome to another installment of WordPress Wednesday<\/a>!<\/p>\n

Today we\u2019re going to discuss the conflicts that arise on multi-app sites, specifically login vary cookie conflicts, and cache tag conflicts<\/strong>. These issues can pop up when you have multiple-WordPress installations with the LSCache plugin<\/a> enabled on the same root (as in www.example.com\/<\/code> and www.example.com\/store<\/code>).<\/p>\n

We\u2019re 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<\/a> will point you in the right direction.<\/em><\/p>\n

Let\u2019s look at a WordPress blog installed at www.example.com<\/code> and a separate WordPress storefront installed at www.example.com\/store<\/code>. This is our current example, but be aware that the same concepts will apply to any situation where one (or more) WP sites is\u00a0installed in a subdirectory of any other WP site.<\/p>\n

Here are two possible problems you can have:<\/p>\n

    \n
  1. Login Vary Cookie Conflict:<\/strong> A page may be served from cache when it shouldn’t be.<\/li>\n
  2. Purge Tag Conflict:<\/strong> Pages may be purged from cache when they shouldn\u2019t be.<\/li>\n<\/ol>\n

    Let\u2019s chat about both of these scenarios, what causes them, and how to fix them.<\/p>\n

    Mmmmm. Login Vary Cookies.<\/h2>\n

    Before we explain how to fix this problem, it\u2019s handy to understand how this is all supposed<\/em> to work.<\/p>\n

    \"\"<\/p>\n

    As of this writing, LSCache for WordPress will only cache and serve pages for non-logged in users. (Remember this. It\u2019s important.) This behavior is controlled by a vary cookie called _lscache_vary<\/code>. \u00a0Once users have logged in, the cookie is set, and their page requests will always <\/em> be processed by WordPress. The pages they visit will not be cached, nor will cached pages be served to them.<\/p>\n

    You can see why it\u2019s important, then, for the _lscache_vary<\/code> cookie to be set correctly. It\u2019s the key to determining which users get pages served from cache, and which users get pages through WordPress.<\/strong><\/p>\n

    Ok, so let\u2019s say your domain serves Example Blog at www.example.com\/<\/code> and Example Store at www.example.com\/store\/<\/code>, which is a subdirectory of Example Blog. If you log into Example Blog, the _lscache_vary<\/code> 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.<\/p>\n

    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<\/code> cookie is still set from your visit to Example Blog, and so this page is cached for logged-in users <\/em> . Uh oh. This causes future logged-in Example Store users to get a \u201ccache hit\u201d on this page and be served the non-logged in version of the page. This is decidedly not <\/em> normal behavior.<\/p>\n

    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).<\/p>\n

    Why does this happen?<\/h3>\n

    Think about it from the browser\u2019s point of view. As far as the browser is concerned, Example Blog (www.example.com\/<\/code>) and Example Store (www.example.com\/store\/<\/code>) 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<\/code>. \u00a0Even though the store is an entirely separate WordPress application, to the browser it looks simply like a part of the blog.<\/p>\n

    How can we fix it?<\/h3>\n

    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.<\/p>\n

    By default, the cache will use _lscache_vary<\/code> 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.<\/strong><\/p>\n

    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<\/strong>, and set Login Cookie<\/strong> to _lscache_vary_blog<\/code> (or whatever you would like it to be).<\/p>\n

    \"\"<\/p>\n

    You could then do the same in Example Store\u2019s WP-Admin panel and set Login Cookie<\/strong> to something different, like _lscache_vary_store<\/code>. \u00a0(Technically, you don\u2019t 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\u2019d have _lscache_vary<\/code> and _lscache_vary_store<\/code>.)<\/p>\n

    If you had more installations running off of this same root, you\u2019d want to repeat this process for all of them.<\/p>\n

    Achievement unlocked: eliminate login vary cookie conflicts!<\/strong><\/p>\n

    Cache Tag Prefix<\/h2>\n

    —<\/p>\n

    September 2017 UPDATE: <\/em><\/strong>in the latest versions of LSCache, this is no longer an issue<\/strong>. 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.\u00a0<\/em><\/p>\n

    —<\/p>\n

    Here is another problem you may run into when you have Example Blog and Example Store running together on www.example.com<\/code>: excessive purging of the cache.<\/p>\n

    Note: This is not <\/em> 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.<\/p>\n

    So here\u2019s the issue: LSCache for WordPress has a default cache tag prefix of b1_<\/code>, 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_<\/code> 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 \u201cpurge everything with the cache tag \u00a0b1_<\/code>\u201d and out goes your entire Example Blog cache (which you wanted) and <\/em> your Example Store cache as well (which you did not want), because it also has the b1_<\/code> tag.<\/p>\n

    To solve this, you need to give all of your sites unique custom Cache Tag Prefix<\/strong>es in the same Advanced settings screen as before.<\/p>\n

    \"\"<\/p>\n

    For Example Blog, you could set it to b<\/code>, and for Example Store, set it to s<\/code>. Those strings would then be added to the beginning of the relevant app\u2019s cache and purge tags. A command to purge Example Blog would then be interpreted as \u201cpurge everything with the cache tag b_b1_<\/code>. \u201d \u00a0Example Store would be left alone, because its purge tags begin with s_b1_<\/code> .<\/p>\n

    Achievement unlocked: eliminate cache purge conflicts!<\/strong><\/p>\n

    In a nutshell…<\/h2>\n

    Using LiteSpeed Cache <\/a> 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 <\/a> .<\/p>\n

    —<\/p>\n

    Have some of your own ideas for future WordPress Wednesday<\/a> topics? Leave us a comment!<\/p>\n

    Don\u2019t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:<\/p>\n