Command Palette: Make available on front-end

[flexseth]

What problem does this address?

The command palette is inaccessible from the front end of your WordPress website.

6.9 gloriously shipped with admin access to the command palette.

What is your proposed solution?

I propose making the command palette universal. If the user is logged in and has permissions, they can access it via keyboard shortcut. It would be only accessible via keyboard shortcut.

Do magical things.

There may be discussions on Trac about this, please reference if so.

related to #66648

Expected changelog

Allow command palette access on front-end.

[mtias]

I believe @ellatrix had a prototype of this ready somewhere. One thing that comes to mind is that we probably need to make it optional to disable, or off by default, since it brings a lot of code to the frontend of sites (for logged-in users).

[t-hamano]

There has been some discussion in the past about whether to expose the command palette on the front end. See the discussion started in #58218 (comment).

[ellatrix]

I have a very quick try of this, but there's a few things to decide. For security and CSS/JS isolation, it would be good if we open the command palette in an iframe. Yes, the below screenshot is a transparent full width iframe with the command palette in it, and it loads very quickly since it's just the command palette:

The problem here is that we don't really know what each action could do: does it navigate to an admin page? Then we need to propagate the navigation to the top-level. What's other stuff it could do? Should we limit it to navigate-only actions?

Imo the only alternative would be to load the command palette in shadow DOM 🤔 Not sure if that would work in every kind of site setup though (like admin and front-end on different domains where there needs to be separation).

[flexseth]

@ellatrix - Thanks for the perspective, and @mtias.. The Architect, of course!

Mindset

Command jump takes you to valuable places, but doesn't slow you down.

Mitigate page load from DB queries and JS. Commands should be need to know.

Caveats

Back and front-end contexts are different in terms of what is already available, data wise.

Possible solution? Settings page

Maybe there could be a settings page for the command palette, ideally with some representation of how much page load by each searchable entity. Some type of sanity check as you start adding a lot of options that you may not need to search for.

Sanity check

Loading a lot of commands can slow down your site. Consider selecting the options you need most.

Then when the user adds a checkbox, it shows stress. In an intuitive way (could be a future feature)

Settings Page: Gutenberg experimental > Command Palette

• ☑️ Allow command palette on the front-end
• ☑️ Customize commands to increase page speed
• ☑️ Commands listed by use case
• ☑️ Select All by taxonomy (warning, increases page load)

Each checkbox hooks or unhooks commands.

What about the overhead

Does object caching help with front-end load?

Use cases of commands to disable

• Jump to raw theme or plugin file editor
• Create a new cron event
• Delete a user account

Disclaimer

I have not used the command palette much as I don't do a lot of publishing. It seems super promising, though.