Layouts: Layouts generate console messages for block updates

[ianstewart]

Steps to reproduce

1. Create a new site on WP.com as a new user
2. Open up your console
3. Switch to an older "Recommended" WP.com theme
4. Click Edit homepage on the modal that pops up
5. Note the "Block successfully updated" message in the console

cc @marekhrabe @obenland @iamtakashi @alaczek

(This might be an issue that touches on themes, page layouts, the layout selector, and theme switching?)

[marekhrabe]

When all those layouts are initially loaded for the selector (doesn't matter if you create a blank page or are switching), they need to be parsed from the HTML string with block comments into proper block objects that the block editor understands

Since most of those templates were written a long time ago, the block syntax has changed slightly from the one that Gutenberg generates today (for example alignment used to be an inline style style="text-align: left" and it got changed into a class like has-text-align-left. All these changes get automatically resolved but they leave the message in console.

In order to get rid of these messages, we would need to regenerate the source code of all our templates (by opening it in new version of the editor and saving it). This would also need to be done to all language mutations of such templates.

[m]

How quickly can we do that? Especially since it's something code we've written (Gutenberg) is able to do automatically.

[obenland]

For templates in English fairly quickly because we keep the originals in Gutenberg. For the 16 translations we'll have to manually replace it in their json files, so quite a bit longer.

[obenland]

@ianstewart has updated the homepage templates in theme demo sites and the remaining templates on a8ctm1. He'll ship the updated homepage templates (en) today.

I created a script to update a8ctm1 templates in D41467-code (including the script's results) and will test & iterate on that today. We should be able to reuse that script for localized homepage templates as well.

[ianstewart]

@obenland EN homepage layouts have all been updated.

[obenland]

All non-homepage templates have been updated in r205519-wpcom. I'll adjust the script and continue working on translated homepage templates tomorrow

[obenland]

Translated homepage templates are being worked on in D41555-code

[obenland]

I decided to stop updating translated homepage templates after realizing that all the work we've put in so far will become pointless once Gutenberg 7.9 has shipped to dotcom.

It includes gems like:

New content generated by `save` function:

<p class="has-text-align-left" style="font-size:16px">A short bio with personal history, key achievements, or an interesting fact.</p>

Content retrieved from post body:

<p style="font-size:16px;" class="has-text-align-left">A short bio with personal history, key achievements, or an interesting fact.</p>

The only tenable solution to this would be to write a job that runs these templates through block transformations and updates annotations automatically. I'm not sure how high up in our priorities that should be, given Create's plans to replace the system (p58i-8On-p2). @davemart-in?

[davemart-in]

@mtias this seems like a really expensive thing for us to have to be doing manually each time there is an update to the markup of any block, especially since this has to be done for all language mutations for each layout. This process of manually making updates doesn't feel very sustainable. What happens when we have 100+ layouts?

Would it be possible to just add something like a printSyntaxChangesToConsole flag in Gutenberg that is set to true by default, but that can be manually set to false on our end to simply turn these audit message in the console off?

[mtias]

@davemart-in it seems imperative that we have a system for updating templates and their translations (I don't know why we don't decouple the translated strings from the template markup) that is not expensive to do. We should avoid suppressing migration logs like this because they indicate extra operational power that we should eliminate at the source. Otherwise we are contributing to degrading performance.

@obenland have you narrowed down the reason for the extra ; in that last example?

[davemart-in]

cc @johnHackworth who's team just took over templates again.

[obenland]

have you narrowed down the reason for the extra ; in that last example?

That's how the Editor saved them at the time they were created. 193098-wpcom

[mtias]

Yes, I mean why the difference.

[obenland]

I have not. Looking at the milestone, WordPress/gutenberg#21037 feels like a candidate but I couldn't point out what would cause it.

[mtias]

It would be a good one to include as heuristics for WordPress/gutenberg#21703 I gather it was just the comment attribute shape that was changing.

[github-actions]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[cuemarie]

This report was found during a recent backlog sweep.

Reviewing WordPress/gutenberg#21703 (comment), it looks like this will not be fixed at the core level.

I've elected not to include the pattern updates in the bundled theme release accompanying WordPress 5.8. This will leave console.info() notices, but it will prevent block validation problems in a number of theme and WP version combinations. See my comment on the ticket for full details.