-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Hooks API: Update block-template-utils for first-last child template parts #6867
Block Hooks API: Update block-template-utils for first-last child template parts #6867
Conversation
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
This is looking good! Love to see the re-use of Is it possible to get away with even fewer changes (to |
As it stands using that filter in the templates controller only gives us the following information; I think we have two options to fix that:
|
Having looked at it again. If the template already has a database record we get the |
Is that really a problem though? Can't we implicitly assume |
Another thing I realized is that on a higher level, For the editor (i.e. the REST API), we might be able to use |
Unless I'm misunderstanding what you're saying here. Those pieces are covered by the updates I made to |
No, that's fine! I guess I was hoping to unify first/last child insertion into |
tests/phpunit/tests/blocks/updateIgnoredHookedBlocksPostMeta.php
Outdated
Show resolved
Hide resolved
bc236c9
to
aaea68d
Compare
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN:
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
src/wp-includes/blocks.php
Outdated
); | ||
|
||
/* | ||
* Skip meta generation when the post content is not in the above map. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Skip meta generation when the post content is not in the above map. | |
* Skip meta generation when the post type is not in the above map. |
src/wp-includes/blocks.php
Outdated
if ( empty( $post->ID ) ) { | ||
return $post; | ||
} | ||
|
||
/* | ||
* Skip meta generation when consumers intentionally update specific Navigation fields |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Skip meta generation when consumers intentionally update specific Navigation fields | |
* Skip meta generation when consumers intentionally update specific fields |
src/wp-includes/blocks.php
Outdated
* We only hook into filters for the `wp_navigation` and `wp_template_part` post types. | ||
* So if the post type is not set we can assume it's a `wp_template_part`. | ||
*/ | ||
$post_type = isset( $post->post_type ) ? $post->post_type : 'wp_template_part'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should infer the post type from the existing post object instead (if there is one).
If I'm not mistaken, the post type will be supplied as part of the stdClass
object if the post object is to be newly created in the DB. This is true both for template parts and for navigation post objects. (This is in keeping with the general concept of the stdClass
object: It contains all the information that needs to be changed -- or newly created -- when updating (or newly creating) the object in the DB. If the object already exists, it will already have a post_type
.)
src/wp-includes/blocks.php
Outdated
// Given a post object ($context), get_post will return a WP_Post object. | ||
$context = get_post( $context ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit risky to me; any reason why we aren't doing
// Given a post object ($context), get_post will return a WP_Post object. | |
$context = get_post( $context ); | |
$context = new WP_Post( $context ); |
(like we're doing e.g. here)?
src/wp-includes/blocks.php
Outdated
if ( 'wp_template_part' === $post_type ) { | ||
// Convert the $context WP_Post object to a WP_Block_Template object. | ||
if ( isset( $post->ID ) ) { | ||
$context = _build_block_template_result_from_post( $context ); | ||
} else { | ||
$meta = isset( $context->meta_input ) ? $context->meta_input : array(); | ||
$terms = isset( $context->tax_input ) ? $context->tax_input : array(); | ||
$context = _build_block_template_object_from_post_object( get_post( $context ), $terms, $meta ); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code seemed fairly reminiscent of inject_ignored_hooked_blocks_metadata_attributes
, which makes sense, given this other observation 😅
…rt_block is run as a visitor callback
…template_part hook
…ed_hooked_blocks_metadata_attributes
This reverts commit 87d9b03.
ab9b20c
to
b679595
Compare
Committed to Core in https://core.trac.wordpress.org/changeset/58614. |
$this->assertStringEndsWith( '<!-- wp:tests/my-block /-->', $template_part->content ); | ||
} | ||
|
||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing star. Same for some other unit tests
For ex. /**
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thank you! I'll address in a follow-up.
$template->content = traverse_and_serialize_blocks( $blocks, $before_block_visitor, $after_block_visitor ); | ||
|
||
if ( 'wp_template_part' === $template->type && $has_hooked_blocks ) { | ||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove extra star per inline comment formate.
/*
* Comment text
* goes here
*/
@ockham Left two nit-pick feedback. |
Fixed in https://core.trac.wordpress.org/changeset/58615. Thank you! |
Currently you are unable to insert hooked blocks in
first_child
andlast_child
positions of template parts. This is because, similarly to the Navigation block the anchor block (core/navigation
/core/template-part
) and its children are detached in the markup from one and other.To solve this issue we have approached it in a similar way by mocking the anchor block in such cases for the purpose of running the block hooks algorithm against it and extracting any related metadata (e.g.
ignoredHookedBlocks
) which are then stored in postmeta.Trac ticket: https://core.trac.wordpress.org/ticket/60854
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.
Testing instructions
core/loginout
block as afirst_child
into template parts._wp_ignored_hooked_blocks
data fromwp_postmeta
from your site and perform steps 1-3 again for modified templates.functions.php
block.json