Namespace constants can no longer be used directly in LocalSettings
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	JeroenDeDauw
	Dec 8 2013, 3:15 PM

Description

Got the following error when updating SMW wiki to SMW master: http://pastebin.com/HY5gMiam

Modification of settings using the namespace consonants still needs to be
delayed. I had to do this (below) to address the issue, and presumably there are quite a few more settings in which those constants might be used, and that thus need to be modified at a later point.

$wgExtensionFunctions[] = function() {

global $wgContentNamespaces;
$wgContentNamespaces = array( NS_MAIN, NS_HELP, NS_CATEGORY,

SMW_NS_PROPERTY, SMW_NS_TYPE, SMW_NS_CONCEPT );

// setup namespace search
global $wgNamespacesToBeSearchedDefault;
$wgNamespacesToBeSearchedDefault[NS_HELP] = true;
$wgNamespacesToBeSearchedDefault[SMW_NS_TYPE] = true;
$wgNamespacesToBeSearchedDefault[SMW_NS_PROPERTY] = true;

// setup namespace protection for documentation
global $wgNamespaceProtection;
$wgNamespaceProtection[NS_HELP] = array('docu');
$wgNamespaceProtection[SMW_NS_TYPE] = array('docu');
$wgNamespaceProtection[NS_PROJECT] = array('docu');

return true;

};

In case those settings are SMW specific, I'm guessing we run into the earlier
issue again, where SMW starts using the config before the delayed modification
in LS happens.

We likely cannot get rid of this, in which case it should be clearly documented.

Version: master
Severity: blocker

Details

Reference: bz58182

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Resolved		None	T60190 Notice: Use of undefined constant SMW_NS_PROPERTY
		Resolved		None	T60182 Namespace constants can no longer be used directly in LocalSettings

Event Timeline

• bzimport raised the priority of this task from to High.Nov 22 2014, 2:31 AM

• bzimport added a project: MediaWiki-extensions-Semantic-MediaWiki.

• bzimport set Reference to bz58182.

• bzimport added a subscriber: Unknown Object (MLST).

JeroenDeDauw created this task.Dec 8 2013, 3:15 PM

This is unfortunate. I cannot add SMW 1.9 as target? :( Easily done on GH...

Issue

SNW-NS constants [0] are delayed due to $smwgNamespaceIndex being a prerequisite and its initialization has to happen first before [1] can be processed.

Solution

Use [2] as an approach in LocalSettings to delay initialization.

[0] SMW_NS_PROPERTY, SMW_NS_TYPE, SMW_NS_CONCEPT

[1] SMW\NamespaceCustomizer

[2] $GLOBALS['wgExtensionFunctions'][] = function() {

// Add settings relevant for after SMW intialization

$GLOBALS['wgNamespacesToBeSearchedDefault'] = array(
    SMW_NS_PROPERTY => true,
);

}

$wgContentNamespaces, $wgNamespacesToBeSearchedDefault and $wgNamespaceProtection are known configuration variables that can hold a [0] reference.

Please feel free to add additional settings that can contain [0].

[0] SMW_NS_PROPERTY, SMW_NS_TYPE, SMW_NS_CONCEPT

Delayed settings are no longer necessary for LocalSettings, as long as you add enableSemantics() to LocalSettings before any configuration is making a reference to a SMW namespace [1].

If by any occasion settings rely on a different NS index (other than 102 etc.), $smwgNamespaceIndex has to be declared before enableSemantics() in order for the namespace to set the correct Id.

Related change [2].

[1] SMW_NS_PROPERTY, SMW_NS_TYPE, SMW_NS_CONCEPT

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/47

It must be noted that, if you are using MW ≤ 1.21.x, you have to invoke the Extension installer extension with

include "extensions/ExtensionInstaller/ExtensionInstaller.php";

before declaring

enableSemantics( 'example.org' )

Otherwise you will naturally be getting a

PHP Fatal error:  Call to undefined function enableSemantics()

Namespace constants can no longer be used directly in LocalSettingsClosed, ResolvedPublicActions