Last modified: 2010-07-04 17:19:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18806, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16806 - Inline links to files are no longer being registered in the link table or image table, or anywhere apparently
Inline links to files are no longer being registered in the link table or ima...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.14.x
All All
: Normal normal (vote)
: ---
Assigned To: Brion Vibber
:
: 16837 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-26 23:36 UTC by carnildo
Modified: 2010-07-04 17:19 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description carnildo 2008-12-26 23:36:42 UTC
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>
Comment 1 Splarka 2008-12-27 05:03:53 UTC
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.
Comment 2 Alex Z. 2008-12-30 05:35:22 UTC
Should be fixed in r45174.
Comment 3 Ilmari Karonen 2008-12-30 16:40:02 UTC
*** Bug 16837 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2008-12-31 23:49:56 UTC
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
Comment 5 Brion Vibber 2009-01-01 00:05:48 UTC
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.
Comment 6 Brion Vibber 2009-01-01 00:23:30 UTC
Cf bug 16162.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links