Image migration logic causes editor to break when editing image attributes dynamically

[artemiomorales]

Description

When editing image attributes dynamically via PHP, the image's block may become invalid, causing the migration logic to run in the image block's deprecated.js.

We should add a check to make sure the required behaviors and behaviors.lightbox values exist in the attributes object during the migration to prevent this breakage.

Alternatively, we can review and revise the logic for determining whether a migration should run.

Please see this forum post for more details.

Step-by-step reproduction instructions

1. Add the following code to your theme's functions.php to modify one of the image block's attributes:

add_filter( 'block_type_metadata', 'set_image_auto_centre' );

function set_image_auto_centre( $metadata ) {
  if ( 'core/image' !== $metadata['name'] ) {
    return $metadata;
  }
  $metadata['attributes']['align']['default'] = 'center';

  return $metadata;
}

2. Open the WordPress admin and try adding a new post.
3. See that the editor breaks.

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.4 with Gutenberg

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

[artemiomorales]

I've created a potential fix for this.

I just add a check in the migration logic to make sure the values we expect exist. That seems to be most straightforward fix for now. We could also consider whether a deeper fix is necessary.

As of now, if one edits the attributes of any blocks, causing a change in the block’s markup, the migration logic will run — see this function where non-matching class names as a result of modifying the image alignment were causing the block validation to fail. Note: The reason this appears to break when attempting to add a new post is that the migration is run for patterns that contain the modified blocks.

On one hand, we could expect developers adding new deprecations to add a check to see if attributes exist before applying any changes. If taking this approach, it could be beneficial to add a note to the docs reminding developers to do that, as they may not expect users to modify block attributes in their functions.php and cause block invalidation.

On the other hand, we could devise additional handling for this seemingly common use case of folks modifying block attributes dynamically — see the linked forum thread for details.

Any thoughts appreciated! 🙏