Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core/Image block validation errors in Block Patterns UI #996

Open
colis opened this issue Oct 29, 2024 · 10 comments
Open

Core/Image block validation errors in Block Patterns UI #996

colis opened this issue Oct 29, 2024 · 10 comments
Assignees

Comments

@colis
Copy link

colis commented Oct 29, 2024

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

Screenshot 2024-10-29 at 10 49 47

Screenshot 2024-10-29 at 10 50 03

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
Copy link

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

@Vdeub-cloudinary Vdeub-cloudinary self-assigned this Oct 30, 2024
@colis
Copy link
Author

colis commented Oct 30, 2024

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)

Screenshot 2024-10-30 at 16 02 13

@jessica-townsend
Copy link

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

Screenshot 2025-01-02 at 10 01 56 AM

@Vdeub-cloudinary
Copy link

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
Copy link
Author

colis commented Jan 15, 2025

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
Copy link

Hi @colis,

Thanks for letting me know.

Is it also happening for newly created posts?

Thanks!

@colis
Copy link
Author

colis commented Jan 15, 2025

@Vdeub-cloudinary

it also happens for newly created patterns, yes

@Vdeub-cloudinary
Copy link

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

@Vdeub-cloudinary
Copy link

@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
Copy link
Author

colis commented Jan 22, 2025

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants