Editor: Introduce WP_Block class

[aduth]

Related: ​https://github.com/WordPress/gutenberg/pull/21467
Related: #48104
Related: ​https://github.com/WordPress/gutenberg/issues/4671

The Gutenberg project is currently exploring the introduction of a new ​block context feature. As part of this effort and in order to make this context available as part of the existing render_callback function signature of block settings, in ​Gutenberg#21467 a new WP_Block class was introduced to serve the purpose of providing a first-class interface for plugins to interact with an instance of a block from within their own render callbacks.

Like in the browser client, this is intended to be distinct from the block value which is produced directly from the parser, and which is otherwise made available through existing low-level filters ​`render_block_data` and ​`render_block`.

See related discussion:

• ​https://github.com/WordPress/gutenberg/pull/21467#issuecomment-613635022
• ​https://github.com/WordPress/gutenberg/pull/21467#issuecomment-613893963
• ​https://github.com/WordPress/gutenberg/pull/21467#issuecomment-614202405
• ​https://github.com/WordPress/gutenberg/pull/21467#issuecomment-614536274
• ​https://github.com/WordPress/gutenberg/pull/21467#issuecomment-614667355

Proposed tasks:

• Introduce new WP_Block class (see implementation from ​Gutenberg#21467 for initial reference)
• render_block constructs WP_Block and largely defers to the implementation of a WP_Block::render (see implementation from ​Gutenberg#21467 for initial reference)
• Consolidate WP_Block_Type::render and WP_Block::render (the former can likely pass-through to the latter)

Note: ​`render_block` and serialize_block currently receive $block in the parsed array form. While I ​remarked differently on the original pull request, I don't know that these actually need to change, since it seems rather sensible that these would except to receive blocks in their parsed forms. If one has access to a WP_Block instance and needs to create its rendered representation, the instance's render function can be used directly.

Feedback welcome: While the above can be considered a proposal of tasks, this is all very much subject to change.

[aduth]

Related: #49927

[aduth]

There have been a few iterations to block context in Gutenberg after the pull request referenced in the original comment.

Notably:

• The approach using ArrayAccess to emulate backward-compatibility was not fully-compatible and was rolled back
  • Issue: ​https://github.com/WordPress/gutenberg/issues/21797
  • Fixes:
    • ​https://github.com/WordPress/gutenberg/pull/21868
    • ​https://github.com/WordPress/gutenberg/pull/21921
• A second attempt was made, where instead of trying to reuse the first argument, a new third argument is added to render_callback
  • ​https://github.com/WordPress/gutenberg/pull/21925

It's quite likely there will be further iterations to WP_Block in Gutenberg.

The most up-to-date version should be found at:

​https://github.com/WordPress/gutenberg/blob/master/lib/class-wp-block.php

Up-to-date file history: ​https://github.com/WordPress/gutenberg/commits/master/lib/class-wp-block.php

Trac ticket: https://core.trac.wordpress.org/ticket/49926

This PR ports the most up-to-date version of the WP_Block class added to Gutenberg:

​https://github.com/WordPress/gutenberg/blob/master/lib/class-wp-block.php

It also adds a corresponding unit tests.

There is a follow-up backport necessary to wire this class when using new block context features as tracked in https://core.trac.wordpress.org/ticket/49927.

I think this needs @since comments on all the classes, methods, and properties not just for the file.

[gziolo]

In 48159:

Editor: Introduce WP_Block and WP_Block_List classes

Backports functionality added in Gutenberg in the following PRs:

• ​https://github.com/WordPress/gutenberg/pull/21467
• ​https://github.com/WordPress/gutenberg/pull/21925

It's a few ideas related to block rendering and the provided block value, which is particularly impactful for work around block context.

Props aduth, TimothyBJacobs, noisysocks, epiqueras, youknowriad, talldanwp, zebulan.
Fixes #49926.