Jump to content

Extension talk:NamespacePaths

Add topic
From mediawiki.org
Latest comment: 11 months ago by 95.98.134.109 in topic example.com/foo/ vs example.com/foo


Configuration

[edit]

Hi,

@Dantman

Could you provide an example how to configure this extension? What to put in $wgNamespacePaths and htaccess? I'm not exactly a programmer but I need an extension like that and I can't figure it out myself. Cristal01 (talk) 23:24, 3 May 2018 (UTC)Reply

Interesting question. I'd e.g. go for this:
LocalSettings.php
$wgArticlePath = "/wiki/$1";
$wgNamespacePaths = [
	NS_FILE => "/wiki/file/$1",
	NS_HELP => "/wiki/help/$1"
];
.htaccess
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteRule ^/?wiki/file(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
	RewriteRule ^/?wiki/help(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
	RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
	RewriteRule ^/?$ %{DOCUMENT_ROOT}/w/index.php [L]
</IfModule>
If this is not working I do not know. Still Dantman may comment. :) [[kgh]] (talk) 06:44, 4 May 2018 (UTC)Reply

more Variable

[edit]

an option to make it more variable would be pleasing.

Namespaces as subdomain for example and no need to hardwire the

 	NS_FILE => "/wiki/file/$1",
   	NS_HELP => "/wiki/help/$1"

would be nice. Actual every addition of namespaces need an modification of the config, it would be awesome that it isn't needed in future versions. I use several, a couple douzen, to set all manually shouldn't be the way to go. Gunnar.offel (talk) 10:10, 5 December 2020 (UTC)Reply

Undesired changes to keys defined in $wgNamespacePaths when extension is active

[edit]

To summarize:

After having a wiki updated from 1.35 to 1.39, in which the configuration was working just fine, the keys pointing to custom namespaces somehow get themselves chanted into zero-indexed integers, as though the values are stored in a regular array.

With $wgNamespacePaths as configured, assuming that NS_FOO = 3000 and NS_BAR = 3002:

LocalSettings.php

$wgArticlePath = "/$1";
$wgNamespacePaths = [
    NS_FOO => "/foo/$1",
    NS_BAR => "/bar/$1"
];

The associative array as evaluated is expected to return

Array
(
    [3000] => /foo/$1
    [3002] => /bar/$1
)

However, with the extension active, the actual outcome gives me

Array
(
    [0] => /foo/$1
    [1] => /bar/$1
)

thereby causing these short links to point to the wrong namespaces in that manner.

With all these taken into account, did I misconfigure anything, or am I missing something, or does the extension have an existing issue that has yet to be fixed?

If it's any of the former two, how do I go along with solving the problem in question?

UPDATE: I found out the underlying cause, that being the absence of "merge_strategy": "array_plus" to be specified in the NamespacePaths config of extension.json. UniversalEntropy (talk) 12:06, 28 March 2023 (UTC)Reply

I also had this issue in MediaWiki 1.41.
Apparently fixed by adding to extensions/NamespacePaths/extension.json
in the section "config"/"NamespacePaths", the key-value pair "merge_strategy": "array_plus"
Thanks, UniversalEntropy, for the help! 95.98.134.109 (talk) 11:14, 31 March 2024 (UTC)Reply

example.com/foo/ vs example.com/foo

[edit]

I notice that example.com/foo works great with namespaces,

but example.com/foo/ returns an error page, which is not preferred:

"Bad title

The requested page title is empty or contains only the name of a namespace."

I can assume it is requesting the page Foo:

Does anybody have a reliable correction for this? 95.98.134.109 (talk) 11:18, 31 March 2024 (UTC)Reply