Blocks: Move block parser PHP classes from Gutenberg to Core

[youknowriad]

The block parser classes (WP_Block_Parser, WP_Block_Parser_Block, WP_Block_Parser_Frame) are currently maintained in the Gutenberg repository and copied to Core during the build process. This creates an inconsistency with other block-related infrastructure that is maintained directly in Core. These classes should be moved to Core and maintained there.

Background

See #64393

Currently, the block parser files live in Gutenberg at packages/block-serialization-default-parser/ and are copied to wp-includes/ during the build. These files are gitignored in Core:

/src/wp-includes/class-wp-block-parser.php
/src/wp-includes/class-wp-block-parser-block.php
/src/wp-includes/class-wp-block-parser-frame.php

Arguments for Moving to Core

• Inconsistency with related Core infrastructure: WordPress Core already maintains several related block processing classes natively: WP_Block_Processor, Block type management (WP_Block, WP_Block_Type, WP_Block_Type_Registry)

Block bindings, patterns, templates, and supports infrastructure.

• Stable code: The block parser has been stable since WordPress 5.0. Looking at the git history, the PHP files have had virtually no changes in years.
• Simplifies the build process: Removing the parser from the Gutenberg copy step would simplify the build integration and reduce dependencies on Gutenberg for core functionality.

This ticket requires changes on both WordPress Core and Gutenberg.

Potential arguments for keeping them in Gutenberg

If in the future we'd want to update the parser to introduce new features, it would become a bit harder (possible) if these files are in Core. I'd say that this is not a very strong as the issue exists for all the other block related code and there are ways around it.

So the pros outweigh the cons.

[mukesh27]

I raise this that file was missing in trunk see ​https://github.com/WordPress/wordpress-develop/pull/10735#issuecomment-3755335847

[dmsnell]

If in the future we'd want to update the parser to introduce new features, it would become a bit harder (possible) if these files are in Core. I'd say that this is not a very strong as the issue exists for all the other block related code and there are ways around it.

Given our experience with developing a number of different APIs in Core, it has not been burdensome to bring features back over into Gutenberg. I don’t see this as being a problem because we can resort to the vetted method of prefixing gutenberg_parse_blocks() or Gutenberg_Block_Parser if we want to change the interface or add functionality. Occasionally this causes additional work, but it has been predictably maintainable.

I have attempted to ascertain where and how Gutenberg imports the parser code and I believe that it doesn’t currently do so, which I think also implies that this question is moot. Any updates we would currently want to make would require similar work if the parser were truly in Core:

• There is no require or include statement pulling in the parser files.
• The parser modules contain no if ( ! class_exists() ) checks.
• WordPress 6.9 runs fine with Gutenberg trunk.
• WordPress trunk runs fine with Gutenberg trunk.

I believe that this means that the source of truth for the parser being Gutenberg is purely organizational, and in fact, that has historically been true due to its colocation with the JavaScript parser. At this point in history the block model is sufficiently set in stone to the point that any meaningful change would have ample testing/any change not committed on both sides would likely immediately break, revealing the defects.

Therefore I think it’s safe that we take a simple approach here:

• Delete the PHP parser code from the Gutenberg repo.
• Undo its removal from Core.
• Remove copying the parser from the new build step.

The only trouble I see here is a temporal breakage due to the change in how Core builds Gutenberg, because until the files are committed in Core and the copy step is removed from the build instructions, Core could be left without any parser. Thankfully, if Core gets the change first then the the copy in Gutenberg should be benign except for those who are checking out specific revisions in the overlap.

Trac ticket: Core-64521

The work in #10638 [61438] for Core-64393 removed the block parser classes from Core, which caused numerous scripts to fail because they were missing. Conditional checks were added in #10718 [61492] which left WordPress in an inoperable state.

This patch restores the block parser in Core, in preparation for work to remove it from Gutenberg (in a separate patch f.

Ironically, the files were removed because the new build was copying them over from Gutenberg and the intent was to avoid having two sources of truth, but this was previously the existing mechanism, so having done nothing to the parser files would have left the status quo. This patch removes the problems originally created by removing the files. They will not be copied from Gutenberg any more and the only source of truth will be Core.

Until removed from Gutenberg, because of the build changes, any changes made on the Gutenberg side will be lost unless manually copied over.

Developed in:
Discussed in: https://core.trac.wordpress.org/ticket/64521

Follow-up to [61438], [61492].
Props dmsnell, mcsf, mukesh27, youknowriad.

[dmsnell]

Before the change in #64393, these files were already being copied. That change didn’t have to address the block parser in any way but it removed the files from Core’s version control. To that end it could have continued the behavior which was working.

This patch is now eliminating the connection between Gutenberg and Core with respect to the default block parser PHP classes. An associated PR will need to remove the files permanently from Gutenberg, but it is safer to reintroduce these files in Core for a period of time before removing them from Gutenberg, otherwise more build breakages are guaranteed.

This looks good to me :)

[dmsnell]

In 61504:

Build: Restore block parser in Core.

The work in [61438] for Core-64393 removed the block parser classes from Core, which caused numerous scripts to fail because they were missing. Conditional checks were added in [61492] which left WordPress in an inoperable state.

This patch restores the block parser in Core, in preparation for work to remove it from Gutenberg (in a separate patch).

Ironically, the files were removed because the new build was copying them over from Gutenberg and the intent was to avoid having two sources of truth, but this was previously the existing mechanism, so having done nothing to the parser files would have left the status quo. This patch removes the problems originally created by removing the files. They will not be copied from Gutenberg any more and the only source of truth will be Core.

Until removed from Gutenberg, because of the build changes, any changes made on the Gutenberg side will be lost unless manually copied over.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/10761
Discussed in: https://core.trac.wordpress.org/ticket/64521

Follow-up to [61438], [61492].

Props dmsnell, mcsf, mukesh27, youknowriad.
Fixes #64521.

[dmsnell]

Reopening for the Gutenberg patch. I believe that it’s prudent to wait some time, even a couple weeks, to allow for a transition to occur which won’t leave people without a functioning WordPress.

That is, if someone has the broken trunk installed but updated Gutenberg to a new release without the block parser code, I fear that this could lead to another break because Core won’t find the parser code to copy.

I would even be in favor of waiting a release cycle to remove the Gutenberg code, simply adding a note at the top of the file about it being deprecated and an historic relic.

Thoughts?