Not defined where?

In T247629#5968878, @Reedy wrote:

Not defined where?

In LocalSettings.php, so that $wgNamespaceProtection [NS_MODULE] = ['editmodule']; restricts write access to the main namespace rather than to Module:.

NS_MODULE is a non canonical namespace, you must use the numerical constant

$wgNamespaceProtection[ 828 ] = [ 'editmodule' ];

In T247629#5969183, @Ammarpad wrote:

NS_MODULE is a non canonical namespace, you must use the numerical constant

$wgNamespaceProtection[ 828 ] = [ 'editmodule' ];

That's what I did; however NS_NODULE is mentioned here: https://www.mediawiki.org/wiki/Extension_default_namespaces#Scribunto.

In T247629#5969186, @alex-mashin wrote:

That's what I did;

No, you used $wgNamespaceProtection [NS_MODULE] = ['editmodule']; that's not the same thing with what I said.

howere NS_NODULE is mentioned here: https://www.mediawiki.org/wiki/Extension_default_namespaces#Scribunto.

Yes, it's still not canonical MW namespace.

In T247629#5969187, @Ammarpad wrote:

In T247629#5969186, @alex-mashin wrote:

That's what I did;

No, you used $wgNamespaceProtection [NS_MODULE] = ['editmodule']; that's not the same thing with what I said.

No, when I found out the absence of NS_MODULE, I had to switch to:

if (defined ('NS_MODULE')) {
	$wgNamespaceProtection [NS_MODULE] = ['editmodule'];
} else {
	$wgNamespaceProtection [828] = ['editmodule'];
}

So, I eventually had to do basically what you said.

@alex-mashin: Instead of having to ask several times due to byte-size information, it would be welcome if you followed https://www.mediawiki.org/wiki/How_to_report_a_bug and provide complete and clear steps to reproduce your setup, which leave no room for interpretation. Thanks.

In T247629#5969191, @alex-mashin wrote:

So, I eventually had to do basically what you said.

No you did something different again; You should use $wgNamespaceProtection [828] = ['editmodule']; as it's all you need. You needn't to 'basically' use something else. NS_MODULE is meant to be used internally in the extension code.

If you must use it then you've to explicitly redefine it for yourself before loading the extension.

define( 'NS_MODULE', 828 );
wfLoadExtension( "Scribunto" );
$wgNamespaceProtection[NS_MODULE] = ['editmodule'];

But that's pretty pointless as it's the same thing with what has been already repeated above.

If you're wondering why $wgNamespaceProtection[NS_CATEGORY] = ['editcat']; works on the fly but $wgNamespaceProtection[NS_MODULE] = ['editmodule']; does not; it is because of this.

In T247629#5970859, @Ammarpad wrote:

No you did something different again; You should use $wgNamespaceProtection [828] = ['editmodule']; as it's all you need. You needn't to 'basically' use something else. NS_MODULE is meant to be used internally in the extension code.

I did it in the hope that this issue would be resolved. The code fragment to which you referred still doesn't explain to me why namespace constants defined in some extensions are not available in LocalSettings.php while others are (like SMW_NS_PROPERTY).

In T247629#5971996, @alex-mashin wrote:

I did it in the hope that this issue would be resolved.

Actually there's no issue to solve here as this report is invalid.

The code fragment to which you referred still doesn't explain to me why namespace constants defined in some extensions are not available in

The constants defined in the extension.json are not available by the time LocalSettings.php is setup because wfLoadExtension() is executed later, I believe.

... while others are (like SMW_NS_PROPERTY).

You did not ask why SMW_NS_PROPERTY works. Semantic MediaWiki is a sort of specialized extension here. That's why the extension is peculiarly enabled with enableSemantics( url ) function instead of loading through conventional wfLoadExtension( ) function or require_once statement used by majority of extensions.

enableSemantics() function is the mechanism through which the constants get defined in your LocalSettings.php. That's not currently available with wfLoadExtension().

If you load Semantic MediaWiki with wfLoadExtension( SemanticMediaWiki ) function (similar to how you currently load 'Scribunto' ), you'll get the same PHP warning as soon as you attempt to use SMW_NS_PROPERTY or any other of its namespace constants in LocalSettings.php

When extensions were loaded via requiring a PHP file like Scribunto.php, that PHP file was able to define constants and so they could be used later in LocalSettings.php.

The switch to extension registration broke this: extension.json can declare namespace constants to be defined, but since extension.json isn't processed until after LocalSettings.php is done those constants don't get defined in time to be used within LocalSettings.php. See also T152294 and T141223.

In T247629#5971996, @alex-mashin wrote:

while others are (like SMW_NS_PROPERTY).

It looks like SMW doesn't directly use MediaWiki's standard extension loading mechanism. Its instructions say to activate it by calling "enableSemantics()" instead, which does a bunch of extra stuff including defining that constant.