Featured image block: The default `aspectRatio` set in `theme.json` doesn't work

[shimotmk]

Description

The default aspectRatio set in theme.json doesn't work

Step-by-step reproduction instructions

1. Add the following code to the default settings of the block in theme.json.

"core/post-featured-image": {
	"dimensions": {
		"aspectRatio": "1"
	}
},

2. Go to post or page and place the Featured image block.

3. You will see that the CSS for the default aspect ratio does not work.

gutenberg/packages/block-library/src/post-featured-image/index.php

Lines 44 to 46 in 951879a

	if ( ! empty( $attributes['aspectRatio'] ) ) {
	$extra_styles .= 'width:100%;height:100%;';
	} elseif ( ! empty( $attributes['height'] ) ) {

Related：#47271

Screenshots, screen recording, code snippet

f.mp4

Environment info

WordPress version: 6.7.2
Twenty Twenty-Five
Gutenberg: version: 20.6.0-rc.1

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[yogeshbhutkar]

Thanks for the issue!

I can replicate this on the Image block as well.

[Sourav61]

Thanks for raising this issue! I can confirm that I am able to reproduce the above issue with the default aspectRatio not being applied as expected in the theme.json settings for the Featured Image block. It seems that the block's attributes are not being updated with properties added in the theme.json.

I think I have been able to partially fix this issue, as can be seen The below code uses a switch statement to migrate the theme_json object from version 1 to 2, and then from version 2 to 3. The fall-through mechanism allows it to migrate through versions sequentially.

lib/class-wp-theme-json-schema-gutenberg.php

// Migrate each version in order starting with the current version.
switch ( $theme_json['version'] ) {
	case 1:
		$theme_json = self::migrate_v1_to_v2( $theme_json );
		// Deliberate fall through. Once migrated to v2, also migrate to v3.
	case 2:
		$theme_json = self::migrate_v2_to_v3( $theme_json, $origin );
}

return $theme_json;

Adding a case for version 3 of theme.json for handling migration from version 3 to the next version, ensuring proper handling of all theme versions and preventing missed migrations.

However even after adding this case statement, our original issue is still not fixed, will need some more debugging.

[t-hamano]

@Sourav61 theme.json version 4 doesn't exist yet, so we can't migrate from version 3 to version 4.

our original issue is still not fixed, will need some more debugging.

First, let's find out why the problem occurs and identify the root cause.

[t-hamano]

In My understanding, the img element inside the Post Featured Image block is expected to have a height:100% style when the aspectRatio is applied.

However, when the style is applied via the theme.json, the block instance itself doesn't have the aspect ratio attribute applied, so the height style doesn't get applied to the img element.

I think this is the cause. Is this correct?

My guess is that when this support was added, it didn't take into account the scenario where default styles are added via theme.json, so some new ideas or approaches may be needed to solve the issue.

[yogeshbhutkar]

I did some research on this issue, and here are my findings:

When the style is applied via theme.json, the block instance itself doesn’t have the aspect ratio attribute applied, so the height style doesn’t get applied to the <img /> element.

I found that while the aspectRatio property correctly applies to the <figure />, the inner <img /> lacks height: 100%, preventing it from filling the available space. Interestingly, toggling the aspectRatio to any value and back to original adds height: 100%; width: 100%; object-fit: cover to the <img />, though these styles are missing when the image is first uploaded.

The <img /> should always have these styles because:

1. The original preset includes them by default.
2. Without an explicit aspectRatio, <figure /> naturally adjusts to the <img /> size (its height and width), so applying height: 100%; width: 100% ensures the image scales properly when an aspect ratio is introduced.

Here's a demo of the above changes:

720p.mov

Caption: Observe the change in aspect ratio

As the previous associated PR is closed, I'd like to open a new PR for this issue.

[t-hamano]

I've been thinking about this issue again, and I think the root problem is that we are trying to add aspectRatio style via theme.json even though the Post Featured Image block doesn't have aspectRatio block support What the Post Featured Image block has is the aspectRatio attribute, not the aspectRatio block support.

Ideally, we'd like to migrate the aspectRatio attribute in the Post Featured Image block to block support. However, that might be a very complicated task due to backwards compatibility issues.

[yogeshbhutkar]

Ideally, we'd like to migrate the aspectRatio attribute in the Post Featured Image block to block support. However, that might be a very complicated task due to backwards compatibility issues.

Hi, @t-hamano. Could you test #69790 and suggest a way forward? Should we keep the proposed changes in the PR for now? (considering the complexity due to backward compatibility), or take the more challenging approach?

Edit: I believe it's the same for the image block as well; it uses the aspectRatio attribute and not the block support and migrating that might also come with certain backwards compatibility issues.

[t-hamano]

Could you test #69790 and suggest a way forward? Should we keep the proposed changes in the PR for now? (considering the complexity due to backward compatibility), or take the more challenging approach?

Personally, it's difficult to say for sure whether this issue itself is a bug, because we're trying to apply styles via theme.json that the block doesn't support in the first place.

It's weird that the block itself doesn't have the block support, but it tries to take into account styles provided by theme.json.

I would like to propose to stop #69790 and migrate to block support, but I have not yet been able to clarify the issues that need to be resolved 😅