Last modified: 2013-11-20 15:32:13 UTC
We're having trouble again with the localisation update and Wikibase. Ori suggested that "ideally any setup code that depends on other extensions being loaded should run in $wgExtensionFunctions[] (or defer execution using some other callback strategy) rather than rely on the order of includes"
The symptom was an unrelated deploy failed in `scap` with Updating ExtensionMessages-1.22wmf11.php...Unexpected non-MediaWiki exception encountered, of type "Exception" exception 'Exception' with message 'Bad initialization order: When running the Wikibase repository extension and the WikibaseClient extension on the same wiki, WikibaseClient has to be included AFTER the repository.' in /a/common/php-1.22wmf11/extensions/Wikibase/repo/Wikibase.php:54 because the mergeMessageFileList.php script in this step gets the list of extension files to include_once from --list-file=$MW_COMMON_SOURCE/wmf-config/extension-list , which developers expect to be order-independent and alphabetical. (Gerrit change #74535 adjusted the order of wmf-config/extension-list to work around the problem.)
This should not happen at all: Bad initialization order: When running the Wikibase repository extension and the WikibaseClient extension on the same wiki, WikibaseClient has to be included AFTER the repository. There should currently be no Wikimedia site running both these extensions. Or does this only happen with localization updates, because that loads everything? Anyway, $wgExtensionFunctions[] is not an option: the include order is enforced to avoid overriding of default settings, which of course are applied directly when the extension is included in LocalSettings. I do not see a way to use $wgExtensionFunctions to improve the situation.
(In reply to comment #2) > Or does this only happen with localization updates, because that loads > everything? Yep.
I think in case of Wikibase and related extensions, we can just explicitly list all the relevant i18n / alias / etc. files in extension-list. Any reason why that would not work?
It's working now, as far as I know. I had to put the client out of alphabetical order (https://git.wikimedia.org/commitdiff/operations%2Fmediawiki-config/064dd7038c69c5ce1cce518114cd9aa9ed4981e4),\ DataTypes, DataValues, ValueFormatters, ValueParsers, and ValueValidators are the only extensions that list their i18n files directly here. I'm not sure if that is related.
Should be fixed by our new build step.
I am closing this as the new deployment repo is done and nearly in production.
