Last modified: 2012-04-11 19:12:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37854, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35854 - LCStore_DB cache is not refreshed on action=purge
LCStore_DB cache is not refreshed on action=purge
Status: NEW
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.18.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-10 11:21 UTC by Dmitriy Sintsov
Modified: 2012-04-11 19:12 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dmitriy Sintsov 2012-04-10 11:21:40 UTC
I spent some hour trying to figure out why all of my ResourceLoader module messages suddenly become unavailable when I just inserted two additional messages into extension's i18n file. Extension originally used to be well-working and messages were well-loading.

I introduced a PHP syntax error (typo) in i18n file, however I quickly fixed it then reload the page, including clearance of Chrome cache, action=purge and $wgCachePages = false; in LocalSettings.php.

But the extension's messages did not appear back, nothing helped. All of messages were replaced by default "message key placeholders with ampersands".

After tracing where placeholders are coming from, I figured out that incorrect empty messages were cached by instance of LCStore_DB, created in constructor of LocalisationCache class:

		$this->store = new $storeClass( $storeConf );

The further code was suggesting to switch to LCStore_CDB instead. So I've added the following line into LocalSettings.php:

$wgCacheDirectory = "$IP/cache";

and just after defining $wgCacheDirectory and simple Ctrl+R in Chrome, all of my ResourceLoader messages, including newly added ones, appeared at client-side, available in mw.msg()

I guess there is some bug in LCStore_CDB because messages file was properly corrected, however the $this->store state was not refreshed.

But the most disappointing is that action=purge did refresh message cache.
Comment 1 Niklas Laxström 2012-04-10 11:57:42 UTC
LocalisationCache is automatically regenerated when any i18n file changes, unless you have disabled that option.

This has nothing to do with action=purge (and shouldn't imho).
Comment 2 Dmitriy Sintsov 2012-04-10 16:05:51 UTC
Which option is it? My test host's LocalSettings.php is mostly generated by new web installer with just some minor tweaks.

Why messages did not regenerate automatically until I switched from LCStore_DB to LCStore_CDB with the only source change in LocalSettings.php

$wgCacheDirectory = "$IP/cache";

and absolutely nothing more? I did a lot of things, touched i18n file, checked sources for syntax errors with recursive php -l (lint), traced from ResourceLoader to MessageBlobStore then MessageCache then both LCStores.
Comment 3 Dmitriy Sintsov 2012-04-10 16:11:27 UTC
I made a typo in the message with timestamp '2012-04-10 11:21:40 UTC', the incorrectly cached and not refreshed messages were in LCStore_DB instance, of course. Switching to LCStore_CDB helped.
Comment 4 Niklas Laxström 2012-04-10 16:14:37 UTC
The setting in question is $wgLocalisationCacheConf['manualRecache'] and it default to false, which means it is updated everytime any of the i18n files change.

Except if there are bugs. There might be for cases the file is missing or broken.
Comment 5 Niklas Laxström 2012-04-10 16:15:03 UTC
Oh and you can run maintenance/rebuildLocalisationCache.php, with --force if needed.
Comment 6 Dmitriy Sintsov 2012-04-11 05:40:46 UTC
Thanks for providing info on maintenance script to rebuild localisation cache. I'll try to switch back from LCStore_CDB to LCStore_DB at the later stage to see whether the messages stored by LCStore_DB still are broken, however at some later stage of my extension development.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links