Upgrade BlueSpice 3 to 4: Global $wgLang is null

Bugs
1

Issue
After upgrading a relativ old BlueSpice installation (first setup 2014) nothing was working and I got strange error messages. The most prominent that all kind of extensions expected to find the Manual:$wgLang - MediaWiki global but the StubObject could not be upgraded to the real Language class.

After some debugging it turns out: the mwstake/mediawiki-component-dynamicconfig component was overwriting the complete $GLOBALS - so $wgLang is null afterwards.

The extensions/BlueSpiceFoundation/config/nm-settings.php file of the BlueSpice 3 instalation has entries like these in there:

// START Namespace NS_NR_BETRIEBLICHE_ABLäUFE
if( !defined( "NS_NR_BETRIEBLICHE_ABLäUFE" ) ) define("NS_NR_BETRIEBLICHE_ABLäUFE", 3002);
$GLOBALS['GLOBALS']['wgExtraNamespaces'][NS_NR_BETRIEBLICHE_ABLäUFE] = 'NR_Betriebliche_Abläufe';
$GLOBALS['GLOBALS']['wgNamespacesWithSubpages'][NS_NR_BETRIEBLICHE_ABLäUFE] = true;
$GLOBALS['GLOBALS']['wgVisualEditorAvailableNamespaces'][NS_NR_BETRIEBLICHE_ABLäUFE] = false;
$GLOBALS['GLOBALS']['smwgNamespacesWithSemanticLinks'][NS_NR_BETRIEBLICHE_ABLäUFE] = false;
$GLOBALS['GLOBALS']['wgNamespaceAliases']['NR_Betriebliche_Abläufe'] = NS_NR_BETRIEBLICHE_ABLäUFE;
// END Namespace NS_NR_BETRIEBLICHE_ABLäUFE

Mind the useless but hamless $GLOBALS['GLOBALS'] instead of $GLOBALS. Looks like at least in one point in time the nm-settings.php file was written this way.

The migration process (BlueSpice\NamespaceManager\Maintenance\MigrateNmSettings::parseGlobals) does not account for this way of updating the globals. Thus it migrated this file so that the whole $GLOABLS['GLOBALS'] global variable (i.e. just $GLOBALS) gets replaced by BlueSpice\NamespaceManager\DynamicConfig\NamespaceSettings with useless stuff.

Workaround
Before upgrading to BlueSpice 4 execute the following in a terminal:

sed -i -e "s/GLOBALS\\['GLOBALS'\\]/GLOBALS/g" extensions/BlueSpiceFoundation/config/nm-settings.php

to remove the useless ['GLOBALS'] from the file. Then the migration creates the right configuration.

2 Likes
2

Hi @djagszent

thanks for that, but the nm-settings file looks good, the installation is not that old, it comes from version 4.2.4. Any other ideas?

3

Is it better to do the Update from 4.2.4 → 4.3 first and the to 4.4 ?

I am going back to my backup to try it again

4

You should double check in the database. Execute the following SQL query in the database of the broken system:

select cast(mwdc_serialized as char) from mwstake_dynamic_config where mwdc_key = 'bs-namespacemanager-namespaces';

It will output a PHP serialized array. It is hard to parse but search for the string _GLOBALS in there. If you find it, this bug affects you too. If not, then you have another problem.

1 Like