Blocks: Set default 'apiVersion' for client-side registration #70750
Conversation
This file contains hidden or 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
d9873af to
55f9a1e
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 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. |
|
Size Change: +10 B (0%) Total Size: 1.89 MB
ℹ️ View Unchanged
|
tyxla
reviewed
Jul 17, 2025
| @@ -78,6 +78,7 @@ export const processBlockType = | |||
| const bootstrappedBlockType = select.getBootstrappedBlockType( name ); | |||
|
|
|||
| const blockType = { | |||
| apiVersion: 1, | |||
There was a problem hiding this comment.
Like we see by needing to update a bunch of tests, this might break some tests or any custom extension logic that performs strict checking of block type.
With that in mind, should we potentially document it as a breaking change in the package?
There was a problem hiding this comment.
This is more like internal breaking change, shouldn’t affect most of consumers. But I’ll add changelog entry.
tyxla
approved these changes
Jul 17, 2025
|
Thanks for the feedback, @tyxla! |
|
As an aside, I think we're being unreasonably conservative with The The Shouldn't we expect all blocks to be compatible with v3 by now? Each version bump is triggered by exactly one change, a rather minor one for most block authors. Is this what @t-hamano aims for with #70743 and related PRs? |
I wish that were the case. However, there are still many blocks that are incompatible with iframes. We've had to revert push for iframed editors, almost every major release I can recall. Issue #70743 is an attempt to find some common ground and encourage developers to make their blocks compatible. |
It's the same in my memory 😅 Personally, I think it would be ok to change the default api version from 1 to 3 if we publish a dev note. |
USERSATOSHI
pushed a commit
to USERSATOSHI/gutenberg
that referenced
this pull request
Jul 23, 2025
…ess#70750) * Blocks: Set default 'apiVersion' for client-side registration * Add changelong entry Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: tyxla <tyxla@git.wordpress.org>
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.
What?
PR updates block type processing helper function and sets the default -
apiVersion: 1.Why?
apiVersionis always defined during block registration.Testing Instructions
registerBlockTypefunction.apiVersionset -wp.blocks.getBlockType( 'test/block-api-version' );.Example Block
Testing Instructions for Keyboard
Same.