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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
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...
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Brion Vibber
: 16837 (view as bug list)
Depends on:
  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: ---


Description carnildo 2008-12-26 23:36:42 UTC
Visit the URL

Expected result:
<?xml version="1.0"?>
      <page pageid="2014995" ns="2" title="User:Carnildo/sandbox7">
          <pl ns="6" title="File:Example.png" />

Actual result:
<?xml version="1.0"?>
      <page pageid="16393778" ns="2" title="User:Carnildo/sandbox7" />
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.