Page MenuHomePhabricator

Gadget-Stockphoto.js on Commons uses non-common thumbnail sizes, leading to a HTTP 429
Closed, ResolvedPublicBUG REPORT

Description

I explained the problem at "Commons:Help desk" already, but got the advice to give a note here: https://commons.wikimedia.org/wiki/Commons:Help_desk#Warum_funktioniert_das_Einbinden_eines_Bildes_in_eine_externe_Website_nicht_(siehe_Beispiel)

What happens?:
All Commons pictures used on external websites did not work anymore. In my case these are far more then 100 pages with more than 700 pictures.

The cause (according to my tests) is that ‘use this file on web’ (or ‘embed’) works with image sizes such as ‘256’ or ‘512’, while technically it has obviously been changed to “250” and ‘500’! If I manually change the 256 or 512 to 250 or 500 in the ‘Embeds’ in the ‘Thumbnail Link’, it works again. With my extremely large number of affected pages from the last 10 years (which I cannot automatically adjust myself), this is extremely annoying. But even the current ‘use this file on web’ template (on German Wikimedia Commons) still offers only the old values (which no longer work) – so it is currently inoperable (no longer works). ..

What should have happened instead?:
Just changing the "use this file on web" template to the new sizes would not solve the "legacy" problem (in my case work from the last 10 years).
It would make sense for the ‘previous solutions’ in the existing world, such as my many pages, to continue to work, e.g. by redirecting the “256” link versions to the new ‘250’ versions. (This applies to the other sizes as well, of course: 512=>500, etc.) Or is there already an elegant solution for automatically changing the format in ‘externally hosted’ websites (in my case, Strato)? It would also be very unfavourable for the ‘use this file on web’ function as a whole if there were no guarantee that the integrations would continue to work in the long term and could not suddenly fail at any time (as is currently the case). Is anyone already working on a solution? Unfortunately, I am unable to do so. What does the solution will look like?

Event Timeline

Aklapper renamed this task from Critical error with ‘use this file on web’ functions to Gadget-Stockphoto.js on Commons uses non-common thumbnail sizes, leading to a HTTP 429.Mar 5 2026, 3:34 PM
Aklapper added a subscriber: Ladsgroup.

Hi @Dirk_Liesch, thanks for taking the time to report this!

This needs to be fixed on Commons by correcting the on-wiki code in https://commons.wikimedia.org/wiki/MediaWiki:Gadget-Stockphoto.js , probably around the line width = $('#stockphoto_html_select').val();.

See https://w.wiki/GHai for more information.

You could bring this up on https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-Stockphoto.js, for example.

User scripts, gadgets, templates, modules, custom CSS are local on-wiki content.
Local content is managed independently on each wiki, by each wiki community themselves.
Phabricator is mostly used for MediaWiki, MediaWiki extensions, or server configuration, or by developers and teams to organize what they plan to work on.
If you are looking for general help with the local code on a wiki, please see https://meta.wikimedia.org/wiki/Tech instead.
This needs fixing on the local wiki by editing its local content.
Thus I am closing this task here - thanks for your understanding.

@Aklapper thanks a lot 4 your information and time

@Aklapper Thanks again. Just for understanding. I understand, that there should be standard sizes for the future and I`m not writing abbout "small thumnails". I'm using since more than 10 years on wordpress blogs mainly 256 or 512px image sizes (with the html-part) generated fom "use this file on web" and link to the original file (high resulution) to the Commons. I also did some trainings for others to do the same, when creating "OER" learning content. All this results from the 10 years don't work now anymore. The results are on a lot differnt Wordpress-Sites, we don't even have access anymore (because it where project by third parties). Even at my own sites I don't habe access with scripts to change "/512px" (old) to "/500px" (new) automatically (same for 256. That means I (and all the people who did the same) have to find all the places, where rhey included images with "use this file on web" an change it (often as I manually).
Maybe it would help a lot if some kind of "redirect" script (at wikimedia commons servers) catch the "/512px" request and redirect them to "/500px" als "Legacy-Funktion".
That the German version from "use this file on web" still generating the wrong 512 or 256px images sizes is a minor problem (after someone knows about the problem and the solution - as now). The difficult part ist the "legacy"-problem with all the wrong links somewhere on differnt sites and the loss of trust, that something like this can happen with wikimedia commons content again in the future.
Therefore it would be great, if there could be a central solution like this "redirect-idea" (if possible). Maybe this is a central task (and not only the German "use this file on web" version) and maybe it's worth to do it, to help a lot of "external" Commons users (like me). I don't know, because I'm working more with OER content nowadays.

Krinkle changed the task status from Invalid to Resolved.EditedMar 14 2026, 10:11 AM

I've done a major update to the logic of the Stockphoto gadget today at the Arnhem Hackathon.

Edit history

Broadly:

  • Improve "Use on web" dropdown menu.
    • Previously it hardcoded powers of two, computing five choices around the preview size. For a landscape photo it would pick 128, 256, 612, 1024, 2048. For portraits it would pick 256, 512, 1024, 2048, 4096. For a small image, it would pick 32, 64, 128, 256, 512.
    • I changed it to instead reuse the links in the mw-filepage-other-resolutions widget, which are rendered server-side by MediaWiki basd on $wgImageLimits, and already take $wgThumbnailSteps into account.
  • Improve "best fit" logic.
    • Previously, it chose the largest power of two that is smaller than the preview. This tended to offer 256px or 512px as the default selection (landscape vs portrait).
    • I changed it to add the preview source directly and select that as the default. This is usually 500px or 960px.
    • I also changed it to limit the embed sizes to 1000px. While it make sense to want to download a 4K photo, it does not make sense to render a 4K thumbnail in the middle of a web page at 1dppx.
  • Improve video embedding to offer embed players matching relevant transcode sizes (480p, 720p, 1080p) rather than thumbnail sizes.
  • Fix broken OGG icon in audio embed player.
  • Fix future bug due to upcoming T414338 rollout, which adds query parameters. The Stockphoto gadget was blindy appending ?download in some places, which conflicts with pre-existing query strings.
  • Remove _=1234 parameters from these URLs instead of copying them from the main preview.

@Krinkle The updates to the gadget are great, for future use. However it doesn't solve the problem of users on external sites using this gadget to embed images on their sites which now have broken links as described under What should have happened instead?:. (Last weekend I found two examples of the same problem on my own site with images as recent as from Wikimania 2024.)