What accessibility testing was performed for these icons? My eyes aren't *that* bad and several of the new icons are very difficult to see & understand at a normal icon scale, especially the UserTemporary icons and HalfBright.

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

git bisect says this is caused by rSVEC148b05474cbd: Allow overflow menu to display icon buttons for logged out users (@Jdlrobson-WMF, @bwang).

Also affecting https://meta.wikimedia.org/wiki/Special:CentralAuth/Faster_than_Thunder

That's probably a consequence of T384844 -- some password managers group all the Wikimedia domains together.

The move to login on auth.wikimedia.org has mostly fixed this for me, as I don't have any *.wikimedia.org autofill entries anymore.

There is probably too much patent uncertainty over AV1, the video encoding format that AVIF is based on, to implement this at this time.

Confirming this affects all attempts to use https://sh.wikipedia.org/wiki/Special:Preferences, and attempts to use the options API to set preferences.

4. AbuseFIlter should have UX added to manage a list of blocked domains (it may already have this) and implement the hook to compare links against this list and return null where appropriate. CSS styling and title messages would be provided by AbuseFilter.

action=view is obviously useful. action=edit is probably someone's workflow. action=info probably isn't going to break anything either way. I can't think of a legitimate reason for the rest to work.

We intentionally don't serve WebP originals for browser support reasons at the time support was added. WebP thumbnails are only sent conditionally when requested by the browser on high-use files only.

Original-size thumbnails must be supported as not all formats are web-safe.

Also getting reports of this.

Fixed with pngfix.

In T415598#11555931, @TheDJ wrote:

The ogp.me tag is listing the thumbnail variant of the fullsize, instead of the fullsize

This started happening within the last month or so. It doesn't happen for every request for every thumbnail, but seems to be more likely after the first request. Discord uses Google Cloud IPs most of the time.

Special:NewFiles doesn't appear to be as bad as it was a few years ago, but I do think it would still benefit from pregenerating the 120px/250px thumbnails.

Fixed with pngfix.

Production data loss -> UBN.

I hit this while making a check yesterday, and then ran in to it with some enwiki CUs today. Both times we were trying to copy/paste IPs into the range calculator.

I have disabled the bgpview.io queries, and the tool appears to be no longer 500ing. So that's a slight improvement.

https://grafana.wikimedia.org/d/000000371/vrts?orgId=1&from=2025-11-02T02:44:01.700Z&to=2025-12-02T02:43:01.700Z&timezone=utc&var-node=vrts1003&viewPanel=panel-30 shows inode usage steadily climbing to 100% since 2025-11-17.

I logged out and logged back in again, (I had already tried that), and now it works. We'll see if this sticks or not.

Yes, it's the same token.

I tried it on testwiki, and was able to edit and make a block without issue.

In T409747#11370774, @Superpes15 wrote:

I remember using it several times without any problems on both Firefox and Chromium browsers. The only point was that the account had to be hidelocked and not suppresslocked for it to work.

Same here, plus a few others in Discord as well.

When I've tried it in Firefox, it fails consistently for the users I tried it on. I just tried it in Chrome and it worked. @KonstantinaG07 said she tried it in Firefox and it works inconsistently. Other stewards have also used it in Firefox and had it work.

x-request-id: 7eed4952-9f9f-4d43-ad59-9c7fdac18555 for an example request.

The regex in rTHMBREXT wikimedia_thumbor/handler/images/images.py should be correct as far as the format & parameters of the thumb URLs, at least at the Thumbor level.

• qlow generates a low-quality JPEG thumbnail, which as far as I know is no longer used in production.
• lossy and lossless are used for certain formats (namely TIFF and webp) to choose the compression type.
• page, as noted, is used for multi-page files, but is not necessarily required for them.
• lang is used for SVG thumbnails. MediaWiki does attempt to detect translation markup in SVGs and only request lang-specific URLs when it expects a working translation. rMW includes/media/SvgHandler.php English is treated as the default (as far as I can tell, unconditionally), with the default/fallback text specified in the SVG being accessed through the und language code.
• seek is a timestamp used for video thumbnails

The statement that solely-AI-generated works are not subject to copyright protection is true in the US, but it is not true in the UK and Hong Kong. It's also possible that other jurisdictions will recognize some level of copyright protection for AI-generated works. For that reason, the backup license should remain.

This is a MediaWiki-extensions-PdfHandler issue, not Thumbor. It's likely related to T299521 and/or T381318.

@Agamyasamuel You can add them to the Trusted-Contributors group on Phabricator and their GitLab account will be approved automatically.