Change #1233759 restored by Krinkle:

[mediawiki/extensions/WikiEditor@master] Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1233759

In T414805#11849172, @gerritbot wrote:

Change #1233759 restored by Krinkle:

[mediawiki/extensions/WikiEditor@master] Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1233759

Before (status quo historically)
Before (regression, HTTP 400)
Before (regression, 20px blurry hotfix)
Before (regression, 40px overflow hotfix)
After (with patch and 40px thumbnail step)

Change #1233759 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1233759

Change #1276727 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/WikiEditor@wmf/1.46.0-wmf.24] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276727

Mentioned in SAL (#wikimedia-operations) [2026-04-23T16:16:32Z] <Amir1> re-enabling general ban on any non-standard thumb (T414805)

Change #1276727 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@wmf/1.46.0-wmf.24] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276727

Mentioned in SAL (#wikimedia-operations) [2026-04-23T21:00:49Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1276727|ext.wikiEditor: Set background-size for toolbar buttons (T414805)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-23T21:02:26Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1276727|ext.wikiEditor: Set background-size for toolbar buttons (T414805)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-23T21:03:54Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1276727|ext.wikiEditor: Set background-size for toolbar buttons (T414805)]] (duration: 03m 05s)

Mentioned in SAL (#wikimedia-operations) [2026-04-23T21:04:11Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1276727|ext.wikiEditor: Set background-size for toolbar buttons (T414805)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-23T21:05:49Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1276727|ext.wikiEditor: Set background-size for toolbar buttons (T414805)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-23T21:09:58Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1276727|ext.wikiEditor: Set background-size for toolbar buttons (T414805)]] (duration: 05m 47s)

Change #1276822 had a related patch set uploaded (by Neriah; author: Krinkle):

[mediawiki/extensions/WikiEditor@REL1_45] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276822

Change #1276823 had a related patch set uploaded (by Neriah; author: Krinkle):

[mediawiki/extensions/WikiEditor@REL1_44] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276823

Change #1276824 had a related patch set uploaded (by Neriah; author: Krinkle):

[mediawiki/extensions/WikiEditor@REL1_43] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276824

Change #1277089 had a related patch set uploaded (by Reedy; author: Ladsgroup):

[mediawiki/core@REL1_45] Media: Re-apply Use previous step for non-standard width between steps and original

https://gerrit.wikimedia.org/r/1277089

Change #1277090 had a related patch set uploaded (by Reedy; author: Ladsgroup):

[mediawiki/core@REL1_44] Media: Re-apply Use previous step for non-standard width between steps and original

https://gerrit.wikimedia.org/r/1277090

Change #1277091 had a related patch set uploaded (by Reedy; author: Ladsgroup):

[mediawiki/core@REL1_43] Media: Re-apply Use previous step for non-standard width between steps and original

https://gerrit.wikimedia.org/r/1277091

Change #1277091 merged by jenkins-bot:

[mediawiki/core@REL1_43] Media: Re-apply Use previous step for non-standard width between steps and original

https://gerrit.wikimedia.org/r/1277091

Change #1277090 merged by jenkins-bot:

[mediawiki/core@REL1_44] Media: Re-apply Use previous step for non-standard width between steps and original

https://gerrit.wikimedia.org/r/1277090

Change #1277089 merged by jenkins-bot:

[mediawiki/core@REL1_45] Media: Re-apply Use previous step for non-standard width between steps and original

https://gerrit.wikimedia.org/r/1277089

Change #1276824 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@REL1_43] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276824

Change #1276822 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@REL1_45] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276822

Change #1276823 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@REL1_44] ext.wikiEditor: Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1276823

Prompted by T424511: Broken logo thumbnail for missing Wikiversities, I'm probably gonna try and work a bit from (subsets of) this Codesearch result to try and find other WMF-deployed places where this enforcement may have caused breakage. (I'm commenting this here in case any other folks also feel like working from this Codesearch result, as I probably won't be able to go through the whole list :))

I went through this CSS global search and fixed CSS on Meta and most Polish sites.

There are still loads of broken MediaWiki:Common.css. I'm usually a fan of "you broke it, you fix it"... and well... you broke it, WMF 🙃

In T414805#11873042, @Nux wrote:

There are still loads of broken MediaWiki:Common.css. I'm usually a fan of "you broke it, you fix it"... and well... you broke it, WMF 🙃

I understand but with the same logic, if any bot breaks anywhere because we remove a deprecated function in our API (granted enough communication was done and enough time is given), it's WMF's fault and we have to fix it?

I went through every case that made more than 5,000 requests a day and fixed them last week.

In T414805#11873989, @Ladsgroup wrote:

In T414805#11873042, @Nux wrote:

There are still loads of broken MediaWiki:Common.css. I'm usually a fan of "you broke it, you fix it"... and well... you broke it, WMF 🙃

I understand but with the same logic, if any bot breaks anywhere because we remove a deprecated function in our API (granted enough communication was done and enough time is given), it's WMF's fault and we have to fix it?

I went through every case that made more than 5,000 requests a day and fixed them last week.

The sites are broken because of your actions. And I assume this was approved by your management, right? If you remove an API just because you want to, and not for valid technical reasons, then yes, you should fix as much as possible before you even remove the API.

Things get deprecated for years in traditional programming before they are removed. I would argue more about that, but my doctor would advise against it :P. But I do want to remind you that, in theory, you did that to prevent AI from crashing the Wikimedia sites and instead of actually blocking them you chose a path that breaks normal usages of the API on Wikimedia site. You broke stuff that has been working for 20 years.

You've also chosen px values that are just unheard of. If you would check PWA recommendations, Apple touch icons sizes, or Microsoft icons sizes, you would know that 20, 40, 60, 120 are not normal icon sizes... Or you could just ask... Or you could just listen... You've also even chose to ignore recommended icon sizes that were documented on the MediaWiki site. You could have just blocked remote requests (edit: I meant invalid remote request); instead, you chose to disturb everybody.

And that is on top of WMF staff already making interface edits harder by forcing re-auth on JS edits (and, for some time, for CSS too). And those, now invalid images, are both in JS and CSS.

In T414805#11874323, @Nux wrote:

And that is on top of WMF staff already making interface edits harder by forcing re-auth on JS edits (and, for some time, for CSS too). And those, now invalid images, are both in JS and CSS.

I completely agree with this point. I have worked with the reftool script on several dozen wikis, and spent several hours logging in again and again. I do use 2fa with a fingerprint, but even that takes a lot of time and is definitely disruptive.

In T414805#11873989, @Ladsgroup wrote:

In T414805#11873042, @Nux wrote:

There are still loads of broken MediaWiki:Common.css. I'm usually a fan of "you broke it, you fix it"... and well... you broke it, WMF 🙃

I understand but with the same logic, if any bot breaks anywhere because we remove a deprecated function in our API (granted enough communication was done and enough time is given), it's WMF's fault and we have to fix it?

One potential difference that comes to mind is that -- potentially nobody (or few people) may have reasonably expected the thumbnail/image URLs to stop working at some point in the future (as long as the images in question are not deleted on the wikis themselves), as may be partially evidenced by the fact that these thumbnail URLs were/are in use within WMF-authored deployed code; whereas APIs/API methods could perhaps be reasonably expected to have parts that are deprecated/removed from time to time.

While it may be true that thumbnail URLs were not declared to be a stable interface, I guess 'cool URI's don't change' is a principle for a reason. YMMV.

In T414805#11875160, @A_smart_kitten wrote:

One potential difference that comes to mind is that -- potentially nobody (or few people) may have reasonably expected the thumbnail/image URLs to stop working at some point in the future (as long as the images in question are not deleted on the wikis themselves), as may be partially evidenced by the fact that these thumbnail URLs were/are in use within WMF-authored deployed code; whereas APIs/API methods could perhaps be reasonably expected to have parts that are deprecated/removed from time to time.

APIs are maintained as stable interfaces, their evolution is subject to change management, e.g. deprecation periods. That doesn't mean other things can't change. The opposite is true. Anything that is not maintained as a stable interface (aka API) can change without notice at any time.

Of course we try to minimize disruption, but that has to be weight against the benefit of the change (in this case: we continue to be able to serve any images at all).

While it may be true that thumbnail URLs were not declared to be a stable interface, I guess 'cool URI's don't change' is a principle for a reason. YMMV.

'cool URI's don't change' is a good principle, but I would not apply it to any resource addressable with a URL. In fact, a lot of URLs point to ephemeral things. I'd only apply it to URIs published explicitly for permanent external use.

All that said: in how for media (and thumbnail) URLs are a public API and should be treated as a stable interface is a debatable question. After all, InstantCommons exists. But again, the stakes here were quite high, and we had to act fast.

In T414805#11875703, @daniel wrote:

APIs are maintained as stable interfaces, their evolution is subject to change management, e.g. deprecation periods. That doesn't mean other things can't change. The opposite is true. Anything that is not maintained as a stable interface (aka API) can change without notice at any time.

I just want to be clear that I don't necessarily disagree with this -- I guess my point was more that, whether or not (e.g.) the thumbnail URLs could have stopped working at any time without notice, I would personally be unsure that many people using them would have - prior to the work done here - reasonably expected them to stop working at any time.

In T414805#11875703, @daniel wrote:

In T414805#11875160, @A_smart_kitten wrote:

While it may be true that thumbnail URLs were not declared to be a stable interface, I guess 'cool URI's don't change' is a principle for a reason. YMMV.

'cool URI's don't change' is a good principle, but I would not apply it to any resource addressable with a URL. In fact, a lot of URLs point to ephemeral things. I'd only apply it to URIs published explicitly for permanent external use.

All that said: in how for media (and thumbnail) URLs are a public API and should be treated as a stable interface is a debatable question. After all, InstantCommons exists. But again, the stakes here were quite high, and we had to act fast.

Were the stakes high, though? I mean, for big images, sure, I can imagine. But for small ones below 40px? How much of a transfer/CPU budget is that? 0.1%? Less? I assume the remaining small images have fewer than 5k hits per day, as already mentioned by @Ladsgroup. That doesn't sound high to me for websites as popular as Wikimedia sites. And I assume most of them were already in cache, were they not?

In T414805#11874323, @Nux wrote:

Things get deprecated for years in traditional programming before they are removed. [..]

You've also chosen px values that are just unheard of.

This process started with T211661 in 2022 with giving new thumbnails TTL (time to live).
T360589 is the research for the thumbnail sizes, and it shows that among the thumbnail sizes that are dividable by 10, the most popularly requested where picked.
The policy on this is https://www.mediawiki.org/wiki/Stable_interface_policy . Since you want different treatment, start an mediawiki rfc on changing that policy.
As for stable image links see T420740.

In T414805#11876609, @Nux wrote:

How much of a transfer/CPU budget is that? [...] And I assume most of them were already in cache, were they not?

It was not done because of the thumbnailer, it was done for the storage space.

This process started with T211661 in 2022 with giving new thumbnails TTL (time to live).

This was a decision about internal storage cleanup, not about what URLs would continue to function. The decision to clean internal storage has almost no impact on users, as new thumbnails could always be regenerated. There has been talk of potentially bucketing thumbnail sizes for years, but only as a potential future plan & without breaking existing URLs.

The policy on this is https://www.mediawiki.org/wiki/Stable_interface_policy . Since you want different treatment, start an mediawiki rfc on changing that policy.

The stable interface policy belongs to the WMF, and can only be changed by the WMF. The TechCom RFC process which was previously used to make WMF development policy in collaboration with volunteers no longer exists, having been deleted by WMF management. This leaves WMF management as the only authority over the policy.

The stable interface policy was written with one audience in mind - people writing PHP code that directly interacts with MediaWiki code. It does not cover the web APIs or the thumbnailer. The Action API has https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Deprecation_process, and there is no policy governing media URLs, as the WMF has never declared them an API. This disconnect been known to the WMF for some time (or, at least, was previously known to WMF staff -- I can not speak as to how well WMF retains knowledge), as internal and external media users alike have treated the thumbnail URLs and the process by which they're generated as stable for a long time. I would analogize this to a long-disused rail line that, as far as the railroad is concerned, is still fully in-service but hasn't seen a train in decades. It would be irresponsible to suddenly start running high-speed trains down that track, and doing so would surely result in fatal grade-crossing accidents.

I will note that lack of a policy preventing disruptive actions is not a sufficient justification for disruptive actions. Whether the WMF *can* do something is never really in question: only whether it should. Proper engineering practice includes determining and controlling for downstream impacts to the extent practicable.

The main gain from bucketing and standardizing thumbnail steps back then was to improve performance. That was mostly gained since last year (T360589) since 92% of the requests at that time switched to standard sizes and got de-fragmented in cache improving performance/cpu/storage for users (T360589#10832485 see for the impact) and also as you can see the ticket, the standard sizes were picked based what was the most usual sizes at that time to minimize image resizing on browsers. It wasn't random.

The current work is similar but it is mostly done for a different reason. Of course, reduction to cpu and improving performance still happened by going from 92% to 100% but the main reason for this change is that we would have been down all the time otherwise. SRE doesn't publicly explain our DDoS vectors and how they can be exploited so it wasn't emphasized but even here it was explicitly mentioned that allowing non-standard sizes is DDoS vector (T414805#11623347). Maybe it is not clear that this was actively being exploited by scrapers and attackers? Here is a graph of requests to non standard thumbnail sizes:

And as you can scrapers became more aggressive and now they are hitting us with around 1B requests being blocked every single day. Five times more than all of CDN cache miss requests to all of our images combined

So to be able to be just up, we would have had to increase the capacity of thumbor and edge by factor of six just to accommodate scrapers (not to mention, they displacing images from CDNs would reduce cache hit ratio and so on, and the fact they wouldn't stop there). For example, in December before we started the rate limit, we had several major outages that images were not loadable to any reader (plus network saturation that brought everything down too, not just images). Obviously these scrapers are getting better at hiding themselves as human traffic so it's basically impossible to simply ban them without banning half of the internet.

And as above it has been explained why craving an exception for "small" sizes still doesn't help with the DDoS vector and could be easily abused (and as you saw in the above graph, we got attacked by sending non-standard sizes) and while they are not large to serve, they are still expensive to generate since the original image still needs to be loaded.

In T414805#11877645, @AntiCompositeNumber wrote:

I will note that lack of a policy preventing disruptive actions is not a sufficient justification for disruptive actions. Whether the WMF *can* do something is never really in question: only whether it should. Proper engineering practice includes determining and controlling for downstream impacts to the extent practicable.

There are two different discussions here. One is that whether this change is violating the policy which the answer is no as the policy doesn't apply as urls to thumbnails are not stable APIs. The second discussion is whether enough courtesy has been given to which my answer is yes (specially surrounding the circumstances I outlined above). When we say you are responsible for fixing your gadgets doesn't mean we didn't try to accommodate you. It's a bit saddening that I've spent so much time fixing gadgets and gave three months since the official announcement and still get such comments like I haven't done anything to accommodate. If you check my global contributions, you can find around sixty fixes (P92132) on many different projects (and each css/gadget/template style requiring a different fix). The point here is NOT that we should drop changes on you because "it's not the policy" but the point is that you should also meet at the middle. We have fixed as many as we could given that there are only 24 hours in a day and I'm just one human. You should also spend some time maintaining gadgets you use and don't just assume it will work forever and we will fix everything since that is not possible for a small group of devs to maintain all userscript/gadget/template styles in all wikis specially when a solution can't be done automatically (sometimes it's possible and I have fixed many users scripts, here is an example my fixes in Finnish Wikipedia) but here it was not.

I appreciated the detailed write-up. The circumstances are unfortunate because editing JS is now hard, and that, I know, is not for any good reason. I'm sorry, but after the so-called "incident" of running a worm from a staff account, I lost trust in WMF staff and WMF procedures and vented here, assuming something similar happened here. That was unfair, and I'm sorry about that.

Back to the topic of thumbnail images on wikis... Aside from JS changes, there are a lot of non-obvious changes, like people adding covers from enwiki as links (copyright issue) and scans of documents from Commons as sources. See my changes regarding thumbs in plwiki articles. I guess you might have seen some of that in stats as bots would probably ping/scrape the links in the article as they parse the code.

Some of the above changes can be semi-automated, but on top of re-auth problems with JS, there are some AWB problems now. AWB seems not to be working at the moment, which is also an unfortunate circumstance when many changes need to be done...

The voluntary efforts are there too, as you can see, but we are probably spread too thin, or there are just not that many people who actually know how to change JS/CSS. I would guess people might also be afraid to make changes after the "incident". For example, I don't have the necessary rights on Commons, and people who do have them haven't fixed icons in this upload helper script since February:
https://commons.wikimedia.org/wiki/MediaWiki_talk:UploadForm.js#Invalid_size_of_image_icons_on_the_form

Note that some of these things are just hard or take time. As an example, it took me almost 2 years to get to the task of removing jQuery UI from one of the gadgets on plwiki. Also, some things are not within the power of voluntary devs. For example, the fix for the WikiEditor toolbar (that was needed here, for this task) would not have happened without a blessing from WMF staff or a decision about which path to take to allow SVG icons in the toolbar.

So ideally, the changes should not have happened so fast. I would really appreciate it if things like that did not change so fast in the future. It would be nice to perhaps have some console warnings first or a more gradual, stretched-out rollout of removing features (e.g., cutting out very large images first and then gradually scaling down, announcing steps before and as they take place).

Change #1281999 had a related patch set uploaded (by Brian Wolff; author: Ladsgroup):

[mediawiki/extensions/PagedTiffHandler@REL1_45] Make it follow thumb steps

https://gerrit.wikimedia.org/r/1281999

Change #1282000 had a related patch set uploaded (by Brian Wolff; author: Ladsgroup):

[mediawiki/extensions/PagedTiffHandler@REL1_44] Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282000

Change #1282001 had a related patch set uploaded (by Brian Wolff; author: Ladsgroup):

[mediawiki/extensions/PagedTiffHandler@REL1_43] Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282001

Change #1282000 merged by jenkins-bot:

[mediawiki/extensions/PagedTiffHandler@REL1_44] Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282000

Change #1281999 merged by jenkins-bot:

[mediawiki/extensions/PagedTiffHandler@REL1_45] Make it follow thumb steps

https://gerrit.wikimedia.org/r/1281999

Change #1282001 merged by jenkins-bot:

[mediawiki/extensions/PagedTiffHandler@REL1_43] Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282001

Change #1282002 had a related patch set uploaded (by Brian Wolff; author: Ladsgroup):

[mediawiki/core@REL1_45] DjvuHandler: Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282002

Change #1282003 had a related patch set uploaded (by Brian Wolff; author: Ladsgroup):

[mediawiki/core@REL1_44] DjvuHandler: Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282003

Change #1282004 had a related patch set uploaded (by Brian Wolff; author: Ladsgroup):

[mediawiki/core@REL1_43] DjvuHandler: Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282004

Change #1282002 merged by jenkins-bot:

[mediawiki/core@REL1_45] DjvuHandler: Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282002

Change #1282003 merged by jenkins-bot:

[mediawiki/core@REL1_44] DjvuHandler: Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282003

Change #1282004 merged by jenkins-bot:

[mediawiki/core@REL1_43] DjvuHandler: Make it follow thumb steps

https://gerrit.wikimedia.org/r/1282004

I understand the need to stop generating arbitrary thumbnail sizes, but was it really necessary to break existing URLs? Serving HTTP redirects to the nearest larger standard size would work in most cases, and seems unlikely to have any meaningful performance impact. Even in cases where this results in images being displayed larger than expected (e.g. T414805#11849180), that seems preferable to them not loading at all. Yes, the URLs might officially be considered an implementation detail, but the reality is that they are linked and embedded across the web, and e.g. forum posts and old static webpages are unlikely to ever be updated to point to new URLs. To be clear, this doesn't just affect users who have manually edited the width in the URLs. For example, at https://web.archive.org/web/20250115020905/https://commons.wikimedia.org/wiki/File:Damage_in_Gaza_Strip_during_the_October_2023_-_29.jpg, all but one of the thumbnail resolutions linked below the preview are now blocked, and the "Use this file on the web" gadget shows HTML and BBCode embed code with several options for the width, all of which are powers of two and now blocked. The latter issue was reported in T419135 and was "fixed" by updating the gadget to use standard sizes, but this does not help with any existing uses.

Change #1253662 merged by BCornwall:

[operations/puppet@production] upload: Return 400 instead of 429 for non-standard thumbnail sizes

https://gerrit.wikimedia.org/r/1253662