Page MenuHomePhabricator

Allow filtering of WhatLinksHere to remove links from templates
Open, Needs TriagePublicFeature


A top wish from Community-Wishlist-Survey-2022 , which (strikingly) does not yet appear to be filed in Phabricator, although I found a declined task T7388 from 2006 which asked for something very similar.

From the Wishlist proposal:

Problem: When using Special:WhatLinksHere, many of the results aren't in the body of the article, and are just from templates (especially navboxes) - this often makes finding results in the content of an article much more difficult than it needs to be.
Who would benefit: Editors (and readers) who use Special:WhatLinksHere.
Proposed solution: Special:WhatLinksHere already has (redirect) and (transclusion): add (template link), with a toggle to hide/show results that only link here from links in templates. Ideally, show the results nested in the same way that (redirect) links are - so if a template links to the article, show all articles beneath that.

Some challenges:

  • The MediaWiki parser expands templates before even beginning to process links. Therefore, by the time links are processed, information on transclusions is lost.
  • Is it worth recording which transcluded template is responsible for each link? This is not asked for in the wishlist proposal.
  • Consideration needs to be given to what happens to links provided in parameters. For example, {{blockquote|I really only listen to, like, [[German death reggae]] and [[Halloween]] sound effects records from the 1950s. And [[Bette Midler]].}} Technically these links are being generated by the template, but editors would consider them just like ordinary links in the body of the page.
  • From a data storage standpoint, a pl_type bitfield could be added to the pagelinks table. However, it is undesirable to ALTER pagelinks due to its vast size on large wikis (1.5 billion rows on enwiki) - see @tstarling's comment under Option 3 in T14019#7662302.

Event Timeline

Maybe the link tagging component can be done in Parsoid. Then we can do the LinksUpdate component after we have Parsoid read views.

Also related: T268526#9594281 which proposes to decouple/restructure how dependency tracking is done. In theory if LinksUpdate wasn't using ParserOutput::addTemplate() we could have a bit more freedom in restructuring how that dependency tracking is done. Right now Parsoid isn't used in any LinksUpdate jobs (except for the "prewarm cache jobs" maybe?) so this would be blocked on T310512: Parsoid and the legacy parser should emit exactly the same ParserOutput metadata.