Extension talk:NamespacePaths
Add topicThis page used the Structured Discussions extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made. |
Configuration
[edit]Hi,
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)
- 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)
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)
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)
- 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)
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)