convert), even when $wgUseImageMagick and $wgUseImageResize are false
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	SacredSum
	May 14 2022, 4:50 PM

Description

List of steps to reproduce (step by step, including full links if applicable):

Set $wgUseImageMagick = false in LocalSettings.php.
Either:
- Make sure ImageMagick (/usr/bin/convert) is not installed, or
- Set $wgImageMagickConvertCommand to a nonexistent path.
Upload a .webp image file.

What happens?:

At the upload's File: page, there is a broken image, with an error message that shows MediaWiki tried to run ImageMagick:

Error creating thumbnail: /bin/bash: line 1: /usr/bin/convert: No such file or directory Error code: 127

What should have happened instead?:

Based on the variable name, I expected that setting $wgUseImageMagick to false would cause ImageMagick never to be used. Acting on that expectation, I disabled the setting as a security hardening measure. Instead, it seems the meaning of $wgUseImageMagick = false is more like: prefer other image libraries if available, but use ImageMagick anyway if it is the only option.

I expected that if $wgUseImageMagick were false and ImageMagick were the only available scaler for an image file format, the image would remain unthumbnailed.

For me, an additional clarification at https://www.mediawiki.org/wiki/Manual:$wgUseImageMagick would be a sufficient fix. Another sufficient fix would be a way to override mustRender for WebP, so that the .webp file can be shown to browsers directly, without needing to be converted to .jpg.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:

MediaWiki 1.37.2

This is where the "im" scaler is hardcoded for WebP:
https://gerrit.wikimedia.org/g/mediawiki/core/+/71c81003ead8e26caf239a109b121df9d7cccd68/includes/media/WebPHandler.php#283

It looks like the same situation exists with XCF (I noticed because the comment in WebPHandler.php is copied from XCFHandler.php):
https://gerrit.wikimedia.org/g/mediawiki/core/+/71c81003ead8e26caf239a109b121df9d7cccd68/includes/media/XCFHandler.php#168

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	mediaHandler: Respect image scaler configs for Webp and XCF files	mediawiki/core	master	+15 -19

Customize query in gerrit

Related Objects

Mentioned Here: T50519: Add basic WebP upload support with JPEG/PNG thumbnails
T105319: Investigate serving webp and JPEG-XR thumbnails to browsers capable of it
T152739: Send WebP images when possible

Event Timeline

SacredSum created this task.May 14 2022, 4:50 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 14 2022, 4:50 PM

TheresNoTime added a project: MediaWiki-File-management.May 14 2022, 5:58 PM

Maintenance_bot added a project: Commons.May 14 2022, 6:30 PM

Peachey88 removed a project: Commons.May 15 2022, 1:16 AM

SacredSum renamed this task from WebP uploads use "im" scaler (/usr/bin/convert) even when $wgUseImageMagick is false to WebP uploads always use "im" scaler (/usr/bin/convert), even when $wgUseImageMagick and $wgUseImageResize are false.Apr 24 2024, 3:26 PM

I forgot that I had opened this task and almost went to open another one today. Anyway, a little more information: the problem still exists in 1.39.7. In addition to ignoring $wgUseImageMagick, the hardcoded getScalerType for webp also ignores $wgUseImageResize.

If I hack getScalerType to return 'client' rather than 'im', it works the way I want: the web server just returns the .webp file without thumbnailing or scaling.

--- a/includes/media/WebPHandler.php
+++ b/includes/media/WebPHandler.php
@@ -288,6 +288,6 @@ class WebPHandler extends BitmapHandler {
         * @return string
         */
        protected function getScalerType( $dstPath, $checkDstPath = true ) {
-               return 'im';
+               return 'client';
        }
 }

Ideally, subclasses of BitmapHandler should not be able to override getScalerType in a way that ignores $wgUseImageMagick and $wgUseImageResize.

I guess it was T50519 that added support for webp uploads and hardcoded JPEG/PNG thumbnailing:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/95872/16/includes/media/WebP.php#304

T152739 and T105319 appear to be related.

Change #1037499 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@master] mediaHandler: Respect image scaler configs for Webp and XCF files

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

gerritbot added a project: Patch-For-Review.Jun 1 2024, 6:23 PM

TheDJ subscribed.Jun 1 2024, 11:45 PM

Change #1037499 merged by jenkins-bot:

[mediawiki/core@master] mediaHandler: Respect image scaler configs for Webp and XCF files

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

@Func does the patch fully solve the issue, or is there additional work required ?

Func closed this task as Resolved.Jun 2 2024, 8:57 PM

ReleaseTaggerBot added a project: MW-1.43-notes (1.43.0-wmf.8; 2024-06-04).Jun 2 2024, 9:00 PM

Maintenance_bot removed a project: Patch-For-Review.Jun 2 2024, 9:30 PM

WebP uploads always use "im" scaler (/usr/bin/convert), even when $wgUseImageMagick and $wgUseImageResize are falseClosed, ResolvedPublicBUG REPORTActions

Description

Details

Related Objects

Event Timeline

WebP uploads always use "im" scaler (/usr/bin/convert), even when $wgUseImageMagick and $wgUseImageResize are false
Closed, ResolvedPublicBUG REPORT
Actions