@Krinkle has proposed a potential solution at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1146663 a couple days ago: Include #ifexist targets in "Templates used on this page" when editing.

That’s useful, but not for my use case: it’s the other way round – it answers the question “which pages’ existence does the current page query?” but my question is “which pages query the existence of the current page?”.

Change #1146663 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] Include `#ifexist` targets in "Templates used on this page" when editing

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

I see three use cases here:

• (New) User interface for outgoing transclusion-like links, i.e. at "Templates used on this page" when editing.
  • #ifexist was historically not included here, but adding it seems useful and helps with transparency, discoverability, and debugging.
• (Restore) User interface for incoming ifexist link, i.e. Special:WhatLinksHere.
  • This was previously available there as a fake pagelink. This had the side effect of populating Special:WantedPages, however we could include it now purely as an existence check, possibly through the existing UI checkbox for template usage / transclusions, or by adding a new checkbox.
• (Restore) API for incoming ifexist link, e.g. ApiQueryBacklinks.
  • Idem. Previously there as fake entry under "backlinks". Similarly could be handled through embeddedin (and expand the query to page through two tables, like WhatLinksHere), or by adding a fourth list type besides "backlinks", "embeddedin", and "imageusage".

And I scoped this task to (either or both of) the latter two.

Similarly to my comment on your patch, I think these shouldn’t group existence links and templates together, since they are different by nature, so I’d add a new checkbox. The API is less straightforward, as the four types that are nicely grouped together on Special:WhatLinksHere are four (actually five) completely separate query modules (list=backlinks/prop=linkshere, list=embeddedin, prop=redirects and list=imageusage; note that some use list while others use prop); I’d love to unify them, but I’m wary of deprecating such basic modules, and having three modules to query (normal) backlinks is a great way to increase tech debt…

While it’s out of the scope of this task, there’s actually a fourth use case, making the matrix complete:

• (Restore) API for outgoing ifexist links
  • This was provided by the prop=links query module. I’m not sure how useful it is, though.

The only real use case out here seem to be the entries in Special:WantedPages, which could be brought back by modifying the special page logic. I doubt we need to complicate core UIs like WhatLinksHere for such a niche use case. Power users who really rely on it could use some user script that reads from the API.

In T395366#10873040, @Tacsipacsi wrote:

The API is less straightforward, as the four types that are nicely grouped together on Special:WhatLinksHere are four (actually five) completely separate query modules (list=backlinks/prop=linkshere, list=embeddedin, prop=redirects and list=imageusage; note that some use list while others use prop); I’d love to unify them, but I’m wary of deprecating such basic modules, and having three modules to query (normal) backlinks is a great way to increase tech debt…

They're already unified in the code. There's no reason to unify them from a user-facing perspective, as they are different things after all. It's easy to add list=ifexistusage as a new query module.

In T395366#10891391, @SD0001 wrote:

The only real use case out here seem to be the entries in Special:WantedPages

Why? The premise of this whole change was that these entries are useless on Special:WantedPages, yet they flood it. I can agree with this; I don’t see any use case for querying all #ifexist: calls returning false on the entire wiki.

Power users who really rely on it could use some user script that reads from the API.

I prefer a UI, but I’d be fine with the API alone, if it existed. But it doesn’t.

They're already unified in the code.

I doubt there’s a unified code for all five modules serving four purposes.

There's no reason to unify them from a user-facing perspective, as they are different things after all.

They’re all backlinks. If I want to see all pages that refer to a page, I’m not interested in how many database tables are queried for that.

It's easy to add list=ifexistusage as a new query module.

It comes with a lot more bookkeeping: more messages to translate, more data to store about the modules in downstream code like Pywikibot.

Just want to note that up to four Action API modules should be added:

1. A prop module to list existencelinks of a page, similar to these.
2. A prop module to list existencelinks coming into a page, similar to these.
3. Possibly a list module to list all existencelinks, similar to these (but see T364617).
4. Possibly a list module to list existencelinks coming into a page, similar to these. IMO those are probably redundant to the prop modules in #2, but it's probably not too hard to add for completeness.

I'd not try to include the existencelinks into existing props like prop=links and prop=linkshere or prop=templates and prop=transcludedin. That would complicate the code and prevent people who have need of differentiating them from easily doing so, and would kind of defeat the purpose of adding the separate table in the first place.

(This should have a core project since a core patch is proposed)