Title & Featured Image: Hide non content controls when block editing mode is 'contentOnly'#59295
Conversation
…ting mode is 'contentOnly'
|
Size Change: +2 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 9ce28dc. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8012320946
|
ramonjd
left a comment
There was a problem hiding this comment.
LGTM - settings are hidden in template preview mode for post featured image and post title blocks.
I can still replace the featured image src as expected.
Before
2024-02-23.10.44.49.mp4
After
2024-02-23.10.46.01.mp4
andrewserong
left a comment
There was a problem hiding this comment.
Thanks for fixing this up! This is mostly working well for me. One thing I noticed is that the controls appear to be hidden for the Featured Image and Title blocks if it's a child of Content. Is that a bug?
To reproduce, I'm in the post editor, and added a Featured Image or Title block within the post, and then switched on Template preview.
Also, and I don't think it's a blocker for this PR, but the Advanced > Block Name control is still visible for these blocks in content only mode. I imagine the block support that allows blocks to be renamed might need to be aware of content only mode, too?
|
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. |
Can also reproduce. Would a parent check work? const hasThisThing = useSelect( ( select ) => {
const { getBlockParentsByBlockName } = unlock(
select( blockEditorStore )
);
return (
getBlockParentsByBlockName( clientId, 'core/post-content' ).length >
0
);
}, [ clientId ] );
// ...
const thingo = hasThisThing || blockEditingMode === 'default';
return (
<>
{ thingo && (
<>
<BlockControls group="block">
//... |
|
Thanks! Definitely a bug, but nothing to do with this one. I'll fix separately. |
|
I must have misunderstood. I figured the behaviour mentioned is directly related to the PR since it's hiding the block controls for every instance of the block when No matter, ignore me. Thanks for the follow up! |
Yes, that was my understanding, too. When I tested it, I thought you could still access the controls at that level in
+1! |
|
@noisysocks Great job getting this fixed up. Thank you 🙇 |
…ting mode is 'contentOnly' (#59295) Co-authored-by: noisysocks <noisysocks@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: colorful-tones <colorful-tones@git.wordpress.org> Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
|
I just cherry-picked this PR to the cherry-pick-wp-6-5-beta-3 branch to get it included in the next release: 12436cb |
…ting mode is 'contentOnly' (#59295) Co-authored-by: noisysocks <noisysocks@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: colorful-tones <colorful-tones@git.wordpress.org> Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
|
A bisect points to this PR as breaking the overlay rendering for the featured image block. Screen.Recording.2024-03-26.at.10.54.08.AM.mp4 |
|
A fix for the Featured Image block's overlay is available in #60187. |
View diff without whitespace
What?
Fixes #59291.
How?
Updates the Title and Featured Image blocks to hide the 'Link to', Overlay, and Dimensions panels when the block's
blockEditingModeis'contentOnly'.It's up to each block to check
blockEditingModeand hide and show the controls that are appropriate for that editing mode. Most blocks and block supports correctly check the mode and hide controls that are not content related ifblockEditingModeis'contentOnly'.Something that has come up before is whether we should simply hide all
InspectorControlswhenblockEditingModeis'contentOnly'. It's debatable because it isn't necessarily the case that all inspector controls have nothing to do with editing content. What is content and what is not content is difficult to say at a global level which is why we leave it up to the blocks. I'm on the fence. At any rate I think it's better to just do the simple fix for 6.5.Testing Instructions