[abhishekfdd]

wp_image_src_get_dimensions() reads $image_meta['width'] and $image_meta['height'] in its full size branch without checking that they exist. When attachment meta has a file key but lacks dimensions (metadata written by SVG plugins, importers, or custom upload handling), this triggers "Undefined array key" warnings and the function returns array( 0, 0 ).

This PR requires width and height to be set before taking the full size branch, so the function returns false in this case, matching its documented return value.

Note that stock core doesn't produce this meta shape. For SVGs, core stores only filesize, so the branch isn't reached on a plain upload. The bug shows up with plugin or import written meta.

Impact

• Removes the warnings.
• Rendered output is unchanged. Both core callers, wp_image_add_srcset_and_sizes() and wp_img_tag_add_width_and_height_attr(), already rejected array( 0, 0 ).
• Code hooked on the wp_image_src_get_dimensions filter now receives false instead of a misleading [0, 0].
• In the srcset path, the function now exits before the wp_calculate_image_srcset_meta filter, which it previously reached with zero dimensions.

This keeps the function's existing contract, same approach as #14861 for #57813, which guards the reads in wp_get_missing_image_subsizes() without changing its return value.

Testing

New test class Tests_Media_wpImageSrcGetDimensions:

• Missing dimension cases via data provider (both missing, width only missing, height only missing): on trunk all fail with the "Undefined array key" warning. With this fix they pass and return false.
• Control test: meta with valid width and height still returns the correct dimensions.

Manual A/B on trunk vs this branch: with meta set to file without dimensions, trunk logs warnings at media.php:1825/1826 on both wp_get_attachment_image() and a front end Image block render. This branch is silent. Rendered <img> markup is identical on both.

Commands:

npm run test:php -- --filter Tests_Media_wpImageSrcGetDimensions
npm run test:php -- --group media

All pass. phpcs shows no new issues.

Trac ticket: https://core.trac.wordpress.org/ticket/62312

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Local environment setup, implementing the fix, writing unit tests, verifying callers, and running the manual A/B reproduction; the changes were reviewed by me.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

Core Committers: Use this line as a base for the props when committing in SVN:

Props abhishekfdd.

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

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.