[Resolved] WP Cache in Multisite Environment

[niyo]

Hey, i'm absolutely loving the cache plugin, however, although working flawlessly in my single site installs, multisite still has a few kinks that need ironing out if possible.

1. "LiteSpeed Cache was unable to write to your wp-config.php file..."
that error persists on all sites in the network despite the cache line being in the config file and the cache functioning super.
also you need to ensure that error is only displayed to network admins as its confusing the life out of less privileged users (even site administrators won't actually know what to do with the error).

2. Domain mapping SSO issue.
you sorted out the issue with logged in users seeing cached pages however the following problem still exists for mapped domains. if a cached version of a page exists and the user is yet to be authenticated on the mapped domain then a redirect loop will occur whereby the back end is saying the user is logged in to the network lets log them in to the mapped domain but litespeed is recognising the user as logged out so serves the cached page and the cycle continues

Thanks

 

[KevinFwu]

Hi niyo,

How is your multi site setup set up? Is it by sub domain or by sub directory?

How many wp-config files do you have?

EDIT: I just did a little testing and am not encountering the error in sub domain nor in sub directory. If the error is still there, could you send me a temporary login to the network admin to see why it's displaying? The only reason it should be showing is if the plugin is enabled and the WP_CACHE define is either not defined or defined as false.

 

[niyo]

ah silly me, guess I was just that excited to use it that I commented out the line from the previous cache not realising it said false and because the cache was functioning fine I didn't double check. silly me.
still think the error shouldn't appear for unprivileged users though. also the sso thing is still a thing.

thanks for your help and looking forward to what this plugin has in store
litemage like functionality for woocommerce would be a dream ;-P

 

[KevinFwu]

Good to hear that it is not an issue any more.

We will look into changing the error. This seems like a simple change, so it will most likely be done unless there is a good counter argument.

For unprivileged users, this is definitely not intended. Do you think your site admins should still be seeing the message?

Could you give me an example of your SSO set up? Which plugin are you using to implement this?

The way LSCache works is that when a user logs into WP, it will include a cookie to the client that logged in. If you did not set any rewrite rules to change it, it should say something like _lscache_vary=1. If you can test this, check to make sure that the response includes this cookie.

Then, try to go to another site in the SSO network. Does the request include this cookie?

 

[niyo]

I think single site installs should be limited to administrators and multisite installs should be limited to network admins. but i guess ultimately it would come down to what you guys think would work.

we use the domain mapping plugin by wpmudev. I'm not all that technically savvy when it comes to more sophisticated matters so i may be slightly off with everything I'm about to say. logged in users aren't automatically logged into mapped domains because the session is specific to the domain they logged in on, so what needs to happen is cookie syncing. the domain mapping plugin appends a query string to the mapped domain when a logged in user first visits the domain and this logs them into the mapped domain. what i believe to be happening is because the user isn't logged into the mapped domain initially (cookie syncing hasn't happened yet), litespeed is trying to serve a cached page when the domain mapping plugin attempts to sync the cookie it can't because litespeed is serving the cached page which in turn results in the plugin trying to sync the cookie again and the cycle continues. something along the lines thereof ~'_'~

subdomain.network.com (user logged in and attempts to visit front end)
mappeddomain.com (user isn't logged in)
mappeddomain.com/?__domainmap_action=domainmap-authorize-user&auth=user|hash (attempt to log user in)
[the sequence is basically an infinite loop of the bottom 2 urls]

this only happens if a cached version of the front end page the user is visiting already exists else it logs in fine and then litespeed is able to discern subsequent pages even if cached version exists. if i were to hazard a random guess as to why it happens with litespeed cache and not other plugins is because with the cache operating on the server level it makes sunrise moot, but i could be wrong

i didn't see the _lscache cookie response header. assuming I'm supposed to be looking at the set-cookie response header? i saw parameters from other plugins. i can provide a log in if thats easier?

 

[KevinFwu]

Hi niyo,

I took a look at the Domain Mapping plugin. It looks like the remote login option in that plugin adds an ajax like request to the pages. What this does is this always sends an extra query to the back end to check if it's a logged in user.

I am not sure if you have this option disabled, but I think the easiest fix to your problem is to enable that option.

The only con about this is that it adds an extra request to the backend each time. However, this request is not required to show the page to non logged in users. This means that non-logged in users will still see a fast page.

To create an alternative for this in the LiteSpeed Web Server/Cache/WordPress Plugin will require a lot of thought. Our current idea would be to implement something similar to what the remote login option does. So even if we implemented it, there would not be a meaningful improvement in our version vs theirs, as it always requires a request hitting the backend.

If you have this option enabled already, we might need access to your server because that for sure means something else is wrong.

Remember to purge your cache after changing the option, as the cache already has a version of the page without the script.

 

[niyo]

hi i think you took a look at a different domain mapping plugin. mine is the one from wpmudev but i guess it potentially works in a similar way. It has a setting called 'Cross-domain autologin'.

it works by adding this line to the head which causes the page to reload if user is logged in:

<script type="text/javascript" src="https://domain.tld/dm-sso-endpoint/1652593547/?dm_action=domainmap-setup-cdsso"></script>

so that explains the infinite loop i guess because pages are cached with that line.

i just looked at the other plugin and found this:
"If you look at the code it's simply a cookie exchange between the subdomain and the mapped domain via a javascript-injected page reload."
so looks like users of that plugin would have the same problem too although i haven't tried it. but it's the page reload that's the problem because of sunrise i think. The page is reloading but litespeed cache serves pages before sunrise which i assume is the point when the cookie sync would occur. something along the lines thereof, like i said I'm not that technically inclined.

I've disabled the setting for now which just means my users won't be able to comment or alike on the front end for cached pages on mapped domains, as all user logins occur on the main domain, but its either that or i go back to supercache. undecided which i'll go for yet.

 

[niyo]

ok so i just installed it on another multisite network that was previously using supercache. for some reason litespeed cache can never write to the config after supercache was in use but that's neither here nor there. so like before i had to add it manually. like before i simply commented out the line however this time i made sure the line said 'WP_CACHE', true

here's the thing after that the error went away but then it came back and this time the config had 'WP_CACHE', false. so maybe i wasn't so crazy the first time around. are there any conditions in which the plugin or wordpress might change it from true to false? also to add false doesn't actually seem to impact plugin functionality.

 

[KevinFwu]

The plugin I looked at, here, looks to be doing the same thing that you are describing. I'm not sure what they changed with the new releases, but the version I linked to worked by enabling that option.

With the link and the log in, I can investigate further to see what actions can be done.

 

[KevinFwu]

Regarding the second issue with supercache, that's a simple bug fix, thanks for reporting it.

 

[niyo]

ok worst case scenario i'll switch to that other plugin if it works. it's by different devs, don't think they're linked in any way just similar in functionality

 

[niyo]

back again with more multisite, domain mapping goodness.

so manually clearing caches with the plugin using mapped domains on multisite is currently a no go. i think it used to work fine when all domains in an account were sharing a cache folder but i think when i changed the setup to lscache/$vh_name to meet the needs of other accounts on the server this may have changed.

so initialy i was using parked domains to map the domains which didn't create any folders in the lscache/$vh_name so i thought that may have been the reason i couldn't clear caches so i switched to addon domains which i now realise creates a subdomain folder in which i can see cache files being created. but when it comes to manually clearing it's still a non starter. and by manually clearing i also include actions such as creating and updating posts. however caches do clear once the ttl expires.

also cached files for the mapped domains are created twice haven't checked if that is standard behaviour yet but they are created in /lcache/ and /lscache/vh_name/ not sure if that has anything to do with it.

any pointers would be helpful.

thanks

 

[KevinFwu]

Hi Niyo,

Could you provide an example of what your setup looks like?

e.g. domain names abc.com, def.com, ghi.com are in a single virtual host, alphabet.
def.com is mapped to abc.com/def/

Then your sites are caching in
/lscache/
and
/lscache/alphabet/

I just want to make sure I completely understand your setup before exploring further.

Cheers,
Kevin

 

[niyo]

cpanel account with the following domain: main.tld

addon domains:
domain1.tld
domain2.tld
all addon domains share the document root "public_html" along with main.tld

also scratch the whole cache files in 2 locations thing. i had temporarily set the cache to /lscache/$vh_domain to test if it would help when clearing cache files and that was why cache files started appearing in /lscace/ because for some reason vh_domain doesnt work for me. i got confused because when the domains were aliases/parked domains they would create cache files in /lscache/ as vh_name doesn't recognise aliases.

anyway now that im using addon domains cache files appear in:
/lscache/main.tld/
/lscache/domain1.main.tld/
/lscache/domain2.main.tld/

the cache for main.tld works fine and im able to clear it using purge from the back end or when pages are updated. it's just the mapped domains that are the problem.

 

[KevinFwu]

So from the wordpress perspective:

Main site is main.tld.

Sub sites are:
domain1.main.tld
domain2.main.tld

These are mapped to domain1.tld and domain2.tld respectively?

If this is the case, and the cache files are in:
/lscache/main.tld/
/lscache/domain1.main.tld/
/lscache/domain2.main.tld/

When you purge from a sub domain's admin panel (e.g. domain1.main.tld), it doesn't purge correctly. Does this sound right?

 

[niyo]

pretty much but to make it a little clearer lets call the sub sites sub

so domain1.tld is mapped to sub1.main.tld and the cache folder for this is /lscache/domain1.main.tld

so when i try to purge from the admin sub1.main.tld/wp-admin it does nothing and still get "x-litespeed-cache hit" on domain1.tld
same applies if new content is published or updated. cached files are only cleared when expired

 

[KevinFwu]

Hi niyo,

Do you have a test machine with the same set up? My current version of the plugin does not have this issue. I will test the version that is out there soon, but if you'd like to test this version out, you are more than welcome to.

I believe it is stable, but it hasn't gone through a full test suite yet.

If you don't get back to me before I test the outgoing version, I will edit this post with updated information.

EDIT:
Tested the outgoing version, I also did not encounter the issue, so my set up may be incorrect.

For me:
testsubdo.com
second.testsubdo.com -> mapped to secondsite.com via wordpress plugin.

On the server side, cache data is set to $SERVER_ROOT/subdo_cache
Nothing else special about it.

1. Visit

http://secondsite.com/2016/03/30/hello-world/

2. Refresh page to make sure it's cached
3. Purge all
3(a). I also tried editing hello-world.
4. Visit page again, it is a cache miss.

Am I missing something in my set up? Where did you set your cache path? In an Apache config, through cPanel admin, or through our web admin?

Cheers,
Kevin

 

[niyo]

Hi Kevin,

Still having the problem on latest build.

My cache path is lscache/$vh_name. It is set in:

/usr/local/apache/conf/userdata/conffile.conf

overall it works as expected other than in this multisite mapped domains scenario.

 

[KevinFwu]

Hi Niyo,

Could you send me your server cache configurations and your vhost configurations? I thought I duplicated your scenario, but I didn't encounter the issue, so I will try to emulate what you have on my machine.

edit: you can send it via the pm to keep it private.

 

[KevinFwu]

To anyone that encounters this problem:

The configuration that caused this problem was that there were two virtual hosts set up.

One for domain1.tld (which is mapped to sub1.main.tld)

And one for *.main.tld.

Both mapped to the same document root.

This caused an issue because the wp admin page is attached to sub1.main.tld, which will go to the second virtual host while anyone visiting domain1.tld is cached in the first virtual host.

Since it is not an alias for the first virtual host, the purge all button will purge the second virtual host while everything is actually cached for the first virtual host.

The solution is to add sub1.main.tld as an alias to the first virtual host. Since sub1.main.tld is a more precise alias when compared to the wildcard, it will utilize that virtual host.