Skip to content

Recover image dimensions when base metadata is incomplete (1x1 WebP)#2542

Draft
adamsilverstein wants to merge 2 commits into
WordPress:trunkfrom
adamsilverstein:fix/2468-recover-incomplete-image-metadata
Draft

Recover image dimensions when base metadata is incomplete (1x1 WebP)#2542
adamsilverstein wants to merge 2 commits into
WordPress:trunkfrom
adamsilverstein:fix/2468-recover-incomplete-image-metadata

Conversation

@adamsilverstein

Copy link
Copy Markdown
Member

Summary

Addresses the intermittent "1×1 px WebP" bug reported in #2468.

Root cause

The reporter's stored metadata for a broken attachment contained only the keys added by the performance plugins and none of the base metadata that core normally produces:

array(
  'dominant_color'   => '757863',
  'has_transparency' => false,
  'sources'          => array( 'image/webp' => array( ... ) ),
)

No width, height, file, or sizes. That happens when core's wp_create_image_subsizes() bails early:

$imagesize = wp_getimagesize( $file );
if ( empty( $imagesize ) ) {
    return array(); // no width/height/sizes
}

wp_getimagesize() can fail intermittently at upload time (e.g. the file is read before it has finished being written to disk). Core then returns an empty array, the wp_generate_attachment_metadata filters decorate it, and the incomplete record is persisted. With width/height missing, core's wp_constrain_dimensions() clamps the dimensions to max( 1, 0 ) = 1, which is why the image renders at 1×1 in the Media Library grid and in the front-end HTML, even though the file itself opens fine. This also explains the "random / works on re-upload" behavior: re-uploading creates a fresh attachment that usually processes cleanly.

The change

By the time webp_uploads_create_sources_property() runs, the file is readable again (the sources and dominant_color keys prove the file was read successfully a moment later). So when the base metadata is missing its dimensions, the filter now recovers width/height from the file before attaching the sources property. If the file still can't be read, it bails without inventing dimensions or persisting a partial record.

This restores correct display of the full-size image. Responsive sub-sizes (sizes) are still absent in this failure case and require regenerating the attachment (wp media regenerate <id>).

Why only the webp-uploads plugin

dominant-color-images is intentionally designed to extract the dominant color independently of base metadata (see test-dominant-color.php, which asserts the color is added even when the incoming metadata is array()). The dominant_color key in the corrupted record is a witness, not a cause, so that plugin is left unchanged.

Testing

  • test_it_should_recover_dimensions_when_base_metadata_is_incomplete — passes incomplete metadata and asserts the real dimensions are recovered and sources attached.
  • test_it_should_not_decorate_metadata_when_file_is_missing — asserts no dimensions are invented and no sources added when the file can't be read.

Open questions / follow-ups

  • This is a mitigation at the plugin layer. The underlying trigger is core returning empty metadata on an intermittent wp_getimagesize() failure; a more complete fix (retry, or regenerating sub-sizes) may warrant a core Trac ticket.
  • Draft pending a green CI run of the new tests.

Refs #2468

When wp_create_image_subsizes() cannot read an upload (an intermittent
race where the file is read before it has finished being written), core
returns attachment metadata without width/height/sizes. The Modern Image
Formats filter then decorates and persists that record, leaving the
attachment rendering at 1x1 pixels in the Media Library and on the front
end while the file itself opens fine.

Recover the original dimensions from the now-readable file before adding
the sources property so the full-size image displays correctly, and bail
without persisting a partial record when the file still cannot be read.
Responsive sub-sizes still require regenerating the attachment.

Refs WordPress#2468
@github-actions github-actions Bot added the [Plugin] Modern Image Formats Issues for the Modern Image Formats plugin (formerly WebP Uploads) label Jun 19, 2026
@codecov

codecov Bot commented Jun 19, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 69.90%. Comparing base (ea77bb1) to head (1728208).
⚠️ Report is 151 commits behind head on trunk.

Files with missing lines Patch % Lines
plugins/webp-uploads/hooks.php 83.33% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##            trunk    #2542      +/-   ##
==========================================
+ Coverage   69.87%   69.90%   +0.03%     
==========================================
  Files          90       90              
  Lines        7797     7803       +6     
==========================================
+ Hits         5448     5455       +7     
+ Misses       2349     2348       -1     
Flag Coverage Δ
multisite 69.90% <83.33%> (+0.03%) ⬆️
single 35.31% <16.66%> (-0.02%) ⬇️

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

☔ View full report in Codecov by Harness.
📢 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.

@adamsilverstein adamsilverstein self-assigned this Jun 19, 2026
@adamsilverstein adamsilverstein added the [Type] Bug An existing feature is broken label Jun 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Plugin] Modern Image Formats Issues for the Modern Image Formats plugin (formerly WebP Uploads) [Type] Bug An existing feature is broken

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant