LSCache Mediawiki Plugin

#61
@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.
So, I've tried to remove it via .htaccess, but it doesn't seem to go away. I wonder if this is something that the plugin is doing, because I can't figure out what is triggering it. I'll double-check the web admin and see if maybe I had something turning it on there.

Unzip the attached test.zip and upload test.php to the document_root where https://test.westeros.org is installed, request it in browser and check cache header. https://www.cachecrawler.com/tmp/test.zip
So, this file does seem to cache, and I see it places the GA cookies. So, that's interesting. So either it's something about how Mediawiki adds hooks, or it's some interaction between the LiteSpeedCache plugin and the hook.... very confusing. I wish there was some way to debug and understand why it decides not to present any cache at all when I have this script added via Gtag or the hook.
 

LiteCache

Active Member
#62
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 you ever tried to completely remove the GA extension? So not only disable but completely remove!
 
#63
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 you ever tried to completely remove the GA extension? So not only disable but completely remove!
Re-uploaded the corrected script, still puts the cookie on and still seems to cache just fine.

The GA extension in localsettings.php is simply called like this:

Code:
wfLoadExtension( 'GTag' );
$wgGTagAnalyticsId = 'G-60WQVKGFXH';
I had just added ## before each line to comment it out, but I have gone ahead and totally removed it just to make sure. Still no joy -- will not cache so long as that hook is putting the script in.

Very frustrating, because everything says it should work. Is there any chance that something in the LiteSpeedCache plugin is at fault? Maybe... could it be seeing the state of the page before the hook, and when it compares to the hook version it says, "Well, this is totally different, cache miss"? But the it caches the post-hook version, so it will never actually hit the cache...

But that doesn't make a lot of sense, because I have other stuff in hooks like meta-tags, and those presented no problem. It's specifically scripts that set cookies that seem to be an issue. I even had a script for geni.us links to automatically rewrite links to Amazon to affiliate links...

Actually, that leads to a thought. I will put the hook near the top of LocalSettings.php, and see if anything changes.

ETA: Nope, no change. Of course, Mediawiki's own execution order may not depend on where things are placed in LocalSettings.php. I will have to check and see if that is discussed anywhere.
 
#65
The LScache extension has a debug function. Please enable it.
Ugh, it seems the plugin's logging does not function with versions after 1.37 at the moment, as it's calling the user ID in an inappropriate way that was changed with 1.37.

I will see if I can fix the plugin later today, need to head off for awhile ATM. Again, many thanks for the assistance!
 
#66
in my opinion problem in $wgHooks['BeforePageDisplay']

Hooks allow custom code to be executed when some defined event (such as saving a page or a user logging in) occurs.
BeforePageDisplay Allows last minute changes to the output page, e.g. adding of CSS or JavaScript by extensions.

I think, you need edit skin to add GA script.
 
#68
I think, you need edit skin to add GA script.
I'm not sure scripts can be executed from inside the skins themselves, but I will look into it.

@LiteCache

Uploaded the new file, still seems to cache successfully. I am still trying to figure out how to get cache logging to work due to the change in how users are called on Mediawiki, so afraid I can't say what the log is saying at the moment.
 

LiteCache

Active Member
#69
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.
 

LiteCache

Active Member
#70
@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 why the cache plugin doesn't work the same way on your server. Given that it also works for me with Gtag, I don't know what to look for. The last option left is to check or deactivate the ls_smartpush cookie. You can find $wgLogos in LocalSettings.php. Comment all entries of this variable. This means that the server PUSH header is no longer sent. Then delete the ls_smartpush cookie in your browser and try again. If this doesn't change anything, I have to ask you to contact LiteSpeed Support. support@litespeedtech.com
 
#71
Wow, that is unexpected news, but thanks for that. I need to figure out where this ls_smartpush cookie is coming from, I guess. It's just a straightforward OLS install.

I may see if I can get a trial key for LSWS as well.
 

LiteCache

Active Member
#72
I need to figure out where this ls_smartpush cookie is coming from, I guess. It's just a straightforward OLS install.
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.
 
#73
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.
Ooooh, I see. Okay, I shall try that and see.
 

LiteCache

Active Member
#74
If you want to test the LSWS, I recommend using it together with a supported server control panel. Using LSWS natively without appropriate knowledge of LSWS is not recommended.
 
#75
If you want to test the LSWS, I recommend using it together with a supported server control panel. Using LSWS natively without appropriate knowledge of LSWS is not recommended.
Thanks.

Unfortunately, I see the skin itself and some other parts of Mediawiki all send images (like the search magnifier) that seem to trigger ls_smartpush. As far as I can tell, OLS doesn't support the directive to turn off smartpush -- at least, it doesn't work when I put it in htaccess.
 

LiteCache

Active Member
#76
The images aren't the problem, it's what MediaWiki does with them. MediaWiki sets a preload header and this header forces the ls_smartpush cookie to be set.

Could you send me the LocalSettings.php via DM? You can delete the DB parameters.
 

LiteCache

Active Member
#78
if disable ESI on LSWS - also work "as expected"
As already said several times ESI doesn't matter. ESI can be enabled and it also doesn't matter, but as slong as there are no ESI wholes ESI is not used. Cache extension for MediaWiki works, but it doesn't work if Gtag extension is installed.
 
#79
if I right understanding, Mediawiki $wgHooks['BeforePageDisplay'] each time redirect output even page in lscache.

lscache send cached page but $wgHooks['BeforePageDisplay'] change header anyway.

I think must by other way add GA script in header.
 
Top