Add FSE infrastructure from Gutenberg plugin into Core

[noisysocks]

• Make it so that a block theme can be activated and render correctly on the frontend.
• Add site editing REST API endpoints.
• Add necessary PHP helpers (WP_Block_Template, etc.)

​https://github.com/WordPress/gutenberg/tree/trunk/lib/full-site-editing

Work in progress. Attempts to add the required infrastructure to render block-based themes to Core.

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

I've merged template-part utils and template utils because the template-utils already worked for both. We just missed some functions.

Add minified CSS to Template Part block.

What is this item about @ockham I think there's no stylesheet for this block if I'm not wrong?

Ok, I think this one is actually ready, the only issue is the manual modifications to the template part blocks which is breaking some tests (unit, e2e tests, npm).

Ok, I think this one is actually ready, the only issue is the manual modifications to the template part blocks which is breaking some tests (unit, e2e tests, npm).

It's a bit of a chicken and egg problem because ​https://github.com/WordPress/wordpress-develop/pull/1804 which updates the blocks properly depends on this PR 🙂

I guess we will need to just skip the tests or commit this with failing tests and then immediately follow up with commits for https://core.trac.wordpress.org/ticket/54336 and https://core.trac.wordpress.org/ticket/54337.

@noisysocks yeah, I'm also fine if we include this patch in the packages update one, whatever works for you.

My comments/suggestions in the tests are not blockers as I can be update them after the merge.

My comments/suggestions in the tests are not blockers as I can be update them after the merge.

Whoopsie didn't mean to close this. Reopening.

In the tests, there are improvements that can be made which are not blockers to merge this PR:

• With PHP getting more and more strict, an effort is ongoing to replace all assertEquals with assertSame.
• With multiple assertions in a single test, if one fails, the other assertions do not run and it can be difficult to know which assertion failed. An effort is ongoing to add custom messages to each of these assertions to help with debugging.

I deleted all of the code suggestions for the tests (too much noise). I'll check after merge for any improvements, which BTW can happen after feature freeze.

​https://github.com/WordPress/wordpress-develop/pull/1796 and ​https://github.com/WordPress/wordpress-develop/pull/1804 depend on each other for tests to pass, so this PR merges both of those PRs into a single big branch. Hopefully that means we can fix tests and commit.

Trac ticket:
https://core.trac.wordpress.org/ticket/54335
https://core.trac.wordpress.org/ticket/54337

I've changed the base of this PR to trunk. This is now the default branch going forward. See the ​original proposal that is finally being put in place.

After rebasing, TT1 Blocks fatals on the frontend since get_query_pagination_arrow is missing. That function is indeed absent from Core; whereas in GB, it’s defined in the ​WP 5.8 compat layer. I’m a bit confused; I thought that means that it’s been present in Core since 5.8?

FWIW, get_query_pagination_arrow was added to GB by this PR: ​https://github.com/WordPress/gutenberg/pull/33656

After rebasing, TT1 Blocks fatals on the frontend since get_query_pagination_arrow is missing. That function is indeed absent from Core; whereas in GB, it’s defined in the WP 5.8 compat layer. I’m a bit confused; I thought that means that it’s been present in Core since 5.8?

That's my bad, sorry 😞 . I will have a PR for adding this in 5.9 for GB. It needs to be added in core as well.

Added get_query_pagination_arrow in blocks.php.

No worries! Thanks a lot for the fix, Nik!

Thanks to everyone who has worked on this, by adding and improving code, or reviewing!

I think we've addressed all feedback, so I'm setting this PR to ready for review. All that's left is some final approval now 😄

Ah, rebasing on trunk (which now includes ​https://github.com/WordPress/wordpress-develop/pull/1808) introduced a conflict (duplicated get_custom_templates()). I'll fix...

Ah, rebasing on trunk (which now includes ​https://github.com/WordPress/wordpress-develop/pull/1808) introduced a conflict (duplicated get_custom_templates()). I'll fix...

Thanks @bernie! I'll rebase and commit this.

Going to ignore the lint failures as they are failing on trunk too.

​https://wordpress.slack.com/archives/C02RQBWTW/p1636411775055600

[noisysocks]

In 52062:

Editor: Add block theme infrastructure

Adds the required infrastructure to render block-based themes. This is sourced
from the Gutenberg plugin.

Fixes #54335.
Props bernhard-reiter, youknowriad, ntsekouras, hellofromtonya.

[desrosj]

In 52110:

Docs: Avoid using “CPT” instead of “custom post type”.

Additionally, when referring to built in Core post types, “custom” is unnecessary.

This also adds a period to the end of the wp_global_styles post type description.

Follow up to [38829], [51003], [52041], [52049], [52062].

See #53399, #54335, #54336.

[SergeyBiryukov]

In 52266:

Tests: Replace assertEquals() with assertSame() in block template tests.

This ensures that not only the return values match the expected results, but also that their type is the same.

Going forward, stricter type checking by using assertSame(), assertSameSets(), or assertSameSetsWithIndex() should generally be preferred, to make the tests more reliable.

Follow-up to [51003], [51079], [52062], [52265].

See #53364, #53363, #54335.

This backports a change that was missed during the initial backports related to the templates list shown in the post editor.
It's a change from the following Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/35802

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

Testing instructions

Make sure the post editor only shows custom page templates in the template list and not hierarchy templates (index, single...)

cc @Mamaduka

This backports a change that was missed during the initial backports related to the templates list shown in the post editor.
It's a change from the following Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/35802

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

Testing instructions

Make sure the post editor only shows custom page templates in the template list and not hierarchy templates (index, single...)

cc @Mamaduka

This backports a Gutenberg change that was missed during the last backport session.
It's a change from the following Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/36000

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

cc @jameskoster

[youknowriad]

In 52331:

Site Editor: Update the block template descriptions.

Align the template descriptions with the latest changes from the Gutenberg plugin.

Props jameskoster, SergeyBiryukov.
See #54335.

committed in https://core.trac.wordpress.org/changeset/52331

[youknowriad]

In 52334:

Block Editor: Only list custom block templates in the template selector.

Previously all block templates including the hierarchy templates were being shown in the CPT template selector.

Props mamaduka.
See #54335.

Committed in https://core.trac.wordpress.org/changeset/52334

Committed in https://core.trac.wordpress.org/changeset/52334

Thank you!

Follow-up for #2020.

This method calls get_block_templates once and uses block template properties directly for filtering. This way, we can avoid hitting the database for each public post type.

The previous method is useful when we already know the current post type we request templates for, like when using REST API.

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

---
Cc @youknowriad @noisysocks @hellofromtonya

Block themes without theme.json file didn't have block templates support enabled in Core by default while they did with the Gutenberg plugin, this fixes that.

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

[youknowriad]

In 52347:

Themes: Auto-enable block-templates support for all block themes.

Block themes without theme.json file used to have block-templates support disabled.
This commit brings this in sync with the behavior in the gutenberg plugin.

See #54335.

Committed in https://core.trac.wordpress.org/changeset/52347

[noisysocks]

In 52365:

Filter custom block templates with PHP

This method calls get_block_templates once and uses block template properties
directly for filtering. This way, we can avoid hitting the database for each
public post type.

The previous method is useful when we already know the current post type we
request templates for, like when using REST API.

Follows [52334].
See #54335.
Props mamaduka, youknowriad.

https://core.trac.wordpress.org/changeset/52365

[gziolo]

In 56983:

Tests: Improve code coverage for _build_block_template_result_from_file

Props costdev, bernhard-reiter.
See #54335, #59325.
Follow-up for [56562].