Prevent transparency loss in AVIF by falling back to WebP on older ImageMagick #2245

b1ink0 · 2025-10-30T21:17:07Z

Summary

Fixes #2237

Relevant technical choices

Prevents transparent backgrounds from being lost when converting PNG images to AVIF format on older ImageMagick

TODO:

Site health test
Add tests

codecov · 2025-10-30T21:26:06Z

Codecov Report

❌ Patch coverage is 14.52991% with 100 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.34%. Comparing base (5db32da) to head (b421017).
⚠️ Report is 12 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...ploads/class-webp-uploads-image-editor-imagick.php	0.00%	33 Missing ⚠️
...ealth/imagick-avif-transparency-support/helper.php	0.00%	23 Missing ⚠️
plugins/webp-uploads/helper.php	32.25%	21 Missing ⚠️
plugins/webp-uploads/hooks.php	28.57%	15 Missing ⚠️
...health/imagick-avif-transparency-support/hooks.php	0.00%	5 Missing ⚠️
plugins/webp-uploads/site-health/load.php	0.00%	2 Missing ⚠️
plugins/webp-uploads/load.php	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            trunk    #2245      +/-   ##
==========================================
- Coverage   69.17%   68.34%   -0.84%     
==========================================
  Files          90       94       +4     
  Lines        7708     7821     +113     
==========================================
+ Hits         5332     5345      +13     
- Misses       2376     2476     +100

