Core/Image block validation errors in Block Patterns UI

[colis]

Bug Description

Block Patterns that use Cloudinary images trigger validation errors when viewed/edited from the dedicated Block Patterns admin UI (accessible at /wp-admin/site-editor.php?postType=wp_block).

Despite being able to fix the validation error by clicking the "Attempt Block Recovery" button, the issue reappears on subsequent page loads.

It looks like a number of additional HTML attributes are being added to the markup but not saved to the DB, which is what seems to trigger the validation errors.

Content generated by `save` function:

<figure class="wp-block-image size-full"><img src="https://res.cloudinary.com/{app-name}/images/w_900,h_506,c_scale/v1708013415/media/820598-edited/820598-edited.jpg?_i=AA" alt="" class="wp-image-567226" style="object-fit:cover"/><figcaption class="wp-element-caption">This is a caption</figcaption></figure>

Content retrieved from post body:

<figure class="wp-block-image size-full"><img width="900" height="506" data-public-id="media/820598-edited/820598-edited.jpg" src="https://res.cloudinary.com/{app-name}/images/w_900,h_506,c_scale/v1708013415/media/820598-edited/820598-edited.jpg?_i=AA" alt="" class="wp-image-567226" style="object-fit:cover" data-format="jpg" data-transformations="" data-version="1708013415" data-seo="1" srcset="https://res.cloudinary.com/{app-name}/images/v1708013415/media/820598-edited/820598-edited.jpg?_i=AA 900w, https://res.cloudinary.com/{app-name}/images/v1708013415/media/820598-edited/820598-edited.jpg?_i=AA 300w, https://res.cloudinary.com/{app-name}/images/v1708013415/media/820598-edited/820598-edited.jpg?_i=AA 768w" sizes="(max-width: 900px) 100vw, 900px" /><figcaption class="wp-element-caption">This is a caption</figcaption></figure>

Steps to reproduce

1. Create a block pattern that includes a core/image block with a Cloudinary image
2. Go to /wp-admin/site-editor.php?postType=wp_block
3. See the validation error appearing both in the Block Patterns listing page and in the Block Pattern edit page

Screenshots

Additional context

• WordPress version: 6.6.2
• Plugin version: 3.2.2
• PHP version: 8.1
• Plugin settings: Sync method manual, Storage Cloudinary and WordPress, Image Delivery ON, Image optimization OFF, Lazy loading OFF, Responsive images OFF

[Vdeub-cloudinary]

Hi @colis, Thanks for reporting the issue. It seems it is an edge case that bypassed the fix released in 3.2.2. I have been told a fix will be shipped in the next version for your issue. I'll keep you posted when I have more vision on when this will be released. Loic

[colis]

Hi @Vdeub-cloudinary and thanks for the update.

Just so you know, the issue also happens when saving a regular page, it doesn't seem to affect only block patterns. (version 3.2.2)

[jessica-townsend]

Hi @Vdeub-cloudinary,

I wanted to mention that a similar problem is happening for videos. I see a block recovery error on videos that are synced with Cloudinary from the site editor screen. Clicking “Attempt Block Recovery” seems to work, but the problem comes back after saving and returning to the site editor.

I'm using plugin version 3.2.3 and WordPress version 6.7.1

[Vdeub-cloudinary]

Hi @jessica-townsend, thanks for bringing this up. I can see the ticket is still open internally on our side and the team is still working on fixing those different cases. I'll update you when the next version is released :)

[colis]

Hi @Vdeub-cloudinary

with the latest version of the plugin (3.2.4) most of the validation issues have been fixed, however there is still one remaining

Content generated by `save` function:

<img class="wp-block-cover__image-background wp-image-526285" alt="" src="https://res.cloudinary.com/mecum/images/v1700168153/media/mecum-auctions-on-time-2023-micro-car-collection-schedule-hero/mecum-auctions-on-time-2023-micro-car-collection-schedule-hero.jpg?_i=AA" data-object-fit="cover"/>

Content retrieved from post body:

<img class="wp-block-cover__image-background wp-image-526285" alt="" src="https://res.cloudinary.com/mecum/images/w_7186,h_3928,c_scale/v1700168153/media/mecum-auctions-on-time-2023-micro-car-collection-schedule-hero/mecum-auctions-on-time-2023-micro-car-collection-schedule-hero.jpg?_i=AA" data-object-fit="cover" />

