Site Editing: Simplify template part toolbar

[jameskoster]

Here's the current template part toolbar:

While template part renaming is an important feature, I am not convinced it needs to be so prominent in the UI. Renaming a template part is a relatively rare exercise after all.

If instead we just display the template part name we can remove the "name" label, and simplify the toolbar while saving space:

Renaming can still be accomplished via the Appearance > Template Parts screen, and we might consider adding it to the ellipsis menu in the template part toolbar as well in the future.

In this branch I have also moved the name 'above' the alignment tool using CSS, but I am certain there is a better way to do that :D

[jameskoster]

Another option might be to combine the name with the block icon, and display the switcher when the name is clicked:

[jameskoster]

I think the above iteration would be good to try.

Adding the Needs Dev label as it goes beyond my designer brain to implement :D

[mtias]

Another option might be to combine the name with the block icon, and display the switcher when the name is clicked:

This seems much better to me. Not sure about the menu that opens, it feels like it should be the default transforms menu perhaps augmented with the template part switcher.

[aristath]

While template part renaming is an important feature, I am not convinced it needs to be so prominent in the UI. Renaming a template part is a relatively rare exercise after all.

Agreed. Additionally, renaming a template-part could possibly, probably, and in fact most likely interfere and prevent us from implementing #27337. footer, header etc are currently determined by their "name". Renaming them can cause issues if not properly implemented... The template-part's name is referenced in the template, so if I change the template-part's name while editing the index template, then the single template will be broken until I go in there and fix the reference to the now non-existing template-part.
So yeah... I don't think we should allow renaming template-part names from the site-editor like that. At least not in the beginning, not until all other aspects are relatively sound.
Showing a selector so that users can select another template-part won't cause any issues and it's something we can definitely do!

[mtias]

I think title and description (not slug) could be valuable to be editable, so if you have multiple headers saved for different purposes you can describe their intent

[aristath]

I think title and description (not slug) could be valuable to be editable, so if you have multiple headers saved for different purposes you can describe their intent

Yeah, if the slug remains unchanged there shouldn't be any issues 👍

[jameskoster]

Different headers will still need different slugs though, right? Could the name could be appended to the slug, making the whole thing behave like get_template_part()?

That would raise the question of how the "default" header is defined, though... I suppose we could prohibit renaming the default theme header?

[aristath]

Could the name could be appended to the slug, making the whole thing behave like get_template_part()?

I think that would be ideal... So we'd have header which would be the global header, overridable by header-red.

Thinking out loud, we wouldn't want users to be able to add a footer template-part in lieu of a header... So if we have a "header" area, users would preferably only be able to choose from one of the available headers - or create a new header. So if we go down that road, perhaps we should start thinking of template-part "zones"? 🤔

[jameskoster]

That's an interesting idea, but I wonder if it might be too restrictive? I'm not sure how sidebars would interact with headers / footers – what if I wanted a full-height sidebar? 🤔

[jameskoster]

it feels like it should be the default transforms menu perhaps augmented with the template part switcher

Circling back to this comment. We could use the transform menu with a larger preview on hover:

[Addison-Stavlo]

Yeah, if the slug remains unchanged there shouldn't be any issues 👍

This is how renaming now works after recent changes. Renaming only changes the title and not the slug.

I am not convinced it needs to be so prominent in the UI.

Agreed it may not need to be this prominent. However, I would argue we should move the renaming feature "somewhere" that is still usable inside the editor. Any ideas where it should go?

Renaming a template part is a relatively rare exercise after all.

Creating any new template part starts with the title "Untitled Template Part", this should remain easily re-namable in some way without leaving the editor.

Im definitely in agreement with the new design, but I think it would be a shame for the renaming feature to disappear altogether.

[jameskoster]

However, I would argue we should move the renaming feature "somewhere" that is still usable inside the editor. Any ideas where it should go?

I'm working on some ideas that will most likely be shared as a part of the designs for this issue.

Ideally renaming a template part should be somewhat consistent with renaming a regular template.

[mtias]

The last design looks like a good direction and would align us back with reusable blocks:

[jeyip]

@jameskoster @mtias

Using the same UI for the reusable blocks transform menu and the template part switcher makes sense to me, but just to clarify, are we getting rid of the "Transform to" options for template parts entirely? Or are we combining them with the "Switch to" options in James's mocks?

[mtias]

I'm not sure, because we also need to account for patterns here. Also it's not an interaction we support elsewhere (like swapping a reusable block for another). The closest I can think of is the "Replace" we have on images. I think my vote would be to not touch this just yet and leave it on pause until the patterns flow is worked out.

[jameskoster]

patterns flow

Latest explorations in this context are shared in #28737 (comment). I just noticed that the concepts there include a transform option on the template part block... you can probably ignore that detail – I don't think template parts should be transformable 😅

[mtias]

Aren't there cases where you might want to add a layout wrapper using transforms? Like placing a navigation in a column or a group.

[jasmussen]

Careful with "order", as they might make for inopportune tabbing flows.

[jasmussen]

Aren't there cases where you might want to add a layout wrapper using transforms? Like placing a navigation in a column or a group.

Sidebar might be a better example, I would imagine it was able to sit at any level of the hierarchy, whether inside a group, or a column.

[jameskoster]

Perhaps that would live in the "transform menu", but it isn't really a transform per se, and so would possibly need a unique treatment.

I'm also wondering if this "transform" wouldn't be better handled by the pattern work we've been exploring recently. It seems plausible that high-level layout patterns that include elements like sidebars could exist.

I am sure we'll look at this more closely when we (eventually) get around to from-scratch template creation flows.

[jeyip]

I think my vote would be to not touch this just yet and leave it on pause until the patterns flow is worked out.

Revisiting this once we have the toolbar pattern insertion flow more well defined makes makes sense to me.

On that note, after a brief investigation yesterday, simplifying the template part toolbar and the solution to handle switching template part entities is pretty straightforward. (At least for the existing mocks we have)

If we eventually decide that we'd like the end state to look like this, it should be relatively easy to implement. 👍

[talldan]

Removing the input from the toolbar would also solve #28825

[jameskoster]

I'm going to close this PR since it is half-implemented already. We can revisit template part switching separately.

@talldan I think you can close #28825 as well, the template part toolbar no longer contains an input.

[mtias]

@jameskoster depending on how long it takes for us to find a good solution for the "switch" flow we might consider updating the icon from the standalone chevron to something else in the meantime.

[jameskoster]

@mtias PR opened here to explore.