Flood of console.info() notices

[desrosj]

Description

In WordPress 5.8-beta1 through RC1, the browser console is displaying many notices when editing a post. The errors are a variation of:

Block successfully updated for `core/button` ( 
Object { name: "core/button", icon: {…}, keywords: (1) […], attributes: {…}, providesContext: {}, usesContext: [], supports: {…}, styles: (2) […], save: save(), apiVersion: 2, … }
 ).

New content generated by `save` function:

<div class="wp-block-button is-style-outline"><a class="wp-block-button__link has-text-color has-background no-border-radius" style="background-color:#000000;color:#ffffff">Visitar</a></div>

Content retrieved from post body:

<div class="wp-block-button is-style-outline"><a class="wp-block-button__link has-text-color has-background no-border-radius" style="background-color:#000000;color:#ffffff">Visitar</a></div> blocks.min.js:2:51968

Is this an intentional decision to include these notices now? If so, could the notices be updated to be conscious of when WP_DEBUG and only output this information when set to true? I can open up a companion ticket on Trac if appropriate.

This behavior did not occur in WordPress 5.7.2.

Originally reported in the Alpha/Beta/RC forums.

Step-by-step reproduction instructions

1. Install 5.8 RC1.
2. Open the console.
3. Edit the Sample Page post created with all new installs.
4. Observe the notices.

Expected behaviour

Minimal notices are displayed in the console.

Actual behaviour

A lot of notices are displayed in the console.

WordPress information

• WordPress version: 5.8 RC1
• Gutenberg version: NA
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

• Device: Mac
• Operating system: MacOS 10.15.x
• Browser: Firefox

[ntsekouras]

I've opened a PR in core for updating the patterns: WordPress/wordpress-develop#1483

[bvlgn]

The console.info messages are also there as soon as you add a new page (without adding content or interacting).
So, I guess they might be caused during parsing/rendering of the previews of the block patterns for the inserter?

This is very confusing for users (that happen to have the developer console open). For developers it is also irritating, because they have to find their own console messages between all of the core info messages.

[ntsekouras]

So, I guess they might be caused during parsing/rendering of the previews of the block patterns for the inserter?

They are parsed, although not for the inserter preview. See: #33153 (comment)

[gziolo]

Resharing my #33153 (comment) comment for visibility:

Thinking a bit more about it, it’s inevitable that with block patterns we will see more and more of those logs. Maybe, we should be less concerned about successful migrations.

I see a ton of console.info logs when developing Gutenberg. It's inevitable to see the growing number of (successful) validation logs with the growing number of block patterns in the directory. I doubt that those patterns are going to be updated often after they get submitted. Well, I think it's great that they work fine even when core blocks update the output format.

What worries me here, that those logs come from the preview in the block inserter the block patterns parsing that isn't related to the content used on the site. I don't think we should be really reporting those issues on production as they bring only confusion. What matters here is if they get correctly inserted into the content/template.

[ntsekouras]

There were some interesting issues surfaced in my attempt to update the patterns in core which are summarized here: WordPress/wordpress-develop#1483 (comment).

In a few words we have patterns in themes and in pattern directory.

As @ocean90 explained:

Themes, which also includes the default themes, are updated via the Theme Directory (Twenty Twenty-One) just like plugins. So while their code lives in the same repo as WordPress core their releases are independent from WordPress core.

So in themes the patterns are checked and have been created against a specific WP version - this still produces migration logs but no errors. We could handle this by adding an extra version check for patterns in themes and register conditionally, but I'm not sure it worths it to add such extra complexity there..

In pattern directory though, a user could submit a pattern with 5.8 blocks for example and try to paste them in 5.3, where there could be a possibility for errors. My suggestion is that pattern directory should at least add a new field for minimum WP version when registering and displaying patterns.

Regarding the logs now, another option maybe would be to implement some kind of source(pattern, content, etc..) attribute in parseBlocks and log conditionally? 🤔

[gziolo]

Regarding the logs now, another option maybe would be to implement some kind of source(pattern, content, etc..) attribute in parseBlocks and log conditionally? 🤔

@mtias, since you proposed an RFC for the classification of block validation types (#21703), I would be curious to hear how it fits in the picture. We didn't have this issue before.

I know that @youknowriad added some changes to the block parser that skips some logging when the validation issues are visible in the UI.