Command Palette: Mapping Contextual Commands

[richtabor]

Tentative mapping out of contextual commands for the Command Center.

These are commands that should be suggested and prioritized when the Command Center is invoked from specific flows (currently within the Site Editor). There are likely more to bake in, but these will help us build it out.

If you have ideas for more, do share them.

Site Editor

Command	Requirement	Suggested	Action
Open Styles	N/A	Yes	Opens the Global Styles panel
Open Templates	N/A	Yes	Opens the Site View > Template sidebar
Open Library	N/A	Yes	Opens the Site View > Template Parts sidebar
Open Style Book	N/A	No	Opens the Global Styles panel, Activates Style Book, Closes List View
Open Style Variations	N/A	No	Opens Site View > Styles sidebar (or Styles sidebar in the Inspector). Also consider re-naming to "Style Variations", as Open and Browse styles isn't great.
Add custom CSS	N/A	No	Opens Styles sidebar with the CSS panel available.

Editing a template

Command	Requirement	Suggested	Action
Manage templates	N/A	Yes	Opens the Manage Templates view
Edit header	Has header template part	Yes	Opens the template's Header in isolated template mode
Edit footer	Has footer template part	Yes	Opens the template's Footer in isolated template mode
Delete template	Is a custom template	Yes	Moves the currently viewed template to the trash
Replace template	N/A	Yes	Opens the template pattern selection modal that currently renders when adding a new template
Clear customizations	Yes	Customizations are present and is not a custom template	Resets the template to the default state

Editing a template part

Command	Requirement	Suggested	Action
Manage template parts	N/A	Yes	Opens the Manage Templates Parts view
Replace template part	N/A	Yes	Opens the template part replace modal
Clear customizations	Customizations are present	Yes	Resets the template part to the default state

Editing a postType

Command	Requirement	Suggested	Action
Preview postType	N/A	Yes	Opens the preview link in a new tab
Publish postType	postType is not published	Yes	Publishes the postType
Save postType	postType has unsaved changes	Yes	Saves changes
Delete postType	postType is a draft, or published state	Yes	Moves postType to trash
Duplicate postType	postType is a draft, or published state	Yes	postType is duplicated as a draft
Add new postType	N/A	Yes	Opens Add New modal #48456

Editing a category template

Command	Requirement	Suggested	Action
Manage categories	N/A	Yes	Opens the /edit-tags.php?taxonomy=category view

cc @youknowriad @WordPress/gutenberg-design

[richtabor]

A WIP, and some may not be entirely possible just yet. Let's riff on these to get going.

[jameskoster]

Nice, this looks like a great start.

• Editing a template part could have the same Replace command as editing a template.
• If we're to include category management as suggested in Details View → Templates #49597, should we mock up a list for Editing a taxonomy term?
• I guess they're not included here as they're not strictly commands, but I assume we'll have a small 'Recently edited' list in each panel?

[richtabor]

Editing a template part could have the same Replace command as editing a template.

✅

If we're to include category management as suggested in #49597, should we mock up a list for Editing a taxonomy term?

Good idea. I'll add one for "Manage categories" and another for "Add new category template".

I guess they're not included here as they're not strictly commands, but I assume we'll have a small 'Recently edited' list in each panel?

I wanted to focus on the actual commands this go around, but recent "context" will be good.

[richtabor]

@youknowriad Do we have sub-commands yet, or was that still up in the air?

Example:

[ramonjd]

🤞 We can add a command for Global styles revisions for the site editor soon!

[youknowriad]

@richtabor We don't have sub commands yet.

---

Also, I'd like some clarifications about how the "contextual commands" work. For instance:

• when editing a "template", I'm also within the "site editor", do I show both the contextual commands for template and site editor?
• when I'm editing a template part, I can be within edit template and within the site editor as well...

I'd love also to get some designs/mockups about how these contextual commands should look.

[jasmussen]

when editing a "template", I'm also within the "site editor", do I show both the contextual commands for template and site editor?

This one could depend on #49980. That is, if you are in the site editor, but in the "page editing" portion, you can show one set of commands, whereas inside the template editing "mode", you'd show the others.

when I'm editing a template part, I can be within edit template and within the site editor as well...

Can we be aware of what's selected in the canvas?

My instinct when thinking of contextuality, it's related either to what is selected, or what mode you are in. So Site editor > select header > edit header in focus mode — the last two steps, or at least the last step, could be the context that defines the suggestions.

CC: @richtabor in case you have clarification or mockups going over this.

[youknowriad]

My question is about when we have more than one context, do we accumulate the contextual commands or do we force the command center to only show one context at time (the more focused I guess)

[jasmussen]

My instinct would also be that we always replace the suggestions with the most focused context.

[richtabor]

when editing a "template", I'm also within the "site editor", do I show both the contextual commands for template and site editor?

Perhaps the "Site Editor" table of suggestions above is throwing us a bit. Currently you have to be in the Edit View to trigger the command center (for now, at least). These are the fallback suggestions (the ones marked as suggestions).

---

I see these as a tree of context. If I'm in the Site Editor, editing a template, I will have the "Editing a template" commands suggested/prioritized, but I can still access the "Open Style Book" command if I type in "Open S".

"Open Style Book" is limited to the Site Editor top-level context, while "Replace template" is limited to the "Editing a template" context within the Site Editor.

