Page MenuHomePhabricator

behavior switch needed to disable links to parent pages from subpages
Open, LowestPublic

Description

MediaWiki needs a behavior switch (such as __NOPARENTLINK__) to disable the automatic link from a subpage to its parent page.

Use cases include WikiProjects that use tab templates, where the first tab is the parent page and the others are subpages. The parent page links on all but the first tab cause the whole navigation framework to shift as users navigate from the main page to the subpages and back.

See: http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Military_history

Other use cases include pages intended for newcomers where it is desirable to limit unnecessary links as much as possible.


Version: 1.21.x
Severity: enhancement

From T120758

Wikibooks uses Subpages in order to structure a book in chapters. Wikiversity does the same for a course and lessons. Each subpage shows links to ancestor pages automatically. Nevertheless the authors offer to navigate between chapters and the content page using navigational templates. In these cases, you see the link to the ancestor page as well as the navigation bar -- e.g. b:en:Geometry for Elementary School/Introduction. I'ld prefer to suppress the automatically created link if a navigation bar is shown. Double information may disturb users.
Users: Wikibooks, Wikiversity and other projects that use subpages. Current situation: Links to ancestor pages can't be suppressed. Solution: Add a behavior switch NOANCESTORLINK or something like that. --
Juetho (talk) 10:45, 18 November 2015 (UTC)
This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey
This proposal received 7 support votes, and was ranked #78 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Reading#Subpages:_suppress_links_to_ancestor_pages

Details

Reference
bz39395
Related Gerrit Patches:

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:52 AM
bzimport set Reference to bz39395.
bzimport added a subscriber: Unknown Object (MLST).
Ragesoss created this task.Aug 15 2012, 9:57 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 13 2016, 10:14 AM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 7 2016, 11:07 AM
Jdforrester-WMF lowered the priority of this task from Normal to Lowest.May 7 2016, 11:12 AM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Adding new behavioural switches adds complexity for users (new things to remember), for software (new checkboxes/etc. with which to prompt users), and the servers (more complex parsing), so it needs to pass a pretty high bar in terms of value when it comes to their features. Though I see the two use cases given (in the description and in the merged task), I'm not sure this is sufficiently valuable to do, and am minded to Decline. Thoughts?

Ricordisamoa raised the priority of this task from Lowest to Normal.May 7 2016, 11:13 AM
Ricordisamoa lowered the priority of this task from Normal to Lowest.
Ricordisamoa updated the task description. (Show Details)

Edit conflict...

Change 257624 had a related patch set uploaded (by Ricordisamoa):
[POC] Implement NOANCESTORLINK magic word

https://gerrit.wikimedia.org/r/257624

Danny_B updated the task description. (Show Details)May 10 2016, 3:51 AM
Danny_B added a subscriber: Danny_B.

Adding new behavioural switches adds complexity for users (new things to remember), for software (new checkboxes/etc. with which to prompt users), and the servers (more complex parsing), so it needs to pass a pretty high bar in terms of value when it comes to their features. Though I see the two use cases given (in the description and in the merged task), I'm not sure this is sufficiently valuable to do, and am minded to Decline. Thoughts?

IIRC there was some request for Tabs extension, so the first usecase would be better handled by the extension itself, which would take care of disabling the autonavigation. (Speaking about extension, how does actually Breadcrumbs extension deal with that?) Beside that, if all wikiprojects do use the same style of navigation, there can be easy CSS written for that. CSS can be written even for certain list (but that's not scalable though). Javascript gadget could also work...

The latter example could be solvable by JS gadget. Or with CSS like above, though in this case it will be the second alternative - un-pretty-scalable growing list.

From the accessibility point of view, the navigation should be consistent across all pages on site, so introducing various different ways is rather disruptive.

Also, all usecases basically dealt only with first level of subpages, but the automatic subpage navigation automatically links all the way down.

Given the reasons above, I am also in favour of declining of this.

Framawiki moved this task from Backlog to Doing on the good first bug board.Dec 2 2017, 1:37 PM