Disable block supports derived design tools when Blocking Editing Mode is not default
#50912
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
scruffian
added
the
[Feature] Site Editor
scruffian
force-pushed
the
update/block-supports-for-editing-modes
branch
from
6a64a86
to
7ebb626
Compare
|
Size Change: +35 B (0%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 7f7b5de. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5082077584
|
scruffian
force-pushed
the
update/block-supports-for-editing-modes
branch
from
1163c2e
to
5a6d5ad
Compare
Block Supports: Disable block supports when Editing Mode is not default Co-authored-by: Alex Lende <5129775+ajlende@users.noreply.github.com> Co-authored-by: Ben Dwyer <275961+scruffian@users.noreply.github.com>
scruffian
force-pushed
the
update/block-supports-for-editing-modes
branch
from
5a6d5ad
to
7f7b5de
Compare
13 tasks
getdave
changed the title
default
|
Related #50857 |
There was a problem hiding this comment.
This is testing pretty well for me.
The block support design tools aren't rendering when editing the nav block in focus mode.
I did run into one scenario though where the styles tab was still rendered. With a Social Links block within the navigation its icon color and background controls are still rendered to the color panel in the styles tab. They are ad hoc controls so might be a different use case but if we aren't allowing other blocks to change colors, I'm assuming we'd want to tidy this up as well?
|
Logically this makes sense to me. Hiding these auxiliary panels when the editing mode is 👍 |
|
When a block list is in contentOnly mode, you can't access the block inspector of the inner blocks at all. Here with a locked group, the paragraph is selected and there's no way to see the inspector: I see now the distinction here is that when a single block is contentOnly that doesn't happen, but I think it should work the same way. So not only hide the design tools, but hide everything. |
14 tasks
Good point but it's not the behaviour we want in #50857. In there, the Post Content block has |
|
Let's get this in as it fixes an issue @tellthemachines noticed in #50857 while testing. I've tested this by merging this branch into #50857. We should fix the Social Links issue @aaronrobertshaw found in #39286 before that is merged. |
noisysocks
approved these changes
Jun 2, 2023
Maybe I'm misunderstanding. I thought that in this case only the Post Content block would be Otherwise I think maybe there's a need to reconsider the term 'contentOnly', and instead call it something different for |
artemiomorales
pushed a commit
to artemiomorales/gutenberg
that referenced
this pull request
Jun 2, 2023
Block Supports: Disable block supports when Editing Mode is not default Co-authored-by: Alex Lende <alex@lende.xyz> Co-authored-by: Alex Lende <5129775+ajlende@users.noreply.github.com> Co-authored-by: Ben Dwyer <275961+scruffian@users.noreply.github.com>
|
I had to change the semantics around Agree the name sucks. In my mind the inner blocks are "content" and so Lots to think about 🤔 definitely don't think we should make this API public for 6.3. |
Ah, I wondered about that, as I remembered seeing it implemented the other way. Being able to mix different editing modes for parents and their children seems like it could unlock a lot of possibilities, so it'd be a nice thing to explore later. It could finally solve #7694 😄
My understanding is that the 'content' part of the naming was supposed to refer to |
43 tasks
sethrubenstein
pushed a commit
to pewresearch/gutenberg
that referenced
this pull request
Jul 13, 2023
Block Supports: Disable block supports when Editing Mode is not default Co-authored-by: Alex Lende <alex@lende.xyz> Co-authored-by: Alex Lende <5129775+ajlende@users.noreply.github.com> Co-authored-by: Ben Dwyer <275961+scruffian@users.noreply.github.com>
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?
Following on from #50643, this hides block supports when Editing Mode is set to be not the default.
Why?
When blocks are not in
blockEditingMode === 'default'state then we shouldn't be able to modify their settings via block supports.How?
Disable the hooks when
blockEditingMode !== 'default'.Testing Instructions
This has to be tested in conjunction with #39286
Checkout that PR and this one and then open the navigation block in focus mode. Check that the inspector controls don't show the anything except the list view panel:
Note
@noisysocks (or anyone else) if you want to take over this PR be my guest