Search results

No, this cookie is always set if there is a static source to preload. Entries in LocalSettings.php -> $wgLogos define such sources. Normally this cookie feature is good, but in OLS this cookie has wrong parameters and has to be fixed.

@Balerion Unfortunately I don't have any good news for you. As advertised, I installed MediaWiki on an LSWS (not OLS) together with the LScache plugin and the Gtag extension from https://www.mediawiki.org/wiki/Extension:GTag and everything worked as expected. Unfortunately, I can't tell you...

If I have time tomorrow, I will install MediaWiki, the LScache Plugin and the GA Extension again. On my own server I have better options to further isolate the problem when debugging through the LScache Extension is not possible.

@Balerion I did another change to test.php. Please download https://www.cachecrawler.com/tmp/test.zip and try again.

The LScache extension has a debug function. Please enable it.

Please download the test.zip again because the test.php contained an error and then try again. If the cache the test.php works, but Mediawiki does not and the GA code is the same everywhere, then the conclusion can only be that the code for implementing the GA extension cannot be right. Have...

@Balerion Leave the SmartPush directive as ls_smartpush cookie is incorrect in OLS, especially since you don't need this ls_smartpush cookie for MediaWiki. Unzip the attached test.zip and upload test.php to the document_root where https://test.westeros.org is installed, request it in browser...

@Balerion Where did you get this code from?

@Balerion ls_smartpush cookie doesn't matter in this case. This cookie is set by OLS/LSWS if there is a HTTP/push header, but you don't have any push headers and OLS sets this cookie wrongly with wrong cookie parameters. Anyway, ignore it. ESI? This doesn't matter as well. Loading an external...

I am out of this discussion. Maybe @Cold-Egg still has the patience to help you.

You don't seem to have understood or wanted to understand anything yet? Sorry, I'm out of this pointless discussion that doesn't help anyone.

I have no idea that the GA plugin can have an influence on the cache function. GA is Javascript based, but you need an HTTP header generated by PHP to influence the cache behavior. Javascript cannot send HTTP headers because it runs in the browser and not on the server. The fact is that if I...

Remove the purge header from GDPR plugin and you will be happy with LScache as well. BUT, you will need another solution for GDPR that doesn't use PHP and session to store users's consent selection.

GA doesn't cause anything.

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...

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...

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...

If you know Javascript then you must know what the additional code does, don't you?

Can I bill your ad guys? This is not a joke!

You must run the logging function as a user of your hosting to see which processes this user is running. You must see in logfile similiar like this: USER PID %CPU %MEM COMMAND litecach 39080 0.0 0.0 lsphp litecach 53422 3.2 0.0 lsphp:ecach/cachecrawler.com/litecache/xxx.php litecach 54118 22.5...