-
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 Variations: Have getActiveBlockVariation
fall back to default variation
#63858
base: trunk
Are you sure you want to change the base?
Conversation
Size Change: +26 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
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. |
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 makes sense!
- If there is a match for the
isActive
field, we return that match. - If there isn't a match for the
isActive
fiend, we return the variation with theisDefault
flag.
I don't see any flaws in that logic 🙂. I would have also expected the isDefault
to work this way.
In a follow-up, it would be nice to log a warning if multiple blocks accidentally have the isDefault
flag. With the current implementation, the first variation in the array would be returned, which is reasonable behavior.
Thank you @michalczaplinski! Unfortunately, e2e tests do not seem to agree with this reasoning 😂 -- I'll have to figure out what's going on there. |
99535f0
to
ab758fd
Compare
😅 . Yeah, you're right. I thought this might be because the current PR should perhaps be stacked on top of #63100. I checkout out both and merged #63100 into the current one locally, but the e2e tests still fail. |
I've started digging. Here's one of the tests that's failing: gutenberg/test/e2e/specs/editor/plugins/block-variations.spec.js Lines 47 to 60 in bfffbe0
The "Large Quote" variation of the Quote block is registered by an e2e test helper plugin: gutenberg/packages/e2e-tests/plugins/block-variations/index.js Lines 23 to 30 in bfffbe0
Here's a screenshot (that's part of the artifact generated by CI when the e2e test failed): |
I tried to repro that e2e error manually but haven't been able so far. Anyway, I suspect it has to do with two different variations having |
It’s possible to accidentally set multiple variations as default through plugins so it picks the first default found if I recall correctly. |
What?
If a block doesn't match any of the block type's variations, return the variation that has
isDefault
set totrue
(as long as it doesn't have anisActive
field, as that would mean that it didn't match the latter).Why?
See #63100 (comment).
How?
Explained above :)
Testing Instructions
Cherry-pick ecedae0 (from #63100) on top of this PR.
Then, in the editor, insert multiple Group blocks, choosing a different variation each time. Save your post and reload the editor. Verify that the block inspector reflects the correct variation for each block.