-
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 API: Registration with "empty" defaults from rWP47875 conflict with block defaults #22810
Comments
Temporary fix at #22811 |
The temporary fix at #22811 was merged. For the fix to be reflected in pull requests, it may be necessary for branches to be rebased. Alternatively, depending if a subsequent change is made in core codebase, it should begin to take effect more immediately (once a new nightly is built). |
I wasn't aware that we use https://github.com/WordPress/wordpress-develop for e2e testing but I think it's a valid approach that helps to catch issues like this immediately 👍
@aduth, thank you for flagging the root cause and providing the temporary fix that gives us some time to discuss the long-term solution. As explained in #22812, we should refactor codebase to start using the new block types REST API endpoint to fetch the list of the blocks from the server. https://core.trac.wordpress.org/changeset/47875 was based on the implementation of the endpoint. It's quite difficult to navigate between PHP and JS because block types were initially client-side only. It looks like there are a few things we could improve:
So the question here is whether we should make |
Yes, as of #22280 the
If it's approached from the perspective of how it had worked previously, the client-side registration relies on the absence of the value to determine if fallbacks should apply. I assume this could need to change if server-side (and at least from the REST endpoint), we want to have a consistent set of properties, even if those properties are "empty". So I think that This distinction of registration vs. registry could be important, and also affect how we consider block type storage in the client. I think it'd be reasonable to assume that registration in both PHP and JavaScript support the omission of certain optional properties, but for how that type is represented in the registry of block types, we'd expect that the properties always be assigned, even if to some "empty" default. For me, I see a few specific points of action:
While it doesn't affect the client-side implementation very much, I'd also wonder about |
I have proposal that should address all points we discussed in #22849. It should follow up with PHP changes in WordPress core. |
Removing "[Priority] High" label, since #22811 should at least give some breathing room for working to a complete resolution. |
Related: https://core.trac.wordpress.org/changeset/47875
Related Slack conversation (link requires registration): https://wordpress.slack.com/archives/C02QB2JS7/p1591045633488200
The core commit r47875 introduces an incompatibility with how block default values are considered.
With this commit, many fields now assign a default "empty" value, either empty string, empty array, or
null
.This can conflict with default block registration will merge default values, since these defaults (even
null
) will take precedent over the fallback value:gutenberg/packages/blocks/src/api/registration.js
Lines 143 to 151 in 281464a
Some validation may also conflict with the new defaults.
Example: Empty string
''
default category may be flagged as invalid:gutenberg/packages/blocks/src/api/registration.js
Lines 206 to 211 in 281464a
Example: Empty string
''
default icon may be flagged as invalid:gutenberg/packages/blocks/src/api/registration.js
Lines 230 to 237 in 281464a
The latter of these is currently causing failed builds on the
master
branch:https://travis-ci.com/github/WordPress/gutenberg/jobs/342186917
Possible Solutions:
Short-term, the builds should be resolved by one of:
Long-term, empty values should be reevaluated by one of:
null
or some equivalent of unset server-sidenull
when performing the settings merge during client-side block registration, thenull
value will take precedence. Previously, it would rely on the fact that the value was unset (undefined
).The text was updated successfully, but these errors were encountered: