Page MenuHomePhabricator

Subpage transclusion / linking is broken
Closed, ResolvedPublic

Description

For some reason, it does not work anymore to transclude a subpage of the current page using {{/Subpage name}}. The software searches for a page in the Template ns instead.
Affected pages are e.g. https://incubator.wikimedia.org/w/index.php?diff=1130172&oldid=1130070 and
https://incubator.wikimedia.org/w/index.php?diff=prev&oldid=1129141

It has worked for years, and still seems to do so on other projects, so I'm guessing it has to do with a config change and file it under Site requests.


Version: wmf-deployment
Severity: major

Details

Reference
bz44546

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:25 AM
bzimport set Reference to bz44546.

Found a related problem on Meta: https://meta.wikimedia.org/w/index.php?title=Meta:Requests_for_adminship&oldid=5163653
In the top right corner, the link to the "Archive" subpages is given as /Archives, and fails.

  • Bug 44596 has been marked as a duplicate of this bug. ***

lambdav wrote:

Links and templates using relative path starting with / doesn't seems to work anymore on pages outside of main namespace.

It seems to work on main namespace only.

lambdav wrote:

On https://fr.wikibooks.org, subpages need to be enabled for the following namespaces :

Project (= Wikilivres)
File (= Fichier)
Template (= Modèle)
Help (= Aide)
Help talk (= Discussion aide)
Category (= Catégorie)

lambdav wrote:

It should easy and quick to fix this immediately.

(In reply to comment #5)

On https://fr.wikibooks.org, subpages need to be enabled for the following
namespaces :

Project (= Wikilivres)
File (= Fichier)
Template (= Modèle)
Help (= Aide)
Help talk (= Discussion aide)
Category (= Catégorie)

DavidL, please, create a NEW bug for your request, including a link to the relevant discussion where the community of fr.wikibooks.org is informed about it and approves this change.

This bug should be left to see the issue described on comment #0 or even closing it as WONTFIX according to comment #2

lambdav wrote:

There is no need for relevant discussion where the community of fr.wikibooks.org approves this change, or it would be a page like this :

There is a bug on our project. What worked before, do not work anymore.
Do you want the bug be corrected ?

lambdav wrote:

There is already subpages links on this namespaces. Why the project configured did changed ??

I meanwhile think that this is caused by change Ibcb53bee, which enabled subpages in the project namespace by default.
It seems like subpages in the project namespace were enabled on some wikis (including Meta and Incubator) by the setting 4=>0 in wgNamespacesWithSubpages (while others did it with 4=>1?!).

(In reply to comment #10)

I meanwhile think that this is caused by change Ibcb53bee, which enabled
subpages in the project namespace by default.
It seems like subpages in the project namespace were enabled on some wikis
(including Meta and Incubator) by the setting 4=>0 in
wgNamespacesWithSubpages
(while others did it with 4=>1?!).

That was to fix the removal in https://gerrit.wikimedia.org/r/#/c/46804/

darklama wrote:

en.wikiversity and en.wikibooks have also been broken by this.

gerrit change I685d49a6 switched to using config overriding.
Looking at the diff, I think some mistakes may have been
introduced in determining which namespaces do and do not have
subpages for many wikis. One of which was using 4=>0.

gerrit change I8d8d1c6f removed a subpages hack for the
project name for all wikis. I think this change in itself
was fine, but by keeping 4=>0 everywhere subpages for
the project namespace was broken for many wikis.

gerrit change Ibcb53bee was likely meant to replace the
hack by making the default to have subpages for the
project namespace. However 4=>0 was kept in the
overrides, which means many wikis don't recognize the
project namespace as having subpages any more.

It's not helped by the config being in such a mess to begin with - why was the config set to false (ignoring the fact it was always overridden!)

For starters, I thought I already merged https://gerrit.wikimedia.org/r/#/c/46826/ which makes it clearer. Apparently not.

Remaining wrong overrides removed in https://gerrit.wikimedia.org/r/47215

Should be fixed now...

lambdav wrote:

It seems to be fixed now.
Thanks.