Page MenuHomePhabricator

API imageinfo query returns no imageinfo data when asking for redirect and redirect target
Closed, ResolvedPublic


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: *|File:HellobyartistJasonThompson2.jpg

  • Results for imageinfo: *|File:Example.jpg|File:Universidad%20del%20Tolima%20logo.jpg&redirects

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:47 PM
bzimport set Reference to bz31849.

I get still:|File:HellobyartistJasonThompson2.jpg

<?xml version="1.0"?>

    <page pageid="15077304" ns="6" title="File:HellobyartistJasonThompson.jpg" imagerepository="" />
    <page pageid="15087902" ns="6" title="File:HellobyartistJasonThompson2.jpg" imagerepository="" />


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...

rd232 wrote:

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.

Bryan.TongMinh wrote:

I think this will also be fixed by 39852.

Bryan.TongMinh wrote:

i.e., I748e5223

Bryan.TongMinh wrote:

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.