Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 7 months ago

#54335 closed task (blessed) (fixed)

Add FSE infrastructure from Gutenberg plugin into Core

Reported by: noisysocks's profile noisysocks Owned by: bernhard-reiter's profile bernhard-reiter
Milestone: 5.9 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch
Focuses: Cc:

Description

  • 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

Change History (43)

This ticket was mentioned in PR #1796 on WordPress/wordpress-develop by ockham.


3 years ago
#1

  • Keywords has-patch added

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

youknowriad commented on PR #1796:


3 years ago
#2

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

youknowriad commented on PR #1796:


3 years ago
#3

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?

youknowriad commented on PR #1796:


3 years ago
#4

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

noisysocks commented on PR #1796:


3 years ago
#5

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.

youknowriad commented on PR #1796:


3 years ago
#6

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

hellofromtonya commented on PR #1796:


3 years ago
#7

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

hellofromtonya commented on PR #1796:


3 years ago
#8

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

hellofromtonya commented on PR #1796:


3 years ago
#9

Whoopsie didn't mean to close this. Reopening.

hellofromtonya commented on PR #1796:


3 years ago
#10

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.

This ticket was mentioned in PR #1825 on WordPress/wordpress-develop by noisysocks.


3 years ago
#11

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

desrosj commented on PR #1825:


3 years ago
#12

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.

ockham commented on PR #1796:


3 years ago
#13

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?

ockham commented on PR #1796:


3 years ago
#14

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

ntsekouras commented on PR #1796:


3 years ago
#15

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.

ntsekouras commented on PR #1796:


3 years ago
#16

Added get_query_pagination_arrow in blocks.php.

ockham commented on PR #1796:


3 years ago
#17

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

ockham commented on PR #1796:


3 years ago
#18

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 😄

ockham commented on PR #1796:


3 years ago
#19

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

ockham commented on PR #1796:


3 years ago
#20

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

#21 @noisysocks
3 years ago

  • Owner set to bernhard-reiter
  • Status changed from new to assigned

noisysocks commented on PR #1796:


3 years ago
#22

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

noisysocks commented on PR #1796:


3 years ago
#23

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

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

#24 @noisysocks
3 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

This ticket was mentioned in Slack in #core-editor by noisysocks. View the logs.


3 years ago

#26 @desrosj
3 years ago

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.

#27 @SergeyBiryukov
2 years ago

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 ticket was mentioned in PR #2020 on WordPress/wordpress-develop by youknowriad.


2 years ago
#28

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 ticket was mentioned in PR #2020 on WordPress/wordpress-develop by youknowriad.


2 years ago
#29

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 ticket was mentioned in PR #2021 on WordPress/wordpress-develop by youknowriad.


2 years ago
#30

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

#31 @youknowriad
2 years ago

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.

#33 @youknowriad
2 years ago

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.

noisysocks commented on PR #2021:


2 years ago
#36

Thank you!

This ticket was mentioned in PR #2031 on WordPress/wordpress-develop by Mamaduka.


2 years ago
#37

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

This ticket was mentioned in PR #2035 on WordPress/wordpress-develop by youknowriad.


2 years ago
#38

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

#39 @youknowriad
2 years ago

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.

#41 @noisysocks
2 years ago

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.

#43 @gziolo
7 months ago

In 56983:

Tests: Improve code coverage for _build_block_template_result_from_file

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

Note: See TracTickets for help on using tickets.