Page MenuHomePhabricator

user talk page reports redirect to wrong page
Closed, InvalidPublic


Both the linkshere and backlinks API endpoints (why do both exist?) report that w:User talk:RjwilmsiBot redirects to w:Ruben Correa, when in fact it is a redirect to w:User talk:Rjwilmsi. At this revision a CSD tag was added to the talk page that links to Ruben Correa, so apparently the API is searching the entire text for links and not just the one that forms the redirect.

Event Timeline

AzaToth raised the priority of this task from to Needs Triage.
AzaToth updated the task description. (Show Details)
AzaToth added a project: MediaWiki-Action-API.
AzaToth added a subscriber: AzaToth.
AzaToth set Security to None.
AzaToth removed a subscriber: MusikAnimal.
TTO claimed this task.
TTO added a subscriber: TTO.

I don't think there is anything to fix in MediaWiki:

  • Twinkle should use prop=redirects instead of list=backlinks.
  • The Rjwilmsibot talk page is a redirect page that has a backlink to Ruben Correa, which is what Twinkle is asking for, so the API response is correct.

TTO already answered the main issue here (use prop=redirects if you want pages that redirect to a title, that's why it exists), but there's a passing question that wasn't answered:

Both the linkshere and backlinks API endpoints (why do both exist?)

'backlinks' came first and is limited to only one title at a time, which isn't particularly convenient in many cases. I can only guess that at the time it was written it either wasn't possible for MySQL to have a well-performing query over multiple input titles for the feature or the people writing the code just weren't aware of one.

Once I figured out such a query, I created 'linkshere' as a prop module to take advantage of it. I couldn't change 'backlinks' since doing so would have broken far too many existing uses. The same goes for 'transcludedin' versus 'embeddedin' and 'fileusage' versus 'imageusage'.