Extension talk:QuickInstantCommons

About this board

This commons files not working on either wikis?? help!

2
ThatRobloxianuser2K6 (talkcontribs)

I keep getting this No file by this name exists message whlist entering file:flag of italy.svg page on this wikis, so any fix this!?!?!?!??! can you someone help me pls!

Bawolff (talkcontribs)

The i in Italy needs to be capitalized

Reply to "This commons files not working on either wikis?? help!"
Nicole Sharp (talkcontribs)

Accessing "[[special:specialpages]]" when both InstantCommons and QuickInstantCommons are enabled produces the following error message:

"Internal error: [ZB4h8wFwXxIU-rLZVpSjQQAAAAE] 2023-03-24 22:19:32: Fatal exception of type 'LogicException'".

What I think happened is that I had MediaWiki initially configured with InstantCommons disabled and QuickInstantCommons enabled, using "$wgForeignFileRepos" to access content from Wikimedia Commons. I then disabled "$wgForeignFileRepos" for Wikimedia Commons and enabled InstantCommons instead, which apparently broke the QuickInstantCommons extension. I'll leave the configuration to use "$wgForeignFileRepos" instead of InstantCommons for accessing Wikimedia Commons content, but this appears to be a bug with QuickInstantCommons that prevents switching back and forth between InstantCommons and "$wgForeignFileRepos" for accessing Wikimedia Commons content. I am using MediaWiki 1.39.2 with PHP 8.2.0.

Nicole Sharp (talk) 22:28, 24 March 2023 (UTC)

Bawolff (talkcontribs)

Its kind of unclear what you did here, but if you are using both [normal] instant commons and QuickInstantCommons, at least one of them has to be setup via $wgForeignFileRepos (Doesn't matter which, could be both), and the two of them have to have separate repo names. If you are setting one up with $wgForeignFileRepos you must ensure the repo name you chose is different from the repo name that is automatically setup for the other one.

If you use the same repo name in $wgForeignFileRepos for more than one foreign file repo, an error will be generated (Potentially this one, but set $wgShowExceptionDetails = true; to be sure).

Nicole Sharp (talkcontribs)

Below is the syntax from "LocalSettings.php" that produces the error. InstantCommons is enabled but the "ForeignFileRepos" for Wikimedia Commons is disabled. Disabling InstantCommons and un-commenting "ForeignFileRepos" for Wikimedia Commons resolves the error.

# To enable image uploads, make sure the "images" directory is writable, then set this to true:
$wgEnableUploads = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";

## https://www.mediawiki.org/wiki/manual:$wgUploadDirectory
$wgUploadDirectory = "{$IP}/uploads";
## https://www.mediawiki.org/wiki/manual:$wgUploadPath
$wgUploadPath = "$wgScriptPath/uploads";

# InstantCommons allows wiki to use images from: https://commons.wikimedia.org/
$wgUseInstantCommons = true;
## https://www.mediawiki.org/wiki/InstantCommons

# https://www.mediawiki.org/wiki/Extension:QuickInstantCommons
wfLoadExtension( 'QuickInstantCommons' );

# https://www.mediawiki.org/wiki/Manual:$wgForeignFileRepos#Usage

# $wgForeignFileRepos[] = [
# 'class' => ForeignAPIRepo::class,
# 'name' => 'commonswiki', # Must be a distinct name.
# 'apibase' => 'https://commons.wikimedia.org/w/api.php',
# 'hashLevels' => 2,
# 'fetchDescription' => true, # Optional.
# 'descriptionCacheExpiry' => 43200, # 12 hours, optional (values are seconds).
# 'apiThumbCacheExpiry' => 86400, # 24 hours, optional, but required for local thumb caching.
# ];

$wgForeignFileRepos[] = [
'class' => ForeignAPIRepo::class,
'name' => 'enwikipedia',
'apibase' => 'https://en.wikipedia.org/w/api.php',
'hashLevels' => 2,
'fetchDescription' => true,
'descriptionCacheExpiry' => 43200,
'apiThumbCacheExpiry' => 86400,
];

Nicole Sharp (talk) 00:18, 25 March 2023 (UTC)

Bawolff (talkcontribs)

This is covered on the extension page. If you want to use both you need to use the settings mentioned in the Advanced Configuration section.

Bawolff (talkcontribs)

err nevermind, i thought the docs had something about this, but i guess it does not.

Bawolff (talkcontribs)

Anyways this is expected behaviour, if you need to use both at the same time (probably not a good idea) use the settings suggested in the advanced configuration section.

Reply to "Logic Exception"

help with ogv file type

9
2001:8F8:1E6D:A884:D8AB:3E80:31ED:4D26 (talkcontribs)

The attached example video from commons is just working good, but when using this extensions, i got a message saying (Error missing media source), while i have timed media handler installed.

Bawolff (talkcontribs)

i think this is an issue with timedmediahandler. I don't think it works with normal instant commons either.

2001:8F8:1E6D:A884:D8AB:3E80:31ED:4D26 (talkcontribs)

it works with normal instant commons, i just did a test now.

Bawolff (talkcontribs)
2001:8F8:1E6D:53DC:853A:9508:C4AD:A5C1 (talkcontribs)

I am sorry Bawolff, i am just working on testing as i promised you earlier, the good thing here that you solve the issues.

Bawolff (talkcontribs)

I appreciate it :)

