|Open||None||T106123 Extensions needing to be removed from Wikimedia wikis|
|Resolved||Legoktm||T290802 Remove libvips-tools from mediawiki appservers|
|Open||None||T260504 Get rid of remaining non-Thumbor MediaWiki image scaling in WMF production|
|Open||Jdforrester-WMF||T290759 Undeploy VipsScaler from Wikimedia wikis|
|Open||None||T291014 Terminate all implicit use of VipsScaler code from Wikimedia production so we can remove it without breaking things this time|
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.
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.