Inline links to files are no longer being registered in the link table or image table, or anywhere apparently
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• bzimport
	Dec 26 2008, 11:36 PM

Description

Author: carnildo

Description:
Visit the URL http://en.wikipedia.org/w/api.php?action=query&prop=links&titles=User:Carnildo/sandbox7

Expected result:
<?xml version="1.0"?>
<api>

<query>
  <pages>
    <page pageid="2014995" ns="2" title="User:Carnildo/sandbox7">
      <links>
        <pl ns="6" title="File:Example.png" />
      </links>
    </page>
  </pages>
</query>

</api>

Actual result:
<?xml version="1.0"?>
<api>

<query>
  <pages>
    <page pageid="16393778" ns="2" title="User:Carnildo/sandbox7" />
  </pages>
</query>

</api>

Version: 1.14.x
Severity: normal

Details

Reference: bz16806

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:24 PM

• bzimport added a project: MediaWiki-File-management.

• bzimport set Reference to bz16806.

• bzimport created this task.Dec 26 2008, 11:36 PM

herd wrote:

This is not the API's fault. Escaped image links are no longer being registered either as images nor as links. This can be verified by linking an image with [[:File]] or [[:Image]] and checking that such a link creates no backlink on the image description page, and no link on Special:Whatlinkshere. NOTE: This is only the case if the file/page exists. If not, the link _is_ registered. This is similar to how Special: page links are now registered if there is no such Special: page, like [[Special:Foobarbazlalala]] will register a NS_SPECIAL pagelink.

Possibly due to related Image->File refactoring. Moving out of API component and resumming, removing some CCs too (since the API peeps probably don't care).

Note: This was reported December 18th in #wikimedia-tech and I told the reporter to open a new bug. I can not find the new bug but if they did create one this may need duping.

Should be fixed in r45174.

*** Bug 16837 has been marked as a duplicate of this bug. ***

Regression seems to be due to changes in what Title::isAlwaysKnown() checks -- it used to pretty much only tackle off-wiki stuff and Specials, things which we're *not* supposed to record in link tables.

The fix in r45174 is insufficient as it only checks the file case; we've got several other things borked:

MediaWiki: links are not recorded
Non-existent special pages *are* recorded

Patched this up in r45266.

Fixes other cases broken by Parser's assumptions failing to hold after change in Title::isAlwaysKnown()'s behavior:

Links to invalid Special: pages were being recorded, but shouldn't
Links to valid MediaWiki: pages were no longer recorded

Instead of the NS_FILE special-case in r45174, I'm just tossing *all* isAlwaysKnown links over to ParserOutput::addLink(), and letting the latter worry about what types of titles it won't record.
Just for good measure, in case any NS_MEDIA titles make it into ParserOutput::addLink() they'll be normalized to NS_FILE.

Cf bug 16162.

• Gilles added a project: Multimedia.Dec 4 2014, 10:44 AM

• Gilles moved this task from Untriaged to Done on the Multimedia board.

Inline links to files are no longer being registered in the link table or image table, or anywhere apparentlyClosed, ResolvedPublicActions

Description

Details

Event Timeline

Inline links to files are no longer being registered in the link table or image table, or anywhere apparently
Closed, ResolvedPublic
Actions