[wp-trac] [WordPress Trac] #64521: Blocks: Move block parser PHP classes from Gutenberg to Core

[WordPress Trac]

#64521: Blocks: Move block parser PHP classes from Gutenberg to Core
-------------------------+------------------------------
 Reporter:  youknowriad  |       Owner:  dmsnell
     Type:  enhancement  |      Status:  assigned
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Editor       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------
Description changed by dmsnell:

Old description:

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

New description:

 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.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64521#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform