-
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
Blocks: Ensure that metadata registered on the server for core block is preserved on the client #29213
Conversation
Size Change: +18 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
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 tests well for me @gziolo! Thanks for pulling this change out into its own PR 💖
…is preserved on the client (#29213) * export metadata, temporary placeholder to not override server values * Add e2e test that ensure that filtered metadata is propagated to the client * Fix issues raised by PHP linter Co-authored-by: Kerry Liu <[email protected]>
We need to revert this one @glendaviesnz found that this is wrapping blocks in additional divs |
Removing the backport label as there's a revert for this PR - #29279 |
This PR is causing all blocks to wrapped in a |
Yes, it's because I checked all |
Can we add an automated test (e2e, snapshot, or otherwise) to guard against this? What would be the most reliable/generalized/minimal way of covering this? #bernieTestNag |
@ockham I'll make a simple test |
…is preserved on the client (#29213) * export metadata, temporary placeholder to not override server values * Add e2e test that ensure that filtered metadata is propagated to the client * Fix issues raised by PHP linter Co-authored-by: Kerry Liu <[email protected]>
Description
Extracted from #29095.
Alternative to #28829.
Props to @gwwar for the proposed solution.
This PR resolves the issue where metadata registered on the server from
block.json
would get overridden by the same data registered again on the client. The fix proposed ensures that for all blocks that have some metadata present, we skip all other attempts to pass the same metadata.unstable__bootstrapServerSideBlockDefinitions
was never meant to stay for so long, but here we are. It isn't part of public API so we shouldn't be worried about backward compatibility that much.It's a blocker for #29095.
It also was caught by @audrasjb when compiling the dev note for new filters added for
register_block_type_from_metadata
. I included e2e tests that ensure that one of the new filters is properly propagated to the client.How has this been tested?
There is a new e2e test added that ensures that the updated logic works correctly:
Types of changes
Bug fix (non-breaking change which fixes an issue). Should be backported to WordPress 5.7. /cc @noisysocks.
Checklist: