Blocks: Ensure that metadata registered on the server for core block is preserved on the client (try 2) #29302
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gziolo
added
[Feature] Block API
|
Size Change: +19 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
|
@noisysocks, as far as I can tell, we won't need to backport this version to WordPress 5.7 and it should be fine to use already backported commits. The regression reported should apply only to WordPress 5.6 and lower. |
8 tasks
|
Reserving this comment for testing: 5.6.2✅ Tests pass locally 👍 No API Version present in 5.6.2 as expected ✅ Classnames and correct wrapping elements appear
5.7 RC1👍 API version present in 5.7 as expected
5.8 alpha👍 API version present in 5.8 as expected
✅ Classnames and correct wrapping elements appear
|
gwwar
reviewed
Feb 24, 2021
There was a problem hiding this comment.
Such a speedy turnaround @gziolo ! ✨ I think this is pretty close. Smoke testing this across different versions we don't see the major regressions from last time. This change still works well with my experimental branch too.
I did perform a quick audit and I noticed we're missing the editorStyle and style attributes, from the server definition which may cause other issues.
Let's 🔍 more on that and maybe get a +1 for the review
| if ( | ||
| serverSideBlockDefinitions[ blockName ].apiVersion === | ||
| undefined && | ||
| definitions[ blockName ].apiVersion |
There was a problem hiding this comment.
I think I spotted a few more differences on the server definition:
- Missing
editorStyle - Sometimes items in
supports, get expanded in blockattributes(I think this is okay) - Missing
style
There was a problem hiding this comment.
It might be worth setting up a test case with all block registration items set and then compare to see what's returned.
There was a problem hiding this comment.
Missing
editorStyle
Missingstyle
At the moment it's used only on the server to enqueue CSS files, for example:
https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md#editor-style
In the future, we might need it on the client to lazy load CSS or JS files for the block.
Edit: In fact, those fields were used in the past for installing blocks from Block Directory, but it was replaced with a different approach in #24117. However, in practice, Block Directory uses its own endpoint to get the block metadata which is further processed block.json file:
gutenberg/packages/block-directory/src/store/resolvers.js
Lines 24 to 26 in 8ab2453
Sometimes items in
supports, get expanded in blockattributes(I think this is okay)
Yes, it's used quite extensively for features built-in in the block editor like alignment, custom class name, anchor, fonts, colors, and other stuff that Global Styles offer. Most (hopefully all) of the hooks that add those fields for attributes respect the version created by developers.
There was a problem hiding this comment.
Great, sounds like this should be relatively safe to try again. ✨
|
I tested and can confirm that the block wrappers are correct on 5.6.2 |
I will merge tomorrow to make sure I'm around if something goes wrong 😄 |
gziolo
deleted the
revert-29279-revert-29213-update/register-block-server-metadata
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
2nd attempt to land #29213 that revert the revert from #29279. This time it should cover the following issue when using WordPress 5.6:
New changes include the polyfill logic when
apiVersionis present inblock.jsonbut it isn't exposed from the server.This PR resolves the issue where metadata registered on the server from
block.jsonwould 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__bootstrapServerSideBlockDefinitionswas 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:
There is a new unit test added that ensures that polyfilling works as expected.
Use WordPress 5.6 and make sure that all blocks have the same class names applied as in WordPress 5.7. It's related to the
apiVersionpresence during block registration.For example, as reported by @glendaviesnz:
I tested with WordPress 5.6 and the Gutenberg demo page:
Block wrapper is correctly applied:
No `apiVersion in the response from the server:
Types of changes
Bug fix (non-breaking change which fixes an issue).
Checklist: