Introduce WP_Block_Type and WP_Block_Type_Registry classes

[danielbachhuber]

The WP_Block_Type and WP_Block_Type_Registry classes currently exist in Gutenberg. They should be in WordPress core instead.

[adamsilverstein]

In 45097.diff​:

• Include WP_Block_Type and WP_Block_Type_Registry and related tests.
• tested with gutenberg master
• ​Build Status

[danielbachhuber]

In 45097.2.diff, further ​adaptation of the patch:

• Updates @since to 5.0.0.
• Updates @package to WordPress and @subpackage to Blocks.
• Removes 'gutenberg' textdomain.
• Renames unit test files according to existing standards.

@adamsilverstein I'm not sure why the tests are passing in Travis for you. Locally, I get:

1) WP_Test_Block_Type_Registry::test_register_block_type_instance
Error: Class 'WP_Dummy_Block_Type' not found

/Users/danielbachhuber/projects/wordpress-develop/tests/phpunit/tests/blocks/block-type-registry.php:111

2) WP_Test_Block_Type::test_has_block_with_mixed_content
Error: Call to undefined function has_block()

/Users/danielbachhuber/projects/wordpress-develop/tests/phpunit/tests/blocks/block-type.php:195

3) WP_Test_Block_Type::test_has_block_with_invalid_content
Error: Call to undefined function has_block()

/Users/danielbachhuber/projects/wordpress-develop/tests/phpunit/tests/blocks/block-type.php:224

4) WP_Test_Block_Type::test_post_has_block
Error: Call to undefined function has_block()

/Users/danielbachhuber/projects/wordpress-develop/tests/phpunit/tests/blocks/block-type.php:237

It seems like we'll need to wait for has_block to land (#45037 I think) before we can continue with this.

[adamsilverstein]

@adamsilverstein I'm not sure why the tests are passing in Travis for you. Locally, I get:

I'll try locally as well, did you start from the 5.0 branch when applying the patch?

[desrosj]

Handfull of minor changes in 45097.3.diff​:

• Added a handful of missing @since tags.
• @access and @static tags have been removed. Per the ​PHP Documentation Standards, these are no longer used, or not necessary.
• Moved the class-wp-dummy-block-type.php into the tests/phpunit/includes folder from Gutenberg. This fixes the first failure @danielbachhuber was seeing. Also, renamed this class to WP_Fake_Block_Type to be more pleasant.
• Removes setup() method from WP_Test_Block_Type (it was not performing any actions).
• Adds missing visibility for methods in test classes.
• Add missing @since and @ticket tags for test methods.

I ​also set up a build on my fork. I am seeing the same issues as @danielbachhuber.

I contemplated marking each test that requires has_block() skipped if the function does not exist. That would allow this to land and would turn the tests on later post-merge, but those skips should be removed after that. @danielbachhuber @adamsilverstein what are your thoughts on that?

[danielbachhuber]

@desrosj My preference would be to land the patch in a finalize state, and not need the intermediate step of skipping tests. We should track down the status of landing has_patch().

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