It looks like, on page load, the system applies some transformations to the image, which are not applied on save, hence the mismatch in the markup

[Vdeub-cloudinary]

Hi @colis,

Thanks for letting me know.

Is it also happening for newly created posts?

Thanks!

[colis]

@Vdeub-cloudinary

it also happens for newly created patterns, yes

[Vdeub-cloudinary]

Thanks for letting me know @colis, I'll reach out to the team and let you know.

[Vdeub-cloudinary]

@colis, any chance you could share a system report with the post details as described here? Are you filtering the WordPress max size for the original?

[colis]

@Vdeub-cloudinary sure, here's the report from a local environment

cloudinary-report-1737551388.json

We're not using the big_image_size_threshold filter in our codebase. Actually the configuration in the backend is kept to a bare minimum, since it's a headless site and everything image-wise is handled on the frontend by a completely different application and codebase.

[Vdeub-cloudinary]

@colis, would you be available for a call with our development team to discuss this issue? If so, could you please share your availabilities? Thanks!

[colis]

@Vdeub-cloudinary sure!

Wed 5 Feb: 14:00-18:00 (CET) Thu 6 Feb: 16:00-18:00 (CET) Fri 7 Feb: 14:00-18:00 (CET) Mon 10 Feb: 14:00-18:00 (CET) Tue 11 Feb: 14:00-16:00 (CET)

Thanks!

[dero]

Hi @colis – in order to disable Cloudinary processing in Gutenberg context, which includes patterns, you might want to try this snippet:

namespace Cloudinary;

add_action(
	'init',
	function () {
		$cloudinary      = get_plugin_instance();
		$delivery_module = $cloudinary->components['delivery'];
		$uri             = isset( $_SERVER['REQUEST_URI'] ) && is_string( $_SERVER['REQUEST_URI'] )
			? esc_url_raw( $_SERVER['REQUEST_URI'] )
			: '';

		// We can't rely on `wp_is_serving_rest_request()`, because it's not available
		// early enough in the request lifecycle.
		$is_rest_blocks_request = strpos( $uri, '/wp/v2/block' ) !== false;

		if ( $delivery_module && $is_rest_blocks_request ) {
			remove_action( 'cloudinary_string_replace', array( $delivery_module, 'catch_urls' ), 10 );
		}
	},
	150
);

Depending on how you consume data from the headless WP, this may only bypass the unwanted processing in the WP admin, while not affecting the data you get through regular WP REST API endpoints.

In case you need to access the wp/v2/blocks endpoint on the front end of the site, this likely won't work without additional tweaks. Please let us know if and how this works for you.

Thank you!

[Vdeub-cloudinary]

@colis did you have a chance to look at @dero's code above regarding disabling Cloudinary delivery mechanism in your headless environment? Thanks!

[Vdeub-cloudinary]

Hi @colis just checking if you managed to try the solution provided. Thanks!

[colis]

Hi @Vdeub-cloudinary, sorry I was out of office the last couple of weeks. I'll test @dero's approach and report back asap, thanks!

[colis]

Hey @Vdeub-cloudinary, I've tested the snippet above and whilst it solves the validation issue, it also stops the asset delivery altogether instead of the transformations only, as images are now displayed with their WordPress URL (i.e. wp-content/uploads/...) rather than the Cloudinary one, which we'd still like to keep.

However, the changes in this PR https://github.com/cloudinary/cloudinary_wordpress/pull/1014 seem to achieve what we're looking for.

[Vdeub-cloudinary]

Hey @colis, Hope you are well. Just wondering if you still encounter this issue after https://github.com/cloudinary/cloudinary_wordpress/pull/1014? Thanks!

[colis]

hey @Vdeub-cloudinary - we haven't yet released the new version to the production environment, but I'll keep you posted. Thank you!

[Vdeub-cloudinary]

Hi @colis, Hope you are well. Just checking if you managed to release the new version? Thanks!

[colis]

Hi @Vdeub-cloudinary, we released the new version a couple months ago and didn't get any bug reports from the client, so I think #1014 fixed it, thanks!

[Vdeub-cloudinary]

Hi @colis that's awesome to hear! Glad everything is now working as expected.