Navigation Focus Mode: Ability to access/edit Navigation Post items in isolation

[getdave]

What problem does this address?

Since the move to saving Navigation items to a custom post type (wp_navigation) there is no longer a way to access the inner blocks data of a Navigation block.

This causes problems for users who wish to manually copy the inner blocks and use in a pattern or on another site.

Moreover, users are forced to use the Navigation block directly as the only way edit a give Navigation Post.

What is your proposed solution?

In the short term we should enable the content field on the Navigation Post type edit screen. As the inner Navigation blocks cannot currently function without a parent Navigation block, this should be forced to default to a code view. This will ensure there are no errors but will still allow power users to access the block grammar HTML.

In the longer term we should investigate

• using Isolated Template revising the Navigation Editor to edit Navigation Posts.
• finding a way for "inner" Navigation blocks (e.g. core/navigation-link) to function without having to be a child of a Navigation block

[talldan]

cc @mtias

This is an important next step alongside other nav block refinements. I think this needs some design input, so will add a label.

From a UI perspective, the main thing is that the inner content of the nav block is distinct from the navigation block styles (a bit like the situation here for template parts - #30641), so there would be no way to customize colors, overlay menus and some of the other visual styles in a standalone editor. Or even show those styles. Should this be more of a pure link editing mode?

In a focus mode it could be possible as @kevin940726 mentions here - #30641 (comment).

From a technical perspective, some of the challenges are detailed here - #36589 (comment).

In the short term we should enable the content field on the Navigation Post type edit screen.

I don't know how valuable this would be. Links are mostly dynamic blocks, so it's not like users will be able to adjust the HTML. I'd be a bit concerned about it being too easy to make a mistake. It could be a power user feature like the Code Editor, but I think the primary editing option should be visual.

[jasmussen]

In order to not introduce any new interfaces if at all possible, it seems like this could use the same interface that exists for editing the contents of template parts in isolation:

The challenge is that any navigation block changes made locally are not saved along with the menu itself. So if I change the font, colors, and overlay options when editing in a template context, as soon as I click to edit in isolation, those changes will no longer be visible. At that point I'm observing the global version of items, stripped of local decoration:

I chatted with @jameskoster about this, as he's been through adjacent challenges with template parts. The solution applied there was to disable local editing of colors, spacing, and layout entirely, relegating those changes to only be possible inside the isolated editor. Such a solution might not be intuitive for navigation, as there's value in visually editing in context of its surroundings.

At the same time, without any handling of local and global changes (such as forcing all local changes be saved/synced with the block), we could end up with a confusing mix: for example when editing the navigation in isolation and setting it to collapse to an overlay, and then seeing it uncollapsed when exiting isolation mode, overridden by a local change.

An interim solution could be to disable inspector controls for the navigation in the global/isolated interface, enabling appearance controls only in the local context. But this should probably be considered a temporary solution as it would depart from (invert) the logic applied to template parts.

In that spirit, it's good to look at where template parts might go in the future, and aim towards that. This might include an interface that embraces local overrides, and even as @mtias suggests, allows template parts to become style providers. There's a lot of good discussion on that thread, pertinent to the challenge here.

[getdave]

disable local editing of colors, spacing, and layout entirely, relegating those changes to only be possible inside the isolated editor. Such a solution might not be intuitive for navigation, as there's value in visually editing in context of its surroundings.

I think that might be a critical thing. We need to retain the separation of concerns between menu data and presentation.

I have been considering the Navigation Editor again recently. I wonder whether we could make a nice distinction here that avoids some of the pitfalls:

• the Nav Editor could be for global changes to menu data for the particular menu (i.e. wp_navigation post) being edited.
• the isolated Nav block view could be for editing menus that are not persisted to a wp_navigation post.

In our context, the Nav block is the style provider.

[talldan]

I think we need to be careful about introducing inconsistencies along the lines of some menus only being editable using one editor and other menus only be editable using another. At least without it being clear to the user why that might be. So far there hasn't been a strong proposal for making only certain menus persisted and that probably needs to be in place before it's a consideration. Is there an issue for it?

It's probably time to start thinking about a new navigation block tracking issue to document the future direction of the block.

Is there more information about style providers for blocks? It sounds like the idea is to store style data external to the block, much like inner blocks are stored in wp_navigation, with both referenced using a slug. That would indeed allow styling to be available both in the isolated view and globally.

[getdave]

It's probably time to start thinking about a new navigation block tracking issue to document the future direction of the block.

✅ #38275

Is there more information about style providers for blocks? It sounds like the idea is to store style data external to the block, much like inner blocks are stored in wp_navigation, with both referenced using a slug. That would indeed allow styling to be available both in the isolated view and globally.

I feel like there was a PR that @youknowriad was working on. Perhaps this one #37978?

[mtias]

Going through notifications and finally coming to this, pardon my tardiness.

@talldan this is very much what this issue was trying to capture #36667 as a next step. Now that navigation blocks are wrappers on the data values, we can present the data values in its tree form more prominently. (The mockups are showing a single main menu but it could offer more through a dropdown if the UI does indeed work.

For the focused view of navigation we don't necessarily need to introduce the styles from the parent template and we can just have some default ones or none at all and default to tree views.

[getdave]

Going through notifications and finally coming to this, pardon my tardiness.

No problem. I can imagine you have quite a few to get through 😄

For the focused view of navigation we don't necessarily need to introduce the styles from the parent template and we can just have some default ones or none at all and default to tree views.

This is what I'd like to pursue here. Start with a focused mode that is editing the "items" (the data). That can serve as a basis for other things in the future.

[talldan]

This is what I'd like to pursue here. Start with a focused mode that is editing the "items" (the data). That can serve as a basis for other things in the future.

Yeah, I think that would be good. The first draft doesn't need to have any special styling, it can just be a proof of concept.

[youknowriad]

With the proliferation of these focuses modes, I think we need to start to think about how these focus modes (which are in reality) multiple editors work together. We need to answer questions like:

• What's the UI that changes when you switch mode?
• What's the UI that stays there, that is common to all modes (save button, more menu...)
• How to write a new "mode" (think navigation mode, template part, reusable block, template mode in post editor...) and organize them properly in the code base.
• How to navigate between modes and what history need to be kept (do we need a "main/parent" mode to come back to).

I'm raising this to avoid introducing all these new modes in an adhoc way and bring some clarity there.

[getdave]

Isolated Editor modes

Some initial research.

Template Part mode

Screen.Capture.on.2022-03-08.at.07-03-22.mov

Note this is for editing Template Parts and thus is distinct from the Template mode (see below).

Appears to be a function of prop setting within packages/edit-site/src/components/block-editor/index.js. For example:

gutenberg/packages/edit-site/src/components/block-editor/index.js

Lines 63 to 66 in 5f140a6

	const [ blocks, onInput, onChange ] = useEntityBlockEditor(
	'postType',
	templateType
	);

Template Editing mode

Screen.Capture.on.2022-03-08.at.08-57-23.mov

Visually this appears near identical to the Template Part editing mode, but is infact a completely different set of components in a different pacakge within: packages/edit-post/src/components/visual-editor/index.js.

gutenberg/packages/edit-post/src/components/visual-editor/index.js

Lines 244 to 253 in 6c6582f

	<RecursionProvider>
	<BlockList
	className={
	isTemplateMode
	? 'wp-site-blocks'
	: undefined
	}
	__experimentalLayout={ layout }
	/>
	</RecursionProvider>

Reusable blocks mode

Screen.Capture.on.2022-03-08.at.07-05-27.mov

This is far less obvious UI wise. The reusable block appears almost seamlessly within the canvas.

This is a function of the core/block block which provides:

• inner blocks for the UI
• an entity editor for managing the persisting of blocks

gutenberg/packages/block-library/src/block/edit.js

Lines 62 to 66 in 5f140a6

	const [ blocks, onInput, onChange ] = useEntityBlockEditor(
	'postType',
	'wp_block',
	{ id: ref }
	);

[getdave]

I experimented with a focus mode editor for Navigation Menus.

[annezazu]

Feedback came in to support/ask for this exact experience in the nineteenth call for testing:

I think you need to lock people into a menu-editing mode. When you hit edit menu/nav, you enter some kind of focus mode where that’s all you can do until you explicitly exit.

Passing along for context :)

[getdave]

Noting feedback from @paaljoachim in this comment.