Topic on Extension talk:QuickInstantCommons

Hi, hopes you are doing well.

This extension is a life saver, and absolutely the best extension for commons, I've tried it and it works like magic.

I have a small issue related to thumbs, if another api repo is used, for instance:

'apibase' => 'en.wikipedia.org/w/api.php',

then:

'thumbUrl' => 'upload.wikimedia.org/wikipedia/commons/thumb',

It won't load thumbs of en.wikipedia.org when the image is only available for that particular wiki(en), where the thumb url has to be like:

upload.wikimedia.org/wikipedia/en

instead of

upload.wikimedia.org/wikipedia/commons

At the same time, all thumbs that are presented on commons are just loading fine.

changing the thumbUrl to upload.wikimedia.org/wikipedia/en solved the problem of thumbs on en.wikipedia but created another problem for thumbs on commons, and thumbs on commons will not load because of url.

This sounds a bit tricky to me, you might be able to solve it, since you are the master of this extension. Thank you very much.

Oh hmm, i forgot about the case where there are layered repos like wikipedia.

If you set transformVia404 => false it should work for this case, but it won't be as fast (should still be an improvement over mediawikis built in support, but not quite by the same amount)

Is it a bug that you have to work it out, or additional feature that need to take place? Thank you

By the way Setting transformVia404 => false, killed the performance, it's just like normal instant commons now.

Hi,

I made a new version of the extension.

In the new version, if you set thumbUrl to false, it should auto-detect the proper one and work in this situation even when transformVia404 is true (so at full speed).

I also fixed the description fetching, so it should now be able to fetch descriptions form both commons and wikipedia.

Thank you very much. I will try it now

Things are great, i have one more issue related to local images, it is a case were images are stored on local wiki, those images are not loading at all. can you try to address this issue please. for instance, images from commons, wikipedia are working, but local images not.

That's odd, the extension shouldn't affect local images in any way.

I tried on my test wiki, and local images seem to work fine.

Can you check to make sure that when you disable the extension, local images start to work again (In order to rule out other causes).

Are there any php errors or warnings being generated?

Do you have any non-default settings for local images (In case there is some weird interaction)

If you go to mywiki.com/w/thumb.php?f=Local_File_Name_with_No_namespace.png&w=102 - does it thumbnail the image. If it doesn't, does it give a specific error message?

You are right, that was because of one setting, that changed the url. xd;

#$wgUploadPath = "$wgScriptPath/img_auth.php";

all went back to normal after disabling it

I noticed another issue related to image that is redirected to another image in commons,

for instance: if you call File:Lua-logo-nolabel.svg, which is redirecting to File:Lua-Logo.svg, image will not show, it looks like it is fetching the wrong thumb or url of the old file:

upload.wikimedia.org/wikipedia/commons/thumb/6/6a/Lua-logo-nolabel.svg/300px-Lua-logo-nolabel.svg.png

while it has to fetch this file

upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Lua-Logo.svg/30px-Lua-Logo.svg.png

hmm. The MediaWiki api doesn't seem to report the image is redirect if its not local. (e.g. compare https://en.wikipedia.org/w/api.php?titles=File%3ALua-logo-nolabel.svg&iiprop=timestamp%7Cuser%7Ccomment%7Curl%7Csize%7Csha1%7Cmime%7Cmediatype&prop=imageinfo&format=json&action=query&redirects=true&uselang=en vs https://commons.wikimedia.org/w/api.php?titles=File%3ALua-logo-nolabel.svg&iiprop=timestamp%7Cuser%7Ccomment%7Curl%7Csize%7Csha1%7Cmime%7Cmediatype&prop=imageinfo&format=json&action=query&redirects=true&uselang=en ) so the extension doesn't realize that the file is a redirect, and gets confused.

I tried filing phab:T298358 but I'm not hopeful that it will be fixed anytime soon, so I'll have to try and think of some other work-around.

Ok, i think i found a work around, try the new version.

I am really sorry Bawolff, i didn't meant to make all this troubles to you. I've read the phabricator post, i which this can be implemented soon. your solution is working and tested. I will keep an eye on this extension and report to you.

No problem at all. I'm just happy someone is using it and testing it.

This should really become part of core. Page that was loading slowly and caused timeouts for backend cache response is no longer issue. Is this also speeding up Preview extension?