If $wgArticlePath = '/$1', a URL created from a title starting from a slash is malformed: [[/etc]] on a page in a namespace for which subpages are not enabled gives http://etc/ not http://my-server//etc as it should.
The article "/etc" is still accessible by the URL http://my-server//etc.
Tested under MW 1.25.2.
Yes, I know that such URLs are not recommended, but that is not the point.
What would be a summarized description of this bug? Editing the task summary is welcome (e.g. by adding a verb as it currently does not describe a problem). Thanks!
I suspect what happens here is that links to the /etc page get output as <a href="//etc">...</a>, which is then interpreted by the browser as a protocol-relative link.
What happens if you set $wgArticlePath = '/./$1'?
In this case, MW engine forms ugly-looking but correctly working URLs, which are prettyfied by browsers (I have checked Firefox and Opera): [[/etc]] → <a href="/.//etc"> in page's source code → http://my-server//etc in browser's status bar, in the clipboard when the link is copied and in the address bar if the link is opened. But I don't know how search engines will treat such internal links.
Perhaps, leading slashes should be URL-encoded or prepended with ./ when forming a wikilink on pages in the main namespace if it does not support subpages?
For the time being, I worked around with this in LocalSettings.php:
// This is for titles starting with /: [[/etc]] → "//etc" → "/.//etc".
// Set merge_slashes off in nginx config!
$wgHooks ['GetLocalURL'] [] = function ($title, &$url, $query) {
if (mb_substr ($title->getText (), 0, 1) === '/'
&& $title->getNamespace () === 0
&& !MWNamespace::hasSubpages (0 /* the same as $title->getNamespace () but faster */)
) {
$url = '/.' . $url;
}
return true;
};Than you, @TTO, for your help.
But I think this is definitely a bug as wiki articles' titles can start with a slash and wiki URLs can contain double slashes.