There are two hooks in this extension that we've learned the hard way still have some impact.

BitmapHandlerCheckImageArea is the obvious one, it overrides $wgMaxImageArea. MediaWiki is still checking this, even though Thumbor is responsible for scaling. Ideally we'd teach MediaWiki to ignore $wgMaxImageArea and just delegate it to thumbor. Alternatively, we set $wgMaxImageArea in line with whatever Thumbor accepts.

The other hook is BitmapHandlerTransform, it clearly does something based on T290973: Error: Call to a member function getMimeType() on null, however I don't actually understand how this actually overrides anything because per exec.log, it's not actually shelling out to vips.

There's also SpecialVipsTest which is actually the last thing shelling out to vips. If it seems like fixing the two hooks is going to take some time, we should just make this special page conditional and disable it on Wikimedia wikis so we can proceed with T260504: Get rid of remaining non-Thumbor MediaWiki image scaling in WMF production.

Change 722385 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/VipsScaler@master] Only show Special:VipsTest if VipsExposeTestPage is true, default false

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

Alternatively, we set $wgMaxImageArea in line with whatever Thumbor accepts.

Thumbor doesn't enforce area limits per se, with the exception of Gif thumbnailing (which is already handled with wgMaxAnimatedGifArea). Everything else is just based on time: as long as it can be done in 59 seconds, it's good.

Change 722385 merged by jenkins-bot:

[mediawiki/extensions/VipsScaler@master] Only show Special:VipsTest if VipsExposeTestPage is true, default false

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

Change 723322 had a related patch set uploaded (by Legoktm; author: Legoktm):

[mediawiki/core@master] Allow skipping $wgMaxImageArea check

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

In T291014#7367570, @AntiCompositeNumber wrote:

Alternatively, we set $wgMaxImageArea in line with whatever Thumbor accepts.

Thumbor doesn't enforce area limits per se, with the exception of Gif thumbnailing (which is already handled with wgMaxAnimatedGifArea). Everything else is just based on time: as long as it can be done in 59 seconds, it's good.

Thanks, this was helpful in figuring out where to go with disabling the size checks.

Change 723322 merged by jenkins-bot:

[mediawiki/core@master] Allow skipping $wgMaxImageArea check

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

Change 725101 had a related patch set uploaded (by Legoktm; author: Legoktm):

[operations/mediawiki-config@master] Set $wgMaxImageArea = false;

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

Change 725101 merged by jenkins-bot:

[operations/mediawiki-config@master] Set $wgMaxImageArea = false;

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

Mentioned in SAL (#wikimedia-operations) [2021-12-17T20:34:13Z] <legoktm@deploy1002> Synchronized wmf-config/CommonSettings.php: Set $wgMaxImageArea = false; (T291014) (duration: 00m 59s)

In T291014#7364592, @Legoktm wrote:

The other hook is BitmapHandlerTransform, it clearly does something based on T290973: Error: Call to a member function getMimeType() on null, however I don't actually understand how this actually overrides anything because per exec.log, it's not actually shelling out to vips.

This is the remaining thing to figure out.

https://en.wikipedia.org/wiki/Special:Version still lists it as deployed, so it was never tried again and was forgotten about ?

Perhaps a new attempt with toggling the config for group0 and group1 is warranted ?

In T291014#8632337, @TheDJ wrote:

https://en.wikipedia.org/wiki/Special:Version still lists it as deployed, so it was never tried again and was forgotten about ?

Not forgotten, just on my backlog unless someone else came along.

Perhaps a new attempt with toggling the config for group0 and group1 is warranted ?

Yeah, that sounds like a good way forward.