The tree is important, especially as we consider bringing the Command Center elsewhere, like the Post Editor. As in that scenario there would be commands (suggested, or otherwise) that should be scoped to the Post Editor (and commands, like "Open Style Book" which should not be available in the Post Editor).

Regarding the suggestions, I think of them as a flag of sorts. Flagging a command within a specific context should surface it as an available command when I press CMD+K.

Does that clear it up?

[richtabor]

My instinct when thinking of contextuality, it's related either to what is selected, or what mode you are in.

I think focusing on where you're at in the editing experience is appropriate.

If I'm in an isolated mode of the template part (&postType=wp_template_part&canvas=edit) then I'm in the edit template part context and the commands "Manage template parts", "Replace template part", and "Clear customizations" are suggested.

If I'm editing a template, then I am in the edit template context, and those commands are suggested.

If I don't have a specific context, i.e. I clicked on "Templates" from the Site Editor navigation (?path=%2Fwp_template), and have not yet dove into a template to edit, then I an still in the general Site Editor context (basically what we have today) but with the suggestions from above.

Commands with more than one context

We can add more contexts as we flesh this out, say for the Templates view we'd have suggested commands for Adding a new template and Managing all templates, which would be suggested in this view (though they are also available in the Edit Template view).

[youknowriad]

Do we have any designs/mockups about the context commands within the command center ?

I'm also struggling to define the API to work with context. Do we offer these:

wp.data.dispatch( wp.data.commands ).pushContext( 'Site Editor' ); // Go down (Probably somewhere in the `<Layout />` component)
wp.data.dispatch( wp.data.commands ).pushContext( 'Edit Template' ); // go down (`<Editor />`component when context is edit)
wp.data.dispatch( wp.data.commands ).pullContext( 'Edit Template' ); // go up (`<Editor />`component when context becomes view or unmounts)

and internally keep a tree of contexts.

or do we offer just this:

// This is orchestrated at the highest level (`Layout` component) and the right context is dispatched as the selection and canvas mode change.
wp.data.dispatch( wp.data.commands ).setContext( 'Edit Template' );

cc @mcsf @ntsekouras @mtias

[richtabor]

Do we have any designs/mockups about the context commands within the command center ?

Yup, there's a Figma doc here:

[ntsekouras]

wp.data.dispatch( wp.data.commands ).setContext( 'Edit Template' );

I'm not aware of all the nuances of the API, but the above seems good to me. And probably the context should be an object to pass additional properties that we're going to use in the future.

[youknowriad]

@ntsekouras The downside of that API is that the third party devs can't add their own context unless they know how to restore the right context (duplicate the code we have to orchestrate and choose the right context)

[jameskoster]

I wanted to focus on the actual commands this go around, but recent "context" will be good.

Should we open a separate issue for displaying 'recently edited' shortcuts when editing a page, template, or template part?

[jameskoster]

I'm not sure how useful the "Edit header" shortcuts are when editing a template, given you can already see and click on the template parts via the canvas. Since we want to include shortcuts to X recently edited, the palette is going to get quite large:

What do you think @richtabor ?

[richtabor]

the palette is going to get quite large

I think it's fine to have loads of commands; I'd rather you search for header and see a command to edit the header, than search for it and not find something.

But we need to be cognizant of the commands that are suggested contextually.

[jameskoster]

Sorry I'm not getting my question across properly :)

But we need to be cognizant of the commands that are suggested contextually.

That is what I am talking about. In #50832, an "Edit..." suggestion is included for each template part in the template you're already editing. The question is about how useful this is, given you can already click directly on the template part on the canvas, or select it via list view. It doesn't seem all that helpful to me, and adds quite a lot of noise to the suggestions.

I agree these commands should appear on search.

[jameskoster]

For custom templates / parts, it might be good to include a Rename command.

[annezazu]

Dropping this bug here as work progresses: #51204

[jameskoster]

When editing a post or page, we might consider a "Swap template" command which would surface all $custom templates in a modal. Related: #51347

[annezazu]

Passing on some feedback from the FSE Outreach Program's latest call for testing:

When I search the new reusable block in the Command center, I didn’t find. The new footer template, yes.

In particular, it is odd that you can search for template parts, including custom ones, but not general patterns. As patterns take center stage with the Pattern section, I think we should consider adding this.

[jameskoster]

Another consideration for "Editing a postType": direct access to revisions.

[jameskoster]

Should we surface management actions in site editor sections? IE in Templates you'd see "Add new template", "Manage all templates"? Same for Pages, Patterns, etc.

[annezazu]

As part of the twenty fifth call for testing, adding a command to open list view was suggested, along with a few other ideas:

This also went generally well, but the List View wasn’t showing as an option to open on the Command Palette. Also, maybe something relevant would be the option to search a block name and edit its styles globally (not sure if maybe this was expected to show up as well).

Another suggestion to add List View in:

Toggling the list view from the Editor using the Command palette doesn’t work yet. I’d love to have the same advanced functions everywhere.

[JosVelasco]

I'd love to have a command to open/expand a block's advanced panel settings. It makes sense to open advanced options easily with a command or at least make it available to search for.

[jasmussen]

A good place to start on this one might be to show the current context. We're already showing initial commands based on this context.