Block patterns with 6.1 format markup throwing console errors in 6.0 sites

[WildeWebMarketing]

In a fresh 6.0.3 site without GB plugin installed, some patterns with 6.1 format markup, like this one, are being pulled into the editor in the background and causing block invalidation errors as the 6.0 version of the editor does not recognise the markup.

Clicking edit for a post was taking longer than usual to get to the editing screen. Opened up the inspect console and there are lots of validation errors, like:

Block validation: Block validation failed for core/button ({name: 'core/button', icon: {…}, keywords: Array(1), attributes: {…}, providesContext: {…}, …}).
Contentgenerated bysavefunction:
<div class="wp-block-button has-custom-width wp-block-button__width-100">Watch my latest videos</a></div>
Content retrieved from post body:
<div class="wp-block-button has-custom-width wp-block-button__width-100"><a class="wp-block-button__link wp-element-button">Watch my latest `videos

[glendaviesnz]

Thanks for reporting this @WildeWebMarketing. I think this is covered by this existing issue, so going to close this one for now.

[glendaviesnz]

Actually this one looks slightly different to the one I linked, so reopening until that is confirmed.

[glendaviesnz]

@WildeWebMarketing are you able to confirm which version of WP you are using when you see these errors, and whether you have the Gutenberg plugin installed and enabled and which version.

Also, have you enable the Gutenberg plugin at any point and then disabled it? or copied content from a site that may be running a newer version of WP/Gutenberg?

[WildeWebMarketing]

I'm using WordPress Version 6.0.3. I do not have the Gutenberg plugin installed and it was not installed at any point. No content from external sites.

I appreciate your attention to this @glendaviesnz

[WildeWebMarketing]

@glendaviesnz I have also checked multiple installations on different servers and the problem is present in those as well.

[glendaviesnz]

@WildeWebMarketing looks like an issue with block patterns. We will try and work out why these incompatible patterns are being pulled into 6.0.3 sites.

[andrewserong]

Update:

some patterns with 6.1 format markup, like this one

Since this is affecting WP 6.0.x where patterns are fetched remotely in core, as a short-term fix, this pattern has been unpublished so that it won't show up in the pattern inserter. It appears to be the only one of the "remotely fetched by default" patterns that was throwing errors in WP 6.0 as far as I could tell from my test site.

Longer-term, @noisysocks suggested that one way to solve it could be if patterns in the pattern directory had a Requires at least: metadata entry of some kind so that sites would only fetch remote patterns that are compatible with their version.

Thanks @tellyworth for the assistance, and just pinging @ryelle for visibility.

[WildeWebMarketing]

Awesome, thank you!

Errors are gone.

[ryelle]

Requires at least: metadata entry

I think this would get tricky because of the Gutenberg plugin + WP core combinations possible. Would it be possible for the inserter to somehow check for validation errors at the client side, and prevent rendering those?

[noisysocks]

Would it be possible for the inserter to somehow check for validation errors at the client side, and prevent rendering those?

Technically yes. To do this you'd recurse through the tree of blocks returned from blocks = parseBlocks( pattern ) and check that every block.isValid.

[andrewserong]

Would it be possible for the inserter to somehow check for validation errors at the client side, and prevent rendering those?

Oh, that's an interesting idea. I quite like that as a longer-term solution to ensuring that patterns don't break the UI. It'd be good for us to ensure that we're still logging something to the console for patterns that break in themes, so that theme developers can investigate and update patterns as needed (and know which ones are broken).

I suppose a challenge with this idea is that it would only really help us for WordPress 6.2 and beyond — for WordPress 6.0, any patterns for later versions will still throw an error in the UI. I think that's one of the reasons I quite liked the idea of a minimum version in the API of the pattern directory. If we had it that a default API response included patterns compatible with 6.0, then we could potentially introduce a param to be passed with the request in subsequent WP releases, that told the pattern directory to return patterns that support a newer WP release?

Given the timing of 6.1 and that the final RC is about to come out, whichever fix we go with appears to be pretty tricky to roll out 🤔

[ryelle]

It'd be good for us to ensure that we're still logging something to the console for patterns that break in themes, so that theme developers can investigate and update patterns as needed (and know which ones are broken).

There was a suggestion in this comment #43395 (comment) about a new debugging constant for theme developers, could help here too — when "THEME_DEBUG" is true, show the pattern console errors, otherwise silently discard them? Or something :)

I suppose a challenge with this idea is that it would only really help us for WordPress 6.2 and beyond — for WordPress 6.0, any patterns for later versions will still throw an error in the UI. I think that's one of the reasons I quite liked the idea of a minimum version in the API of the pattern directory.

I don't think that would really help older versions either though, because we haven't been tracking gutenberg versions for the existing patterns. 🤔 Maybe we could add some temporary post meta (via a sandbox) to any problem-patterns that are being loaded in WP (was it just this one?) and use the passed wp-version param in the API request to only send those back when version >= 6.1. That would work around the problem in the short term, and buy some time for the longer-term solution in 6.2+. And it would be a wporg-side fix, independent of the RC cycle.

[ntsekouras]

I think this would get tricky because of the Gutenberg plugin + WP core combinations possible. Would it be possible for the inserter to somehow check for validation errors at the client side, and prevent rendering those?

This is a long standing known issue and I also believe a minimum version field is needed. Do you find any problems by checking only against WP? That means that all the patterns in PD should have been created at most the current stable WP version and not with GB. What do you think?

[ryelle]

That means that all the patterns in PD should have been created at most the current stable WP version and not with GB. What do you think?

That's not the pattern directory environment, though. Since it's part of the w.org multisite, it runs WP trunk and the latest Gutenberg release. At launch, we needed GB because the Creator needed some unstable APIs to work. I'm not sure if that's still the case, so we could possibly disable GB on the Directory site, but it will still run WP trunk.

[ryelle]

In WordPress/pattern-directory#536 I added a check for the requesting site's WP version, and any pattern tagged with a higher version number will not be returned in the API response.

I've also re-published the Link in Bio pattern with a minimum version of 6.1, so if you're on 6.1+ you should now see that pattern in the "Featured" category in the editor (the API result is locally cached, so it might take an hour to show up). If you're still on 6.0, the pattern won't show up (even if you have Gutenberg installed).

Pattern versions are added manually, so I still see this as a short-term fix, with client-side validation as a more effective fix.

[ntsekouras]

I'm closing this issue as the reported pattern has been fixed and this is something that needs to be handled in Pattern Directory, which is quite convoluted as explained in this PD PR: WordPress/pattern-directory#536.