Search results

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

btw. You know that deactivating the built-in crawler can easily bypassed and you can't prevent this bypass....?

You can only "watch" the current running processes only with the account/user you are logged-in. If you are logged-in as root, then ps aux command only shows processes that are executed by root.

No, not the cache plugin. I mean the GDPR plugin.

Would you provide me with a link where you got this plugin from?

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

No, with any user account.

Please temporarily deactivate the GDPR plugin and purge the cache.

I just disabled my adblocker and can now reproduce the problem you described. Would you please post the .htaccess and any custom header settings you changed/added in OLS?

https://wiki-test.westeros.org/index.php/Main_Page?test=11