Page MenuHomePhabricator

“What links here” does not work for objects
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
A short list of pages is displayed, but no functions or other objects.

What should have happened instead?:
All objects that have a direct Reference to the object should be listed. In particular, Persistent objects Z41 and Z42 should be listed as linking to Z40.

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
This capability was supposedly provided by T284694, which is shown as Resolved. I have been unable to find any task for limiting or removing the capability, which is why I am reporting this as a Bug.

I can see that some objects (especially Types) could have an excessive number of links, but links between Functions via Compositions are a high priority, in my opinion, as will be links to custom Types (although changes proposed under T359672 may be an appropriate alternative).

Event Timeline

Notes as I'm debugging:

  • We manually add links in ZObjectContentHandler::fillParserOutput, via ParserOutput::addLink(), which is what we're meant to do.
  • These are then meant to go into the page link tables via PageLinksTable::setParserOutput() which calls ParserOutput::getLinks().
  • I've manually confirmed in production that our ParserOutput objects indeed do have these links in them.
  • However, these are indeed not showing up on Special:WhatLinksHere (but other links are).
  • Pulling the data in prod, [[Z801]] as of writing has:
[
[ "Z881" => 192, "Z17" => 19, "Z1" => 3, "Z1002" => 232, "Z1157" => 383, "Z1025" => 251, "Z1014" => 240, "Z20" => 21, "Z8010" => 1141, "Z8011" => 1142, "Z8012" => 1143, "Z8013" => 1144, "Z14" => 18, "Z901" => 200, "Z801" => 169, ],
]
    • … but e.g. Special:WhatLinksHere/Z881 doesn't list Z801, or any NS_MAIN objects at all.
  • As a gut-check, [[Wikifunctions:Status]] has:
[
0 => [ "Z10000" => "1186", "Z811" => "176","Z881" => "192",],
4 => ["Report_a_technical_problem" => "1175",],
]
    • … so they're in the same format (it's ignoring the implicit 0 => in the first level when there are no secondary keys)
  • Somehow the content is ignored and other links instead?
  • Z801 is page ID 169 (you can see this on action=info as well as from $title->getId()); SELECT * FROM pagelinks WHERE pl_from = 169 returns no results at all.

🤔Why isn’t the page ID quoted?

🤔Why isn’t the page ID quoted?

In my sample SQL? It's a raw number, not a string.

Note that SELECT * FROM pagelinks WHERE pl_from_namespace = 0 LIMIT 10; does return some results, and those do indeed get populated – page 17185, which is Z11735, has three outbound links, to pages Z20, Z866, and Z11834, and indeed it shows up:
https://www.wikifunctions.org/wiki/Special:WhatLinksHere/Z20

… so maybe this is just stale data that has been wrongly cached?

In the Z801 data, the page IDs are unquoted; in the Wikifunctions:Status data, they are quoted 🤷‍♂️

In the Z801 data, the page IDs are unquoted; in the Wikifunctions:Status data, they are quoted 🤷‍♂️

Oh, huh, you're right. I don't think that should make a difference, but perhaps it does? We're just handing addLink() a Title object.

However, @Bawolff has pointed out that LinksUpdate asks for a non-HTML PO, which we do an early-return on. Let's fix that…

Change #1037570 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/WikiLambda@master] ZObjectContentHandler::fillParserOutput: Add links before early return

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

Jdforrester-WMF changed the task status from Open to In Progress.May 30 2024, 4:35 PM
Jdforrester-WMF claimed this task.

Change #1037570 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] ZObjectContentHandler::fillParserOutput: Add links before early return

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

Once this rolls out, it should hopefully slowly fix all the missing data, as each Object is re-parsed (when visited out of cache, or more swiftly, when edited).

This comment was removed by GrounderUK.

Effect of “Recent changes”:

https://www.wikifunctions.org/wiki/Special:WhatLinksHere/Z14711 now links back to:

https://www.wikifunctions.org/wiki/Special:WhatLinksHere/Z15907 shows links to new and amended Implementations but not Test cases or an unaltered Implementation (Z15911). A new test (Z16807) appears immediately as a backlink and has no backlinks. After being connected to the function, the new test has a backlink to it.

Editing a function’s description results in backlinks from its Implementations and Test cases (see, for example: https://www.wikifunctions.org/wiki/Special:WhatLinksHere/Z13472).

https://www.wikifunctions.org/wiki/Special:WhatLinksHere/Z16793 (a new function) shows links to both its Implementation and its Test cases. These link back to the new function. The functions called by the Implementation [Z16667, Z16728] link back to it.

We are beginning to get some Z18 backlinks from new and revised compositions, like Z16806 (new) and Z15910 (revised).

Z15910 also has a Z13518 backlink (since it refers to a literal Natural number). Z16806 has no such backlink (since it refers to Natural number arguments only by Argument reference).

https://www.wikifunctions.org/w/index.php?title=Special:WhatLinksHere/Z16659&limit=50&offset=0%7C31723&dir=prev is looking good.

Still missing T345457 but a single-click workaround is available. Documented in https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Status&diff=prev&oldid=108273 (probably in the wrong place now).