-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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: Fix truncation of post content #68926
Conversation
gutenberg_apply_block_hooks_to_post_content
Flaky tests detected in 8d1e654. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/13033762960
|
$content = apply_block_hooks_to_content( $content, $reusable_block ); | ||
// Remove block wrapper. | ||
$content = remove_serialized_parent_block( $content ); | ||
$content = apply_block_hooks_to_content_from_post_object( $content, $reusable_block ); |
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.
Note that each block that fetches content from a post object in the DB does so in a different way. Specifically, the Synced Pattern block (core/block
) does not invoke the the_content
filter, so we need to run apply_block_hooks_to_content_from_post_object
manually.
// but before `do_blocks` runs, as it would otherwise attempt to render the same block again -- | ||
// thus recursing infinitely. | ||
add_filter( 'the_content', 'remove_serialized_parent_block', 8 ); | ||
|
||
/** This filter is documented in wp-includes/post-template.php */ | ||
$content = apply_filters( 'the_content', str_replace( ']]>', ']]>', $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.
The Post Content block runs the the_content
filter, to which we've hooked apply_block_hooks_to_content_from_post_object
, which is why we don't have to run it manually here.
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @theMasudRana, @jacobzymet. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
This should be ready for review. Since it's a pretty nasty bug, it'd be great if we could get it merged and synced over to Core before WP 6.8 Beta 1 (next Tuesday). I'm not sure if another npm package release and sync is planned prior to that; otherwise, Beta 1 will have the bug, and the fix will only go into Beta 2. Anyway, pinging Release Tech Leads @joemcgill @desrosj @Mamaduka for advice. Testing this PR is no small feat; not only do we need to test that it fixes the original issue, but also to make sure that hooked block insertion into the affected blocks (Post Content, Synced Pattern, Navigation) still works (especially first child/last child insertion). For the latter, we can peruse the testing instructions from the respective PRs that added Block Hooks to those blocks:
and
It'd be great if we could divvy up testing to speed it up! (Ideally, we can land it on Thursday or Friday, so it can be part of another npm package release and sync prior to WP 6.8 Beta 1). If you'd like to help, edit this comment to add yourself to the above list, next to whichever block you're going to test, and leave a comment with your findings once you're done 😊 Tentatively pinging @ryelle @richtabor @gziolo @tjcafferkey to ask for help with testing, if you have a bit of time available 🙌 Finally, I've already started working on the Core port. I'll add some test coverage there and see to landing it before Beta 1. |
Thanks for working on this, @ockham! Does core have PHPUnit test coverage for these methods? Can we add additional unit tests? The release date of the WP 6.8 Beta 1 is March 4, 2025, so there will be at least one more Gutenberg release. |
Not yet.
Yes! I'm planning to add unit test coverage for
Oh, for what date is that GB release scheduled? (Also, we used to have a GB cut-off release some 2-3 weeks prior to WP Beta 1, after which any changes in GB had to be manually cherry-picked (to GB's |
Thanks again, @ockham!
The plugin cut-off happens a week before Beta 1 - https://make.wordpress.org/core/handbook/about/release-cycle/block-editor-release-process-for-major-releases/#scheduling-the-last-editor-release-and-communicating-deadlines. |
🤦♂️ For whatever reason, I had February 4 as the date for Beta 1 in my mind -- i.e. in less than a week from now -- even though you wrote March. Apologies -- took me a moment to realize! Anyway, that gives us plenty more time to work on this 😅 |
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.
Code changes look good. It's definitely much anticipated refactoring that helps to remove some code duplication. In my testing, everything works as expected for the edge cases covered that regressed. I also repeated the testing steps outline in #67272. It would be nice to add some e2e testing coverage as this started to be very complex process to find and repeat all these steps.
One thing that might need closer look is when using the Classic block in the post content. I couldn't make it work with inserting the hooked block as the last or first child in the core/post-content
block.
No blockers from my side! I'll file issues for the e2e tests, and for the problem with the classic block that @gziolo found. |
Thank you for merging this, @Mamaduka! I've filed |
What?
Fix #68605. To understand the underlying problem, see #68605 (comment).
How?
By introducing a new function,
apply_block_hooks_to_content_from_post_object
, to colocate the logic used to temporarily wrap content in a parent block (withignoredHookedBlocks
information fetched from post meta) alongside the call toapply_block_hooks_to_content
.This centralizes logic added to the Post Content (#67272), Synced Pattern (#68058), and Navigation (#57754) blocks.
See
#62716
.Testing Instructions
First, verify that this PR indeed fixes #68605. To do so, add the following filter:
Then, verify that content on the frontend is indeed replaced by
123456789
(and not by just456
).Additionally, it would be good to verify that this PR also fixes #68614.
Finally, testing needs to cover that insertion of hooked blocks into Post Content, Synced Pattern, and Navigation blocks still works as before -- with a special focus on insertion as first or last child of those blocks.
To that end, please refer to the testing instructions of #67272, #68058, and #57754, respectively.