Last modified: 2013-04-22 16:17:04 UTC
I can't say more than that I have a query which asks for imageinfo of multiple files. And API does not return ImageInfo for File:HellobyartistJasonThompson.jpg despite it should. 1) File:HellobyartistJasonThompson.jpg exists 2) File:HellobyartistJasonThompson2.jpg is a redirect to 1) 3) File:Example.jpg exists 4) File:Universidad del Tolima logo.jpg 5) File:Arc 23468.jpg is a redirect to 4) * No results for imageinfo: * http://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:HellobyartistJasonThompson.jpg|File:HellobyartistJasonThompson2.jpg * Results for imageinfo: * http://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:HellobyartistJasonThompson.jpg http://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:HellobyartistJasonThompson.jpg|File:Example.jpg http://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:Arc%2023468.jpg|File:Universidad%20del%20Tolima%20logo.jpg&redirects
Unfortunately the new title even does not reflect the problem: Works fine: http://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:Arc%2023468.jpg|File:Universidad%20del%20Tolima%20logo.jpg Or did I miss something?
I get still: http://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:HellobyartistJasonThompson.jpg|File:HellobyartistJasonThompson2.jpg <?xml version="1.0"?> <api> <query> <pages> <page pageid="15077304" ns="6" title="File:HellobyartistJasonThompson.jpg" imagerepository="" /> <page pageid="15087902" ns="6" title="File:HellobyartistJasonThompson2.jpg" imagerepository="" /> </pages> </query> </api>
That is WEIRD. Leaving off the second file from &titles= does result in the proper imageinfo.
It really should be returning results for the redirect too though, shouldn't it? See also bug 32031 -- problems with {{#ifexist}} and image redirects...
Is the same as (or related to) Bug 23750 - &redirects doesn't work properly with prop=imageinfo?
(In reply to comment #5) Only partial. Here we have another bug: No imageinfo for both: The redirect and the target. And this does not happen on other files. Just test the examples given in the description (comment 0).
I see the problem here. The call to RepoGroup::singleton()->findFiles() returns an associative array mapping the redirect *target* to the image object; the image object refers back to the original title queried. So what happens is that it first looks up File:HellobyartistJasonThompson.jpg, and fills in a mapping in the result array for "File:HellobyartistJasonThompson.jpg" to an image object whose getOriginalTitle() returns File:HellobyartistJasonThompson.jpg. Then it looks up File:HellobyartistJasonThompson2.jpg, and since that redirects to File:HellobyartistJasonThompson.jpg it fills in "File:HellobyartistJasonThompson.jpg" again in the result array, overwriting the old image object with a new one whose getOriginalTitle() returns File:HellobyartistJasonThompson2.jpg. Then when the API module is iterating over the results, it pulls getOriginalTitle() getting File:HellobyartistJasonThompson2.jpg, sees it's a redirect, and skips inserting the image info into the output. It never sees a result for File:HellobyartistJasonThompson.jpg at all, so that also gets no image info. One fix would be to have RepoGroup::singleton()->findFiles() (and the related findFiles() methods on the individual groups) return results mapped from the queried title rather than the redirect target title, so a redirect wouldn't overwrite the original image object. But I don't know what else that might break. Or findFiles() could prefer to keep the non-redirect image object rather than whichever happened to be queried last. Or the API module could iterate over the queried titles instead (and look them up in the $images array), ignoring getOriginalTitle() completely. Or it could take the key from $images and pass it through Title::newFromDBkey, again ignoring getOriginalTitle() completely. I'm not sure which method would be best.
I think this will also be fixed by 39852.
i.e., I748e5223
That is, I27485bba. Sorry for the mails.
(In reply to comment #8) > I think this will also be fixed by 39852. No, it's not.
Change I0b298290 should fix it, and bug 36751 in a more straightforward manner.
Merged.