Last modified: 2011-06-05 10:39:31 UTC
Since 1.17 the API output for action=query&prop=imageinfo&iiprop=url returns false in the 'descriptionurl' property of the imageinfo object. See the following two urls of en.wikipedia (MW 1.17) * (shared) http://en.wikipedia.org/w/api.php?format=jsonfm&action=query&titles=File:Albert%20Einstei%20Head.jpg&prop=imageinfo&iiprop=url%7Cmime&iiurlwidth=200 * (local) http://en.wikipedia.org/w/api.php?format=jsonfm&action=query&titles=File:BahamasCoin.jpg&prop=imageinfo&iiprop=url%7Cmime&iiurlwidth=200 compared t the following two urls of test2.wikipedia (MW 1.16) * (shared) http://test2.wikipedia.org/w/api.php?format=jsonfm&action=query&titles=File:Albert%20Einstein%20Head.jpg&prop=imageinfo&iiprop=url%7Cmime&iiurlwidth=200 * (local) http://test2.wikipedia.org/w/api.php?format=jsonfm&action=query&titles=File:030a%20Shrady%20portrait.tiff&prop=imageinfo&iiprop=url%7Cmime&iiurlwidth=200 According to Bawollf (via IRC) in the MW PHP source code it says getting descriptionurl may return false if it's not applicable or when it's unavailable. However the description for the url should be available just fine, just like it was fine in 1.16. This is currently affecting the highly used gadget 'Navigation popups', which, when hovering a link to an article shows the excerpt of an article and the first image. Whenever that image is a local file the anchor-tag around the image will link to 'false' and when hovering the thumb it'll show the excerpt of [[false]]. It will undoubtly screw up many other uses of the API.
Looking at the wmf config files, it has an entry: $wgLocalFileRepo = array( 'class' => 'LocalRepo', 'name' => 'local', 'directory' => $wgUploadDirectory, 'url' => $wgUploadBaseUrl ? $wgUploadBaseUrl . $wgUploadPath : $wgUploadPath, 'hashLevels' => 2, 'thumbScriptUrl' => $wgThumbnailScriptPath, 'transformVia404' => true, 'initialCapital' => $wgCapitalLinks, 'deletedDir' => "/mnt/upload6/private/archive/$site/$lang", 'deletedHashLevels' => 3, 'thumbDir' => str_replace( '/mnt/upload6', '/mnt/thumbs', "$wgUploadDirectory/thumb" ), ); This doesn't include scriptDirUrl, like the equivalent definition in Setup.php. I think this causes FileRepo::getDescriptionUrl to fail on local images on wmf wikis. However, with that said, I'm at a loss as to why it would work on test2. (and why this just started breaking)
As an aside, if the file->getDescriptionUrl returns false, we should probably just not output that field, instead of saying its value is a literal 'false'. (That's a separate issue, since local images should have desc page).
Appears to be caused by r70296. However, I think the appropriate course of action would be for Wikimedia to change its declaration of $wgLocalFileRepo to more match the default in Setup.php. Changing to a shell bug.
(In reply to comment #2) > As an aside, if the file->getDescriptionUrl returns false, we should probably > just not output that field, instead of saying its value is a literal 'false'. > (That's a separate issue, since local images should have desc page). or maybe not. Its giving a boolean value of false in json, not a literal string of a false, so maybe its not that inappropriate to return that (I don't really know). in the xml format it returns an empty descriptionurl attribute.
The boolean false is fine, that is, if there really isn't a description url available. The fact that NavPopups link to [[false]] is most likely because it doesn't check it and <code>var foo = '[[' + false /* boolean false, without quotes */ + ']]'; </code> gives '[[false]]'.
bawolff+wn@gmail.com 2011-02-26 20:07:03 UTC > Keywords +shell > Component -API +Site requests > Product -MediaWiki +Wikimedia > Summary -[Regression!] 'description' imageinfo propety is 'false' for local files > + Wikimedia's declaration of $wgLocalFileRepo doesn't include scriptDirUrl and scriptExtension options Are you sure it's wikimedia dependant and not a bug in MediaWiki ? If it can happen at Wikimedia with an upgrade, it can happen to others as well I guess.
Bug 27477
Marking as dupe, FileRepo should just be able to interpolate this stuff. *** This bug has been marked as a duplicate of bug 27477 ***