Flag	Coverage Δ
multisite	`68.34% <14.52%> (-0.84%)`	⬇️
single	`35.04% <14.52%> (-0.35%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

westonruter · 2025-10-31T04:55:05Z

plugins/webp-uploads/hooks.php

+	$imagick = $image_property->getValue( $editor );
+
+	if ( $imagick instanceof Imagick ) {
+		wp_cache_set( 'webp_uploads_image_has_transparency', (bool) $imagick->getImageAlphaChannel(), 'webp-uploads' );


Is this set here in the cache since this function runs first and then later webp_uploads_get_image_output_format() runs to then read the value from the cache? This seems perhaps brittle. Normally setting and getting a cache value would happen in the context of the same function, not across separate functions, right? It feels like there may not be guarantees that the cached value would be set when it is checked for.

Yeah, it works but is definitely brittle. The other approach I can think of is using a global variable or a transient with a short expiration time to store the transparency status and hash of any uploaded file for the current request, and then using it in the webp_uploads_filter_image_editor_output_format to determine the output format. If you have any ideas for a temporary storage that can be used within the same request, I’d appreciate that.
@adamsilverstein if you also have a better idea to handle this case, I’d appreciate that as well.

If these are both part of the same request, perhaps you could apply a filter inside the webp_uploads_filter_image_editor_output_format function, then add a filter here to set the value?

There are multiple approaches. I came up with this to solve it:
The most elegant way is to replace the WP_Image_Editor_Imagick class with a custom class WebP_Uploads_Image_Editor_Imagick, which can be used to detect transparency and provide access to the protected variable.

But this will interfere with other plugins if they are trying to use their own custom class. I was thinking of just dynamically extending any custom classes extended from the WP_Image_Editor_Imagick class.

If these are both part of the same request, perhaps you could apply a filter inside the webp_uploads_filter_image_editor_output_format function, then add a filter here to set the value?

The issue I faced was with the subsize-image generation. The webp_uploads_filter_image_editor_output_format filter is called with an empty filename, so with this approach the sub-size images were getting generated as AVIF.

Because of that, the only way to check the current processing image calling the output-format filter is to access the $image of the image-editor instance that is processing it. But since the core does not expose the image-editor instance through globals or filters, there seems to be no way to determine the currently processed image. To solve this, the only idea I could come up with was using our own custom Image Editor class.

I have implemented the mentioned approach in this commit 2247b61.

cc: @adamsilverstein

westonruter · 2025-10-31T04:57:31Z

plugins/webp-uploads/hooks.php

+	$reflection     = new ReflectionClass( $editor );
+	$image_property = $reflection->getProperty( 'image' );
+	if ( PHP_VERSION_ID < 80100 ) {
+		$image_property->setAccessible( true );
+	}
+	$imagick = $image_property->getValue( $editor );


It's too bad that the image property is protected. Note how in the Image Placeholder plugin it actually extends WP_Image_Editor_Imagick with a Dominant_Color_Image_Editor_Imagick which it then uses. This is problematic though since multiple plugins can't each register their own editor classes.

I did try to create an anonymous class and added a method to expose the image property, but the Reflection API seemed better.

westonruter · 2025-10-31T05:00:57Z

plugins/webp-uploads/helper.php

+function webp_uploads_imagick_avif_transparency_supported(): bool {
+	if ( extension_loaded( 'imagick' ) && class_exists( 'Imagick' ) ) {
+		$imagick_version = Imagick::getVersion();
+		if ( (bool) preg_match( '/((?:[0-9]+\\.?)+)/', $imagick_version['versionString'], $matches ) ) {


Suggested change

if ( (bool) preg_match( '/((?:[0-9]+\\.?)+)/', $imagick_version['versionString'], $matches ) ) {

if ( (bool) preg_match( '/^\d+(?:\.\d+)+$/', $imagick_version['versionString'], $matches ) ) {

Updated regex to /\d+(?:\.\d+)+(?:-\d+)?/ for handling version string like this:

ImageMagick 7.1.1-15 Q16 aarch64 98eceff6a:20230729 https://imagemagick.org

Co-authored-by: Weston Ruter <westonruter@google.com>

…cy-loss

b1ink0 · 2025-11-14T12:33:18Z

plugins/webp-uploads/site-health/imagick-avif-transparency-support/hooks.php

Would it make more sense to move this Site Health test to the Modern Image Formats plugin?

Just seeing this comment. I think it makes sense to move all Site Health tests for images to the plugin. See #1781

…cy-loss

github-actions · 2025-12-26T13:05:59Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @johnmagbag1995, @wes-davis.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: johnmagbag1995, wes-davis.

Co-authored-by: b1ink0 <b1ink0@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: paulgibbs <djpaul@git.wordpress.org>
Co-authored-by: mindctrl <mindctrl@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

adamsilverstein · 2026-01-12T20:42:57Z

plugins/webp-uploads/site-health/imagick-avif-transparency-support/helper.php

+ * @since n.e.x.t
+ */
+
+// @codeCoverageIgnoreStart


I'm curious why this needs to be ignored for code coverage?

As far as I know, this section gets flagged by Codecov as the constant is always defined in the test environment, and as there is no way to undefine or modify a const value in PHP, we have to ignore it.

That's right. However, this could be made slightly more concise:

if ( ! defined( 'ABSPATH' ) ) { exit; // @codeCoverageIgnore }

This could be done at once for all files in the repo, since they all have it now, for example:

performance/plugins/performance-lab/load.php

Lines 18 to 22 in b4f9898

// @codeCoverageIgnoreStart

if ( ! defined( 'ABSPATH' ) ) {

exit; // Exit if accessed directly.

}

// @codeCoverageIgnoreEnd

plugins/webp-uploads/tests/test-helper.php

adamsilverstein · 2026-01-12T20:57:31Z

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

+			 * has been compiled against ImageMagick version 6.4.0 or newer.
+			 */
+			if ( is_callable( array( $this->image, 'getImageAlphaChannel' ) ) ) {
+				if ( ! $this->image->getImageAlphaChannel() ) {


Here you should explicitly check against Imagick::ALPHACHANNEL_UNDEFINED. getImageAlphaChannel returned an int initially, a boolean later.

Done in 991d7c9.

adamsilverstein · 2026-01-12T20:58:24Z

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

+			 * has been compiled against ImageMagick version 6.4.0 or newer.
+			 */
+			if ( is_callable( array( $this->image, 'getImageAlphaChannel' ) ) ) {
+				if ( ! $this->image->getImageAlphaChannel() ) {


Have you checked that this works correctly with PNG, WebP and AVIF uploads with transparencies?

adamsilverstein · 2026-01-12T21:01:10Z

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

+			}
+
+			// Walk through the pixels and look transparent pixels.
+			$w = $this->image->getImageWidth();


this strikes me as very heavy and deserving of caching at the very least to avoid repeating.

I would also be fine saying Imagick 6.4 is required for transparency support :)

Done in fece741.

adamsilverstein · 2026-01-12T21:04:37Z

plugins/webp-uploads/helper.php

+	$avif_support = webp_uploads_mime_type_supported( 'image/avif' );
+
+	if ( $avif_support && webp_uploads_check_image_transparency( $filename ) ) {
+		$avif_support = false;


~~AVIF should still be supported in Imagick is new enough, right? this line sets it as false if the image has a transparency without regard to the Imagick version.~~

misread that call ^^

adamsilverstein · 2026-01-12T21:10:47Z

@b1ink0 - overall this looks very good!

I wonder if this belongs in core directly: does this impact AVIF with transparency uploads in core (without the upload transform from PNG->AVIF)? If so this probably belongs in core directly since we aim to support AVIF as completely as possible. You probably noticed the existing PNG transparency handling in core, we could add similar handling for AVIFs.

b1ink0 · 2026-01-12T21:20:32Z

@adamsilverstein I was just thinking all this complex logic is just so that if an image does not have transparency and the site has an AVIF transparency unsupported version of ImageMagick, we allow the AVIF conversion. The simplest way could be to turn off AVIF conversion completely, even for non-transparent images.

plugins/webp-uploads/helper.php

plugins/webp-uploads/tests/test-helper.php

adamsilverstein · 2026-01-12T21:46:37Z

@adamsilverstein I was just thinking all this complex logic is just so that if an image does not have transparency and the site has an AVIF transparency unsupported version of ImageMagick, we allow the AVIF conversion. The simplest way could be to turn off AVIF conversion completely, even for non-transparent images.

Thats fine for the plugin! Happy to see this fix land here. I'm just thinking we may also be able to introduce a more general fix in core to handle this case. I will check to see if we have an existing ticket for this.

…cy-loss

…ilename parameter by defaulting it to null Co-authored-by: Weston Ruter <westonruter@google.com>

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

Co-authored-by: Adam Silverstein <adamjs@google.com>

b1ink0 · 2026-01-15T20:23:45Z

I wonder if this belongs in core directly: does this impact AVIF with transparency uploads in core (without the upload transform from PNG->AVIF)? If so this probably belongs in core directly since we aim to support AVIF as completely as possible. You probably noticed the existing PNG transparency handling in core, we could add similar handling for AVIFs.

I’m not sure about a Core integration, since this is an edge case and would affect a very small number of sites. I’m also unsure whether this belongs in Core at all, as we’re doing a very specific check whether the ImageMagick version is less than 7.0.25. But I think if there is no ticket regarding this it should be opened to discuss it further.

Co-authored-by: Adam Silverstein <adamjs@google.com>

…cy-loss

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

westonruter · 2026-01-20T23:39:20Z

plugins/webp-uploads/hooks.php

+	$key = array_search( WP_Image_Editor_Imagick::class, $editors, true );
+	if ( false !== $key ) {
+		$editors[ $key ] = WebP_Uploads_Image_Editor_Imagick::class;
+	}


Will this not unfortunately conflict with Dominant Color Images?

performance/plugins/dominant-color-images/helper.php

Lines 32 to 42 in 34445d4

$replaces = array(

WP_Image_Editor_GD::class => Dominant_Color_Image_Editor_GD::class,

WP_Image_Editor_Imagick::class => Dominant_Color_Image_Editor_Imagick::class,

);

foreach ( $replaces as $old => $new ) {

$key = array_search( $old, $editors, true );

if ( false !== $key ) {

$editors[ $key ] = $new;

}

}

The fallback to the WP_Image_Editor_GD class was making the Dominant Color Images work, but that still wasn’t correct.

I’ve updated the logic to unshift the WebP_Uploads_Image_Editor_Imagick class instead of replacing WP_Image_Editor_Imagick class.

Done in 717e768.

Will this work still? I'm looking at _wp_image_editor_choose() in core, and it seems it loops over the array to find the first one that works. In other words, it seems like it is not possible for both the implementation in Modern Image Formats and the implementation in Image Placeholders to both be active. So if the issue is fixed here with AVIF, does this mean that the dominant color is no longer getting extracted from the image?

Yes, it will work. Dominant Color Images doesn’t rely solely on what _wp_image_editor_choose() returns by default, it passes specific arguments to ensure it gets a class that implements the get_dominant_color and has_transparency methods. I’ve tested this solution, and it works correctly. Also, this class is used temporarily and is removed as soon as its task is complete. See below:

performance/plugins/dominant-color-images/helper.php

Lines 97 to 114 in 34445d4

add_filter( 'wp_image_editors', 'dominant_color_set_image_editors' );

/**

* Editor.

*

* @see dominant_color_set_image_editors()

* @var WP_Image_Editor|Dominant_Color_Image_Editor_GD|Dominant_Color_Image_Editor_Imagick|WP_Error $editor

*/

$editor = wp_get_image_editor(

$file,

array(

'methods' => array(

'get_dominant_color',

'has_transparency',

),

)

);

remove_filter( 'wp_image_editors', 'dominant_color_set_image_editors' );

Co-authored-by: Weston Ruter <westonruter@google.com>

b1ink0 · 2026-01-21T19:06:43Z

I’d like feedback on the approach I mentioned here: #2245 (comment)

The idea is to dynamically extend the active image editor class. If a third-party plugin has extended WP_Image_Editor_Imagick, we would extend that class itself (as long as it’s not a final class), instead of assuming the core class directly.

I have added a temp commit with a POC: c033c44.

cc: @westonruter @adamsilverstein

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 12 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-22T06:23:29Z

plugins/webp-uploads/hooks.php

+
+	if ( ! class_exists( 'WebP_Uploads_Image_Editor_Imagick_Base' ) ) {
+		if ( WP_Image_Editor_Imagick::class !== $editors[0] ) {
+			if ( ! is_subclass_of( WP_Image_Editor_Imagick::class, $editors[0] ) ) {


The is_subclass_of() parameters are in the wrong order. The first parameter should be the child class and the second parameter should be the parent class. Currently, this checks if WP_Image_Editor_Imagick is a subclass of $editors[0], when it should check if $editors[0] is a subclass of WP_Image_Editor_Imagick. The parameters should be swapped to is_subclass_of($editors[0], WP_Image_Editor_Imagick::class).

Suggested change

if ( ! is_subclass_of( WP_Image_Editor_Imagick::class, $editors[0] ) ) {

if ( ! is_subclass_of( $editors[0], WP_Image_Editor_Imagick::class ) ) {

Alternatively, instanceof is easier to read and generally better, AFAIK.

The issue is that we don’t have an instance here we only have the class name as a string. That’s why I used is_subclass_of().

Copilot · 2026-01-22T06:23:29Z

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

+				// Walk through the pixels and look transparent pixels.
+				$w = $this->image->getImageWidth();
+				$h = $this->image->getImageHeight();
+				for ( $x = 0; $x < $w; $x++ ) {
+					for ( $y = 0; $y < $h; $y++ ) {
+						$pixel = $this->image->getImagePixelColor( $x, $y );
+						$color = $pixel->getColor( 2 );
+						if ( $color['a'] > 0 && $color['a'] < 255 ) {
+							self::$checked_images[ $file_path ] = true;
+							return true;
+						}
+					}
+				}


This function walks through every pixel in the image to check for transparency, which can be extremely slow for large images. For example, a 4000x3000 pixel image would require 12 million iterations. Consider implementing sampling (checking a subset of pixels) or early exit strategies, or using alternative Imagick methods like getImageAlphaChannel combined with histogram analysis to detect transparency more efficiently.

Suggested change

// Walk through the pixels and look transparent pixels.

$w = $this->image->getImageWidth();

$h = $this->image->getImageHeight();

for ( $x = 0; $x < $w; $x++ ) {

for ( $y = 0; $y < $h; $y++ ) {

$pixel = $this->image->getImagePixelColor( $x, $y );

$color = $pixel->getColor( 2 );

if ( $color['a'] > 0 && $color['a'] < 255 ) {

self::$checked_images[ $file_path ] = true;

return true;

}

}

}

// Use the image histogram to look for partially transparent pixels more efficiently.

$histogram = $this->image->getImageHistogram();

foreach ( $histogram as $pixel ) {

// Get normalized color values (0-1), including alpha channel.

$color = $pixel->getColor( true );

// Match previous behavior: consider pixels with partial transparency only.

if ( isset( $color['a'] ) && $color['a'] > 0 && $color['a'] < 1 ) {

self::$checked_images[ $file_path ] = true;

return true;

}

}

I’m not sure about this. Histogram calculation can also be expensive, and a large image like 4000×3000 could have millions of unique colors. It might be faster for smaller images, though. I’ll run some tests with different types of images first to get actual numbers.

What about using getImageChannelMean method.

Copilot · 2026-01-22T06:23:29Z

plugins/webp-uploads/helper.php

+	if ( 'avif' !== webp_uploads_get_image_output_format() || webp_uploads_imagick_avif_transparency_supported() || ! class_exists( 'WebP_Uploads_Image_Editor_Imagick' ) ) {
+		return false;
+	}
+
+	if ( null === $filename ) {
+		if ( null === WebP_Uploads_Image_Editor_Imagick::$current_instance ) {
+			return false;
+		}
+		$file = WebP_Uploads_Image_Editor_Imagick::$current_instance->get_file();
+		if ( '' === $file ) {
+			return false;
+		}
+		$filename = $file;
+	}
+
+	if ( ! is_string( $filename ) || ! file_exists( $filename ) ) {
+		return false;
+	}
+
+	if ( isset( $processed_images[ $filename ] ) ) {
+		return $processed_images[ $filename ];
+	}
+	$processed_images[ $filename ] = false;
+
+	$editor = wp_get_image_editor( $filename );


There's a circular dependency risk here. The function webp_uploads_check_image_transparency() calls wp_get_image_editor() at line 578, which triggers the 'wp_image_editors' filter (line 1018 in hooks.php). That filter callback webp_uploads_set_image_editors() loads the WebP_Uploads_Image_Editor_Imagick class, but that class is only needed if webp_uploads_check_image_transparency() returns true. However, webp_uploads_check_image_transparency() checks for the class existence at line 554, which can create a chicken-and-egg problem. This could lead to the transparency check being skipped when it shouldn't be, or infinite recursion in some edge cases.

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

Copilot · 2026-01-22T06:23:30Z

plugins/webp-uploads/helper.php

+/**
+ * Checks if Imagick has AVIF transparency support.
+ *
+ * @since n.e.x.t
+ *
+ * @return bool True if Imagick has AVIF transparency support, false otherwise.
+ */
+function webp_uploads_imagick_avif_transparency_supported(): bool {
+	if ( extension_loaded( 'imagick' ) && class_exists( 'Imagick' ) ) {
+		$imagick_version = Imagick::getVersion();
+		if ( (bool) preg_match( '/\d+(?:\.\d+)+(?:-\d+)?/', $imagick_version['versionString'], $matches ) ) {
+			$imagick_version = $matches[0];
+		} else {
+			$imagick_version = $imagick_version['versionString'];
+		}
+		return version_compare( $imagick_version, '7.0.25', '>=' );
+	}
+
+	return false;
+}
+
+/**
+ * Checks if an AVIF image has transparency
+ *
+ * @since n.e.x.t
+ *
+ * @param string|null $filename The uploaded file name.
+ * @return bool Whether the image has transparency.
+ */
+function webp_uploads_check_image_transparency( ?string $filename ): bool {
+	static $processed_images = array();
+
+	if ( 'avif' !== webp_uploads_get_image_output_format() || webp_uploads_imagick_avif_transparency_supported() || ! class_exists( 'WebP_Uploads_Image_Editor_Imagick' ) ) {
+		return false;
+	}
+
+	if ( null === $filename ) {
+		if ( null === WebP_Uploads_Image_Editor_Imagick::$current_instance ) {
+			return false;
+		}
+		$file = WebP_Uploads_Image_Editor_Imagick::$current_instance->get_file();
+		if ( '' === $file ) {
+			return false;
+		}
+		$filename = $file;
+	}
+
+	if ( ! is_string( $filename ) || ! file_exists( $filename ) ) {
+		return false;
+	}
+
+	if ( isset( $processed_images[ $filename ] ) ) {
+		return $processed_images[ $filename ];
+	}
+	$processed_images[ $filename ] = false;
+
+	$editor = wp_get_image_editor( $filename );
+
+	if ( is_wp_error( $editor ) || ! $editor instanceof WebP_Uploads_Image_Editor_Imagick ) {
+		return false;
+	}
+
+	$has_transparency              = $editor->has_transparency();
+	$processed_images[ $filename ] = is_wp_error( $has_transparency ) ? false : $has_transparency;
+
+	return $processed_images[ $filename ];
+}


The new transparency checking functionality lacks test coverage. The repository has comprehensive test coverage for other functions (test-helper.php, test-load.php, etc.), but no tests are present for webp_uploads_imagick_avif_transparency_supported(), webp_uploads_check_image_transparency(), or the WebP_Uploads_Image_Editor_Imagick::has_transparency() method. Given the complexity and critical nature of this transparency detection logic, unit tests should be added to verify correct behavior.

@copilot open a new pull request to add test coverage based on this feedback

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php

plugins/webp-uploads/helper.php

Copilot · 2026-01-22T06:23:31Z

plugins/webp-uploads/hooks.php

+function webp_uploads_set_image_editors( array $editors ): array {
+	if ( 'avif' !== webp_uploads_get_image_output_format() || webp_uploads_imagick_avif_transparency_supported() ) {
+		return $editors;
+	}
+
+	if ( 0 === count( $editors ) || false === array_search( WP_Image_Editor_Imagick::class, $editors, true ) ) {
+		return $editors;
+	}
+
+	if ( ! class_exists( $editors[0] ) ) {
+		return $editors;
+	}
+
+	if ( ! class_exists( 'WebP_Uploads_Image_Editor_Imagick_Base' ) ) {
+		if ( WP_Image_Editor_Imagick::class !== $editors[0] ) {
+			if ( ! is_subclass_of( WP_Image_Editor_Imagick::class, $editors[0] ) ) {
+				return $editors;
+			} else {
+				$reflection = new ReflectionClass( $editors[0] );
+				if ( $reflection->isFinal() ) {
+					return $editors;
+				}
+				class_alias( $editors[0], 'WebP_Uploads_Image_Editor_Imagick_Base' );
+			}
+		} else {
+			class_alias( WP_Image_Editor_Imagick::class, 'WebP_Uploads_Image_Editor_Imagick_Base' );
+		}
+	}
+
+	if ( ! class_exists( 'WebP_Uploads_Image_Editor_Imagick' ) ) {
+		require_once __DIR__ . '/class-webp-uploads-image-editor-imagick.php'; // @codeCoverageIgnore
+	}
+
+	array_unshift( $editors, WebP_Uploads_Image_Editor_Imagick::class );
+
+	return $editors;
+}
+add_filter( 'wp_image_editors', 'webp_uploads_set_image_editors' );


The webp_uploads_set_image_editors() function lacks test coverage. Given the repository's comprehensive test coverage for other functions and the complex conditional logic with class aliasing in this function (lines 981-1018), tests should be added to verify correct editor registration behavior under different scenarios: when AVIF support exists, when it doesn't, with different editor configurations, etc.

@copilot open a new pull request to add test coverage based on this feedback

plugins/webp-uploads/helper.php

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

adamsilverstein · 2026-01-22T20:08:56Z

@b1ink0 overall I think the temporary approach is good, bravo for figuring that out. I asked @copilot to work on some additional test coverage it suggested which should result in PRs against your branch you can review.

Add support for AVIF transparency checks during image uploads

ae7f22d

b1ink0 added this to the webp-uploads n.e.x.t milestone Oct 30, 2025

b1ink0 added [Type] Bug An existing feature is broken [Plugin] Modern Image Formats Issues for the Modern Image Formats plugin (formerly WebP Uploads) labels Oct 30, 2025

westonruter requested changes Oct 31, 2025

View reviewed changes

b1ink0 and others added 3 commits November 3, 2025 02:04

Improve Imagick version string regex validation

a1aff66

Co-authored-by: Weston Ruter <westonruter@google.com>

Merge branch 'trunk' into fix/imagemagick-old-version-avif-transparen…

be0817b

…cy-loss

Add site health checks for Imagick AVIF transparency support

3fe6954

b1ink0 commented Nov 14, 2025

View reviewed changes

westonruter mentioned this pull request Nov 20, 2025

Transparent backgrounds lost when converting to AVIF under certain conditions #2237

Open

b1ink0 added 3 commits December 17, 2025 19:23

Add custom image editor class to help with AVIF transparency detection

2247b61

Move Imagick AVIF transparency support site health test

1a58d1c

Merge branch 'trunk' into fix/imagemagick-old-version-avif-transparen…

fdf65ec

…cy-loss

b1ink0 marked this pull request as ready for review December 26, 2025 13:05

b1ink0 requested a review from felixarntz as a code owner December 26, 2025 13:05

westonruter modified the milestones: webp-uploads 2.6.1, webp-uploads n.e.x.t Jan 6, 2026

adamsilverstein reviewed Jan 12, 2026

View reviewed changes

plugins/webp-uploads/tests/test-helper.php Outdated Show resolved Hide resolved

adamsilverstein reviewed Jan 12, 2026

View reviewed changes

westonruter reviewed Jan 12, 2026

View reviewed changes

Merge branch 'trunk' into fix/imagemagick-old-version-avif-transparen…

50f2be1

…cy-loss

Allow webp_uploads_get_upload_image_mime_transforms() to omit the f…

f8af1e9

…ilename parameter by defaulting it to null Co-authored-by: Weston Ruter <westonruter@google.com>

westonruter requested a review from Copilot January 13, 2026 21:33

Copilot started reviewing on behalf of westonruter January 13, 2026 21:33 View session

Copilot AI reviewed Jan 13, 2026

View reviewed changes

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php Outdated Show resolved Hide resolved

Add explicit return value check for getImageAlphaChannel method

991d7c9

Co-authored-by: Adam Silverstein <adamjs@google.com>

b1ink0 and others added 4 commits January 20, 2026 21:58

Add transparency check caching to custom image editor class

fece741

Co-authored-by: Adam Silverstein <adamjs@google.com>

Merge branch 'trunk' into fix/imagemagick-old-version-avif-transparen…

9020b24

…cy-loss

Refactor to use filename instead of file hash for transparency check

435f5ff

Fix transparency detection to exclude fully opaque pixels

4da1758

b1ink0 commented Jan 20, 2026

View reviewed changes

plugins/webp-uploads/class-webp-uploads-image-editor-imagick.php Outdated Show resolved Hide resolved

westonruter reviewed Jan 20, 2026

View reviewed changes

b1ink0 and others added 2 commits January 21, 2026 23:26

Fix image editor confilict with Dominant Color Images

717e768

Co-authored-by: Weston Ruter <westonruter@google.com>

Dynimacally extend the image editor class

c033c44

westonruter requested a review from Copilot January 22, 2026 06:17

Copilot started reviewing on behalf of westonruter January 22, 2026 06:17 View session

Copilot AI reviewed Jan 22, 2026

View reviewed changes

b1ink0 and others added 6 commits January 22, 2026 22:21

Fix parameters order in is_subclass_of

b28885e

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Simplify conditional checks

6004d18

Fix transparency detection for fully transparent images

d218d0f

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Improve doc comments

41f94e1

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Skip unnecessary transparency check when image format is already WebP

28f2583

Improve doc comments

b421017

	if ( (bool) preg_match( '/((?:[0-9]+\\.?)+)/', $imagick_version['versionString'], $matches ) ) {
	if ( (bool) preg_match( '/^\d+(?:\.\d+)+$/', $imagick_version['versionString'], $matches ) ) {

	// @codeCoverageIgnoreStart
	if ( ! defined( 'ABSPATH' ) ) {
	exit; // Exit if accessed directly.
	}
	// @codeCoverageIgnoreEnd

	$replaces = array(
	WP_Image_Editor_GD::class => Dominant_Color_Image_Editor_GD::class,
	WP_Image_Editor_Imagick::class => Dominant_Color_Image_Editor_Imagick::class,
	);

	foreach ( $replaces as $old => $new ) {
	$key = array_search( $old, $editors, true );
	if ( false !== $key ) {
	$editors[ $key ] = $new;
	}
	}

	add_filter( 'wp_image_editors', 'dominant_color_set_image_editors' );

	/**
	* Editor.
	*
	* @see dominant_color_set_image_editors()
	* @var WP_Image_Editor\|Dominant_Color_Image_Editor_GD\|Dominant_Color_Image_Editor_Imagick\|WP_Error $editor
	*/
	$editor = wp_get_image_editor(
	$file,
	array(
	'methods' => array(
	'get_dominant_color',
	'has_transparency',
	),
	)
	);
	remove_filter( 'wp_image_editors', 'dominant_color_set_image_editors' );

	if ( ! is_subclass_of( WP_Image_Editor_Imagick::class, $editors[0] ) ) {
	if ( ! is_subclass_of( $editors[0], WP_Image_Editor_Imagick::class ) ) {

Prevent transparency loss in AVIF by falling back to WebP on older ImageMagick #2245

Are you sure you want to change the base?

Prevent transparency loss in AVIF by falling back to WebP on older ImageMagick #2245

Conversation

b1ink0 commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Relevant technical choices

Uh oh!

codecov bot commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b1ink0 Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b1ink0 Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Dec 26, 2025

Unlinked Accounts

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamsilverstein Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamsilverstein commented Jan 12, 2026

Uh oh!

b1ink0 commented Jan 12, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adamsilverstein commented Jan 12, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

b1ink0 commented Oct 30, 2025 •

edited

Loading

codecov bot commented Oct 30, 2025 •

edited

Loading

b1ink0 Dec 17, 2025 •

edited

Loading

b1ink0 Nov 14, 2025 •

edited

Loading

adamsilverstein Jan 12, 2026 •

edited

Loading

b1ink0 commented Jan 21, 2026 •

edited

Loading