Page MenuHomePhabricator

[Regression!] ImageInfo API query returns descriptionUrl = false if file comes from local repository
Closed, ResolvedPublic

Description

Compare the output of the two following queries:

http://commons.wikimedia.org/w/api.php?action=query&titles=File:Albert%20Einstein%20Head.jpg&prop=imageinfo&iiprop=url&format=jsonfm

http://en.wikipedia.org/w/api.php?action=query&titles=File:Albert%20Einstein%20Head.jpg&prop=imageinfo&iiprop=url&format=jsonfm

The file resides at the Commons. When the query is run at the Commons, descriptionurl is false; when run at the English Wikipedia, it is set correctly to the file description page at the Commons.

Trying the same query for a file that actually is at en-WP:

http://en.wikipedia.org/w/api.php?action=query&titles=File:Kouprey%20at%20Vincennes%20Zoo%20in%20Paris%20by%20Georges%20Broihanne%201937.jpg&prop=imageinfo&iiprop=url&format=jsonfm

Again descriptionurl is false.


Version: unspecified
Severity: normal

Details

Reference
bz27477

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:22 PM
bzimport added a project: MediaWiki-API.
bzimport set Reference to bz27477.
Lupo created this task.Feb 16 2011, 10:42 PM

To me, in the code, it looks to be done purposefully, but I can't swear to it.

Hopefully Bryan can confirm either way, and fix if it is an issue.

Lupo added a comment.Feb 17 2011, 6:42 AM

If it's intended behavior that the descriptionurl is always false for local files, fine by me, but then please document it. I just reported it because prior to the switch to 1.17 at the Commons, it was set.

Bryan.TongMinh wrote:

This is a bug.

Bryan.TongMinh wrote:

Most likely caused by r68897, but I can't reproduce it locally... interesting.

Bryan.TongMinh wrote:

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

(In reply to comment #5)

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

Adding the same tags/blockers from the dupe-marked bug bug 27749

Bryan.TongMinh wrote:

I'm reading the code from 1.16wmf4 and I wonder how this could have ever worked.

Bryan.TongMinh wrote:

r70296 is to blame

Bryan.TongMinh wrote:

Fixed in r83114.