LSCache Mediawiki Plugin
- Thread starter Balerion
- Start date
Think this covers it:
Server Configure > Cache Module
Module Parameters
storagePath $SERVER_ROOT/cachedata
Virtual Host (subdomain) > Cache Module
Module Parameters
CacheRoot lscache
CacheEngine On
CacheIgnoreCacheControl On
CacheLookup public on
CacheLookup private on
Virtual Host (subdomain) > Context
Header Operations
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy "upgrade-insecure-requests;connect-src *"
Referrer-Policy strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection 1;mode=block
Permissions-Policy: geolocation=(self "")
.htaccess
Header unset Pragma
AddDefaultCharset utf-8
<IfModule litespeed>
CacheLookup on
</IfModule>
<FilesMatch \.php$>
SetHandler proxy:fcgi://westeros-php81
</FilesMatch>
Server Configure > Cache Module
Module Parameters
storagePath $SERVER_ROOT/cachedata
Virtual Host (subdomain) > Cache Module
Module Parameters
CacheRoot lscache
CacheEngine On
CacheIgnoreCacheControl On
CacheLookup public on
CacheLookup private on
Virtual Host (subdomain) > Context
Header Operations
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy "upgrade-insecure-requests;connect-src *"
Referrer-Policy strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection 1;mode=block
Permissions-Policy: geolocation=(self "")
.htaccess
Header unset Pragma
AddDefaultCharset utf-8
<IfModule litespeed>
CacheLookup on
</IfModule>
<FilesMatch \.php$>
SetHandler proxy:fcgi://westeros-php81
</FilesMatch>
I am now pretty sure that the malfunction is caused by the GDPR plugin and that this plugin sends a purge header so that the consent selection can be saved. If I'm correct, then you have to choose another plugin for the GDPR function or ask the plugin's programmer how to deactivate this purge header.
Sure: https://www.mediawiki.org/wiki/Extension:LiteSpeedCache
Oh, you probably mean the GDPR code. That came from our ad guys, I have contacted them.
Oh, you probably mean the GDPR code. That came from our ad guys, I have contacted them.
Hah. Well, apparently they have it through a third party vendor and are contacting them.
That said...
I have disabled all ads and the consent, cleared all cookies, restarted my browser... and I am now just getting misses. The only cookie being set is from Google Analytics. So it seems like the consent code may not be the only issue.
I do notice that one of the fields in the GA cookie, _ga_60WQVKGFXH (may be individual) keeps incrementing with each reload. So if somehow all cookies are being looked at, not just log-in, the changing value might possibly explain misses?
That said...
I have disabled all ads and the consent, cleared all cookies, restarted my browser... and I am now just getting misses. The only cookie being set is from Google Analytics. So it seems like the consent code may not be the only issue.
I do notice that one of the fields in the GA cookie, _ga_60WQVKGFXH (may be individual) keeps incrementing with each reload. So if somehow all cookies are being looked at, not just log-in, the changing value might possibly explain misses?
The cookie itself doesn't matter, but any script seems to send the purge header and this header seems to prevent proper caching, so it is up to you to find out which function sends this purge header with every request. Finally, this issue is not a LiteSpeed issue and is caused by 3rd party script or extension. Please don't ask for free support if any 3rd party scripts prevents correct caching!!!
Thanks for helping me narrow it down. It seems like it must be a Mediawiki issue, then, since the script is being loaded via LocalSettings.php. OF course, now that I think of it, Varnish doesn't seem to have a problem with this script-related issue, for whatever reason. May have to look to setting that up again instead, since this LSCache seems less customizable than I had hoped.
Last edited:
It's neither a MediaWiki nor a LiteSpeed problem. MediaWiki cannot and must not take into account the use of a page cache and the LiteSpeed Cache plugin can only take into account the original functions of MediaWiki. If you install additional plugins that influence the cache behavior and thereby cause problems, then the respective plugin manufacturer is responsible for any malfunctions! Unfortunately, 3rd party programmers are often not very familiar with LiteSpeed and often do the wrong thing to make their programming work.
Additional information:
Compared to LiteSpeed, Varnish is a primitive Neanderthal that only knows an OFF and On of the cache. Likewise, Varnish is inflexible and cannot adapt to flexible and dynamic states of a page. That's why the area of application of Varnish is very limited. Quite apart from the technical effort required to run Varnish, Varnish is not really an intelligent Page cache solution. Ultimately, however, all aspects do not matter if a plugin programmer intentionally deactivates the cache function so that his programming works. Smart is when you develop your code so that it is also cache friendly.
The Cache Plugin for MediaWiki is a very limited plugin in terms of functionality, as it only provides basic functions, but even the best LiteSpeed Cache Plugin cannot solve something that is deliberately caused by other plugins to prevent caching. The cause of this extensively described problem is not due to the cache plugin, but rather to deliberate functions of another plugin that tries to prevent caching in order to guarantee its own functionality.
Compared to LiteSpeed, Varnish is a primitive Neanderthal that only knows an OFF and On of the cache. Likewise, Varnish is inflexible and cannot adapt to flexible and dynamic states of a page. That's why the area of application of Varnish is very limited. Quite apart from the technical effort required to run Varnish, Varnish is not really an intelligent Page cache solution. Ultimately, however, all aspects do not matter if a plugin programmer intentionally deactivates the cache function so that his programming works. Smart is when you develop your code so that it is also cache friendly.
The Cache Plugin for MediaWiki is a very limited plugin in terms of functionality, as it only provides basic functions, but even the best LiteSpeed Cache Plugin cannot solve something that is deliberately caused by other plugins to prevent caching. The cause of this extensively described problem is not due to the cache plugin, but rather to deliberate functions of another plugin that tries to prevent caching in order to guarantee its own functionality.
Right. I have OLS, I have Mediawiki, I have GA via
The reason I mention Varnish is that we use it on the main site we were hoping to move to LOS + LS cache (https://awoiaf.westeros.org), and it works fine, so perhaps it being primitive means it ignores whatever supposed plugin is causing this problem with LS cache.
The reason I mention Varnish is that we use it on the main site we were hoping to move to LOS + LS cache (https://awoiaf.westeros.org), and it works fine, so perhaps it being primitive means it ignores whatever supposed plugin is causing this problem with LS cache.
As we discussed earlier, I have disabled the GDPR and ads, so the only script setting cookies is GA, and that also doesn't successfully engage the cache.
I am in the process of removing the Mediawiki GoogleAnalytics extension and replacing it with a newer one )Gtag) to see if that improves the situation. I am doubtful, but who knows, maybe we'll have some luck.
I am in the process of removing the Mediawiki GoogleAnalytics extension and replacing it with a newer one )Gtag) to see if that improves the situation. I am doubtful, but who knows, maybe we'll have some luck.