Tools: Automate backporting core blocks from Gutenberg to Core

[gziolo]

Follow up for #55642.

Syncing stable blocks from the Gutenberg repository to wordpress-develop is currently a manual process, but it can be automated.

The proposed workflow:

1. Read all the block.json files from the @wordpress/block-library directory.
2. Pick the ones without __experimental restrictions – these are the stable blocks.
3. Use that list to generate PHP code that requires appropriate dynamic blocks PHP files.
4. Use that list to generate PHP code that calls remove_action with appropriate arguments in PHP unit tests.
5. Use that list yet again in webpack config, instead of the hardcoded one.

To make the process smooth, require and remove_action calls can be extracted to separate PHP files that can be easily autogenerated and overwritten:

• wp-includes/blocks/require-dynamic-blocks.php
• wp-includes/blocks/require-static-blocks.php
• tests/phpunit/includes/unregister-blocks-hooks.php

Replaces ​https://github.com/WordPress/wordpress-develop/pull/2647.

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

## What problem does this PR solve?

Syncing stable blocks from the Gutenberg repository to wordpress-develop is currently a manual process.

The thing is, it can be automated.

That's what this PR does.

## How does this PR solve it?

The big idea is to:

1. Read all the block.json files from the @wordpress/block-library directory.
2. Pick the ones without __experimental restrictions – these are the stable blocks.
3. Use that list to generate PHP code that requires appropriate dynamic blocks PHP files.
4. Use that list to generate PHP code that calls remove_action with appropriate arguments in PHP unit tests.
5. Use that list yet again in Webpack config, instead of the hardcoded one.

All of this is possible thanks to ​https://github.com/WordPress/gutenberg/pull/40655

To make the process smooth, require and remove_action calls were extracted to separate PPH files that can be easily autogenerated and overwritten:

• wp-includes/blocks/require-dynamic-blocks.php
• wp-includes/blocks/require-static-blocks.php
• tests/phpunit/includes/unregister-blocks-hooks.php

## How to test?

1. Wait for the Gutenberg 13.2 release on May 11th where ​https://github.com/WordPress/gutenberg/pull/40655 will be included
2. Confirm all the checks are green on this PR
3. Checkout this branch
4. Run npx grunt sync-gutenberg-packages
5. Confirm all the stable blocks are now represented in the PHP files listed above
6. Confirm all the stable blocks were included in the build.
7. Confirm experimental blocks like post-author-name were excluded from both lists

cc @adamziel

[gziolo]

In 53688:

Tools: Automate backporting core blocks from Gutenberg to Core

Syncing stable blocks from the Gutenberg repository to wordpress-develop was a manual process, but it got automated with the script that runs together with syncing WordPress packages changed in the Gutenberg package.

Props zieladam.
Fixes #56179.

[gziolo]

We still need to improve the integration with the webpack config that depends on bringing the changes applied in ​https://github.com/WordPress/gutenberg/pull/40655 to WordPress core. In effect, we need to update all core blocks to their latest version before we can land these changes.

I landed most of the changes with https://core.trac.wordpress.org/changeset/53688. The last remaining piece is the changes to the weback config that requires updating core blocks first.

[azaozz]

May be missing something but... Looking at [53688], think it was decided it's a good idea to not commit auto-generated files to trunk. They are replaced every time when building, there is no point of them being in the repo.

In addition having these dynamically generated, always overwritten files committed may bring problems when building to /build, the same thing that happened with script-loader-packages.php before.

Any particular reason the auto-generated PHP files are committed to trunk? Think it was decided to not do that again after the problems with script-loader-packages.php.

Also, these files are supposed to be overwritten every time WP is build, right? So why commit the potentially old versions of them :)

[gziolo]

Also, these files are supposed to be overwritten every time WP is build, right? So why commit the potentially old versions of them :)

Thank you for raising the issue. It's a different use case though because the script that updates 3 newly extracted files is totally optional. We might want to reword the code comment that gets included in the file after it gets recreated when core blocks change in a specific way in the Gutenberg plugin - new block added, a block promoted from an experiment to a stable version, block transitioned from static to dynamic or the other way around:

https://core.trac.wordpress.org/browser/trunk/tools/release/sync-stable-blocks.js?rev=53688#L22

This file was autogenerated by tools/release/sync-stable-blocks.js, do not change manually!

To further clarify, tools/release/sync-stable-blocks.js doesn't run on every build. It gets only triggered when calling npm run sync-gutenberg-packages that you run only when bringing new changes from the Gutenberg plugin to WordPress core. I expect those files to change at most a few times for a given major WordPress release.

[gziolo]

In 54308:

Tools: Simplify syncing core blocks from Gutenberg plugin to Core

Follow-up [53688].

Removes the hardcoded list of blocks that should be synced from the Gutenberg plugin. webpack reads all information from the @wordpress/block-library by scanning block.json files.

Props zieladam, azaozz.
Fixes #56179.

With https://core.trac.wordpress.org/changeset/54308 all changes are now included in WordPress core.

[desrosj]

In 54406:

Build/Test Tools: Use require_once instead of require.

The sync-stable-blocks.js file is used to compile the contents of require-dynamic-blocks.php, which includes the PHP files required for dynamic Core blocks.

Since these files define PHP functions, require_once should be used instead of require to guard against fatal errors.

Follow up to [53688].

Props aristath, SergeyBiryukov, desrosj.
Fixes #56738. See #56179.