Sidebar Tabs: Stabilize the block inspector tabs experiment #47045
Conversation
Without this change we have to wait for fills before the tab would be included preventing the list tab being a default.
aaronrobertshaw
added
[Type] Enhancement
aaronrobertshaw
requested review from
TimothyBJacobs,
spacedmonkey,
geriux,
ellatrix and
tellthemachines
as code owners
|
Size Change: +1.08 kB (0%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 175a868. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3890697796
|
|
With the tabs being stabilized, a number of e2es will need updating. I'm in the process of updating them. |
packages/block-editor/src/components/inspector-controls-tabs/use-inspector-controls-tabs.js
Outdated
Show resolved
Hide resolved
packages/block-library/src/navigation/edit/menu-inspector-controls.js
Outdated
Show resolved
Hide resolved
aaronrobertshaw
requested review from
ntwb,
nerrad and
ajitbohra
as code owners
|
Yep, that all makes sense to me. I suppose with both |
+1 for this. Having an easy way to explicitly add options to each tab would be perfect for block plugins. |
|
PR stabilizing inspector controls groups, adding a styles group, and aliasing the default group as settings is up in #47105. |
Dev Note for 6.2Introduction of Block Inspector TabsThe new Block Inspector tabs aim to help organize and delineate the design tools within our Block Inspector sidebar. Before these tabs, the sidebar was becoming increasingly crowded and challenging to use. With the release of WordPress 6.2, you'll find the inspector's design tools categorized under three tabs;
Block Inspector Tabs DisplayThe Block Inspector will only render tabs when it makes sense to do so. As such, there are a few conditions around their display:
It is possible that the Block Inspector tabs may not make sense for all blocks. Plugins might also aim to overhaul a block's available tools. In these cases, it would be desirable to disable Block Inspector tabs. This can be achieved via a new editor setting, function my_plugin_disable_tabs_for_my_custom_block( $settings ) {
$current_tab_settings = _wp_array_get( $settings, array( 'blockInspectorTabs' ), array() );
$settings['blockInspectorTabs'] = array_merge(
$current_tab_settings,
array( 'my-plugin/my-custom-block' => false )
);
return $settings;
}
add_filter( 'block_editor_settings_all', 'my_plugin_disable_tabs_for_my_custom_block' );If available, the Block Inspector tabs will be displayed in the following order; List View, Settings, and Appearance. The default selected tab will be the first available. For the majority of blocks, this will be the Settings tab. Inspector Control GroupsThe In addition to stabilizing the <InspectorControls group="styles">
// Add your custom styles-related controls here.
</InspectorControls>Block Inspector Tabs vs InspectorControl GroupsEach Block Inspector tab is responsible for displaying a subset of the available Inspector Controls groups.
Settings-only BlocksDuring the experiment trialling Block Inspector tabs, it became clear that some blocks should be considered "settings-only". A great example of this is the Query block. A user's primary focus while interacting with this block is to configure it to display their desired posts. Attempts to apply styling, e.g. colors, at such a high level leads to inconsistent results. To remove that friction moving forward, we've removed the color block support from the Query block, making it settings-only. A new deprecation has been added to migrate existing Query blocks with color styles. These will have their inner blocks wrapped in a Group block with the original color styles applied. For blocks considered settings-only, the recommended approach to styling moving forward is to wrap the inner blocks in a style-provider block, e.g. Group. @bph the draft above aims to cover the dev note requirements for a number of tightly coupled PRs (#47045, #47105, #45005, #46321, #46147). Do you think that covers all that's required, or is a bit too much? I'm happy to continue iterating on it in light of any feedback. |
|
This is great, thanks @aaronrobertshaw. It covers everything I can think of that an extender would want to know 🙌 |
|
I agree with @ndiego. Thank you, @aaronrobertshaw would you have bandwidth to add the note to the make blog in draft so we can get it into the publishing queue? I'd be happy to do it for you, though. I know it's a bit short notice. Note: I see a few references "we" that would need to be reviewed. Options:
|
bph
added
has dev note
|
@bph I've tweaked those references to "we" while creating a draft on the Make blog: |
|
Maybe I missed something, but where is custom class and anchor section now? I see that instead of Advanced section, we have "Looking for other block settings? They've moved to the styles tab." but this section is not available under Styles tab
|
|
@ndiego I thought Gutenberg plugin has the same things as Beta WP. Ok, with beta 4 I don't see typography, so it's fixed About class panel, How to reproduce - add any core block, you will see next
But if I go to Style tab, no Advanced panel, so, we have no option to add "ADDITIONAL CSS CLASS(ES)" or anchors
|
|
Hi @wpsoul, in the first screenshot above the notice is the Advanced panel. Clicking on this will open the panel, which will have the options. Is that what you are looking for? |
|
Curious @aaronrobertshaw whether we might want to clarify this in the dev notes, but can an extender use |
|
@ndiego clear now, ok, but maybe it's better to place this notice inside Advanced panel, because currently all content is inside panels and when I see this notice, I decided that it's part of Advanced panel. Or maybe removing notice will be better, I don't see that it solves something, just confusing. Style tab is visible enough and doesn't require any notice |
|
@wpsoul, thanks for flagging the potential for confusion regarding the hint notifying users that controls may have moved tabs.
The purpose of the hint is to reduce some of the friction created by reorganising controls into different tabs. Burying this hint under a collapsed by default Advanced panel would defeat its purpose.
I can understand the potential for this confusion. I wonder if the original design accepted this potential was mitigated by the visual cue of the Advanced panel's chevron indicating that it is collapsed and can be expanded.
It's expected that over time, the need for this notice will be reduced and it can in fact be removed. You can find more context and history around the current design and past decisions in the issue and PR introducing the hint. If you'd still like to propose removing or relocating the hint, would you mind creating a new issue and linking it to the original issue/PR above? It would help to attract a wider set of opinions and ideas than this conversion being hidden on a loosely related PR. |
Thanks for the suggestion @colorful-tones, I'm not sure we should make this PR's dev note a complete readme around As for the question at hand, I'm not 100% certain whether it is possible to render |
👍
I would love to know what you find if/when you have time to dig more. I think this will quickly become a common feature request for extenders who want to organize their plugin's settings into "General" and "Advanced" tabs, which we should aim to clarify whether this is suitable or even recommended. Thanks @aaronrobertshaw ! |
|
I did some digging into why The reason is that More specifically, it's this check that causes nothing to be rendered since It may be possible to make it work (I haven't checked feasibility), but I don't think it'd be a high priority since there's already a decent alternative (the |
|
Thanks for investigating @aaronrobertshaw |
|
The props for pinpointing where the limitation occurs go to @talldan. I merely reached out to pick his brain 😁 |
Related:
What?
Why?
We're pretty confident the tabs are here to stay, given generally positive feedback in recent calls for testing. These tabs must also be stabilized for the Navigation block's off-canvas editor to be the default experience.
How?
window.__experimentalEnableBlockInspectorTabsbased on experimentwindow.__experimentalEnableBlockInspectorTabs__experimentalprefix from the block inspector tabs block editor settingTesting Instructions
blockInspectorTabs.defaulteditor setting tofalseto check complete disabling of tabsClick for quick and dirty patch to update block editor setting to test disabling tab display across blocks
diff --git a/packages/block-library/src/navigation-link/index.php b/packages/block-library/src/navigation-link/index.php index f214a6b9b5..db113f7289 100644 --- a/packages/block-library/src/navigation-link/index.php +++ b/packages/block-library/src/navigation-link/index.php @@ -396,7 +396,7 @@ function gutenberg_disable_tabs_for_navigation_link_block( $settings ) { $settings['blockInspectorTabs'] = array_merge( $current_tab_settings, - array( 'core/navigation-link' => false ) + array( 'core/navigation-link' => false, 'default' => false ) ); return $settings;Screenshots or screencast
Screen.Recording.2023-01-11.at.11.53.32.am.mp4