It just might take a bit longer to fix, because the issue isn't in my code, so I have to get other stakeholders on board, which can be a complicated process sometimes.

2001:8F8:1E6D:E155:6DBD:BAA4:5CA2:D6A9 (talkcontribs)

I am watching those changes, but wondering whether they are applied to version 1.37 or only at the master branch.

Bawolff (talkcontribs)

Yes. it requires the "master" or "1.38" version of TimedMediaHandler. Its likely that version only works with the (yet unreleased) MediaWiki 1.38.

2001:8F8:1E6D:2802:A84E:54BC:CA12:8558 (talkcontribs)

Thank you Bawolff

Reply to "help with ogv file type"

(No action needed) QuickInstantCommons is deployed by Miraheze wikis

2
Lens0021 (talkcontribs)
Bawolff (talkcontribs)

Awesome! If you encounter any bugs or issues please let me know.

Reply to "(No action needed) QuickInstantCommons is deployed by Miraheze wikis"

Thank you for this great extension

15
2001:8F8:1E6D:72D2:4DD7:3397:2DCD:1F2D (talkcontribs)

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.

Bawolff (talkcontribs)

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)

2001:8F8:1E6D:72D2:5C94:A1C3:6BA1:9011 (talkcontribs)

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

2001:8F8:1E6D:72D2:5C94:A1C3:6BA1:9011 (talkcontribs)

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

Bawolff (talkcontribs)

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.

2001:8F8:1E6D:72D2:ED:DE30:6A50:5078 (talkcontribs)

Thank you very much. I will try it now

2001:8F8:1E6D:72D2:ED:DE30:6A50:5078 (talkcontribs)

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.

Bawolff (talkcontribs)

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?

2001:8F8:1E6D:72D2:61C3:2D42:4213:4A8E (talkcontribs)

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

2001:8F8:1E6D:72D2:61C3:2D42:4213:4A8E (talkcontribs)

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

Bawolff (talkcontribs)

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.

Bawolff (talkcontribs)

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

2001:8F8:1E6D:72D2:89B6:46B2:F904:4A86 (talkcontribs)

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.

Bawolff (talkcontribs)

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

Pspviwki (talkcontribs)

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?

Reply to "Thank you for this great extension"

Problem rendering TIF files

4
Ostrzyciel (talkcontribs)

Hi, I've noticed that after enabling QuickInstantCommons, TIF files from Commons stopped displaying in articles. See for example this page https://nonsa.pl/wiki/Patelnia with this image https://nonsa.pl/n/A3

I'm not sure why that is, but I suspect it may have something to do with TIF thumbnails having a different extension than the original file, they use .tif.jpg.

Bawolff (talkcontribs)

I think i found the culprit. In TiffHandler.php in MW core it hard codes built in InstantCommons.

        public function canRender( $file ) { 
                global $wgTiffThumbnailType;

                return (bool)$wgTiffThumbnailType
                        || $file->getRepo() instanceof ForeignAPIRepo;
        }

sigh

Ostrzyciel (talkcontribs)

Ouch.

I managed to temporarily fix it by setting:

$wgTiffThumbnailType = [ 'jpg', 'image/jpeg' ];

Sooo thanks for the hint! ;)

Bawolff (talkcontribs)

I made a new version (version 1.2) that will ignore built in tiff handler.

I don't think $wgTiffThumbnailType = [ 'jpg', 'image/jpeg' ]; should work (unless transformVia404 is false) because commons uses PagedTiffHandler instead which uses an incomaptible url format.

I think for best results, install PagedTiffHandler extension so it matches the one used on commons, but the new version should work regardless.

I've also been told there are issues with TimedMediaHandler files.

Reply to "Problem rendering TIF files"
Ostrzyciel (talkcontribs)

Couldn't find the issue tracker for this ext, so posting this here. I enabled the extension on an instance of MW 1.36.2, PHP 7.4.25. When viewing pages with Commons imagery I get the following error message at the top of the page:

Warning: curl_multi_setopt(): CURLPIPE_HTTP1 is no longer supported in /var/www/html/extensions/QuickInstantCommons/src/MultiHttpClient.php on line 532

More version information: https://nonsa.pl/wiki/Specjalna:Wersja?uselang=en

Bawolff (talkcontribs)

Oh you have a newer version of curl than me. It should be safe to ignore that warning, i'll commit a fix this evening. (The 3 should be a 2 on line 532)

Bawolff (talkcontribs)

This should be fixed now

Translation link is not suitable

5
Summary by Bawolff

Now on translatewiki

Lens0021 (talkcontribs)
Bawolff (talkcontribs)

I'm looking into how to get the extension added to translate wiki.

Lens0021 (talkcontribs)
Bawolff (talkcontribs)
Bawolff (talkcontribs)

Yes Done

Lens0021 (talkcontribs)

Hi, I am considering trying this extension on the production of Femiwiki which is a small wiki that has an average of 5000 visitors daily.

But I couldn't find tags or deterministic branches. Could I ask you to add the tag "1.0" to the repository?

Bawolff (talkcontribs)

There should now be a "v1.1" tag

Lens0021 (talkcontribs)
Bawolff (talkcontribs)

Awesome! Let me know if you run into any issues or if any of the image performance is less than expected.

There are no older topics