[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:
-------------------------+------------------------------

Comment (by 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.

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