Introduce editor block related functions

[desrosj]

The editor's block related functions are located in /lib/blocks.php of Gutenberg. These should exist in WordPress Core instead.

[pento]

In 43742:

Blocks: Introduce WP_Block_Type and WP_Block_Type_Registry classes.

These are the foundational classes allowing blocks to be registered and used throughout WordPress.

This commit also includes the has_block() and has_blocks() functions, which are required for unit testing these classes.

Props adamsilverstein, danielbachhuber, desrosj.
See #45097, #45109.

[pento]

In 43743:

Blocks: Introduce register_block_type(), unregister_block_type(), and get_dynamic_blocks() functions.

These helper functions allow easy access to the global block registry.

See #45109.

[pento]

In 43751:

Blocks: Introduce the block parser.

The WP_Block_Parser class, and the accompanying parse_blocks() helper function, can be used to parse an array of blocks out of a content string.

WP_Block_Parser is copied from the @wordpress/block-serialization-default-parser package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.

See #45109.

[pento]

In 43752:

Blocks: Parse blocks when displaying posts.

Posts containing blocks are now correctly handled when displaying on the front end, including dynamic blocks and nested blocks.

See #45109.

[pento]

There are still some issues (eg, ​GB#10463) to be tackled, but that can be done in a seperate ticket. This one is done for now.

[dimadin]

Replying to pento:

WP_Block_Parser is copied from the @wordpress/block-serialization-default-parser package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.

What about @since tags? Do all three classes must be in the same file?

Also, in [43752] you probably included /blocks directory by mistake.

[pento]

Replying to dimadin:

What about @since tags? Do all three classes must be in the same file?

Because WP_Block_Parser comes from an external package, any @since tags are related to the package version, not the WordPress version. This is similar to other external packages, such as SimplePie​, for example.

Also, in [43752] you probably included /blocks directory by mistake.

/src/wp-includes/blocks? That's intentional, it contains the PHP needed to for the dynamic blocks that are included in Core. It's similar to the /src/wp-includes/widgets directory.

[swissspidy]

Fix package name and text domains

[swissspidy]

@pento Please note that you forgot to remove the gutenberg text domain for all the strings in wp-includes/blocks. I fixed those and the package names in 45109.diff​.

Also, not really happy with the gutenberg_ function prefixes there. Especially since a function like gutenberg_draft_or_post_title() can be used in lots of other places like Walker_PageDropdown::start_el(), wp_prepare_attachment_for_js(), WP_Widget_Recent_Posts::widget() or wp_ajax_find_posts(), perhaps even more.

[pento]

These are copied from @wordpress/block-library so need to be fixed in the Gutenberg repo.

I've ​opened an issue for removing the text domain.

I agree that there's still work to be done to clean up the naming here, we can reshuffle things a bit.

[youknowriad]

@pento Did you consider loading the block-library php files directly from the npm packages instead of copying them over?

My concern with copying is that these are highly tied to their JavaScript part, so they should probably live together.

[pento]

@youknowriad: The files are copied from the npm package as part of the grunt webpack:dev script, they're intended to be maintained in the package, and copied into core when the package is upgraded.

[youknowriad]

@gary Oh great, I missed that part.

[ocean90]

#45180 was marked as a duplicate.

[swissspidy]

Why do gutenberg_render_block_core_latest_comments and gutenberg_draft_or_post_title still have the gutenberg_ prefix where other functions like render_block_core_latest_posts don't? That looks quite arbitrary.

[pento]

Thank you for the reminder, @swissspidy. I've added ​an issue in the Gutenberg repo to track that, too.

[pento]

In 44108:

Blocks: Introduce WP_Block_Type and WP_Block_Type_Registry classes.

These are the foundational classes allowing blocks to be registered and used throughout WordPress.

This commit also includes the has_block() and has_blocks() functions, which are required for unit testing these classes.

Merges [43742] from the 5.0 branch to trunk.

Props adamsilverstein, danielbachhuber, desrosj.
Fixes #45097.
See #45109.

[pento]

In 44109:

Blocks: Introduce register_block_type(), unregister_block_type(), and get_dynamic_blocks() functions.

These helper functions allow easy access to the global block registry.

Merges [43743] from the 5.0 branch to trunk.

See #45109.

[desrosj]

In 44116:

Blocks: Introduce the block parser.

The WP_Block_Parser class, and the accompanying parse_blocks() helper function, can be used to parse an array of blocks out of a content string.

WP_Block_Parser is copied from the @wordpress/block-serialization-default-parser package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.

Props pento.

Merges [43751] to trunk.

See #45109.

[desrosj]

In 44118:

Blocks: Parse blocks when displaying posts.

Posts containing blocks are now correctly handled when displaying on the front end, including dynamic blocks and nested blocks.

Props pento.

Merges [43752] to trunk.

See #45109.