Add command palette entry point to admin bar/toolbar

[annezazu]

While on the Product Review call for 7.0 with Matt ​https://make.wordpress.org/core/2026/02/18/wordpress-7-0-product-review-meeting-with-matt/ (recording incoming), he mentioned wanting a way to better surface that the command palette is available everywhere and asked that this be added to 7.0. With the 24 hour delay and the small nature of this change, let's get this in.

For now, to keep it simple based on the feedback on the call, here are two "designs" using the command palette symbol in the site editor and adding it to the toolbar ​https://cloudup.com/cIiLlrqm_dE & ​https://cloudup.com/ciCl2upQrnI with different placements.

[annezazu]

A diversity of different ideas for design approaches for command palette

[annezazu]

Individual command palette view in the admin toolbar that uses the same light grey as the icons.

[annezazu]

I've been exploring a few different design options shown above and am landing more closely on the placement and approach of the individual style shown above. It feels closest to what we show in the Site Editor already (just ⌘K on a white background) so it will be familiar and it matches the coloring of the icons, which feels more accurate for communicating it as a keyboard shortcut.

[wildworks]

Note that the ⌘ key is Mac-specific and not available on Windows. On Windows, we can launch the command palette with Ctrl+K. This symbol has also been removed from the visual assets in the 6.9 release. ​https://github.com/WordPress/gutenberg/issues/71818#issuecomment-3515409477

This PR adds a button to invoke the command palette from the admin bar. The button label renders the symbolic "Command K" for Mac and "Ctrl+K" on all other platforms.

@annezazu mentioned the possibility of using AI and Playground for addressing this ticket, and we gave it a shot with Claude. It took some correction, but the result seems simple enough. I'm not sure whether the hotkey text should be translatable but guess it does not.

Trac ticket: https://core.trac.wordpress.org/ticket/64672

## Use of AI Tools

This patch was generated using Claude Code with a few manual changes.

[wildworks]

I haven't created a core backport PR yet, but I have created a Gutenberg PR for now. I'd appreciate any feedback.

​https://github.com/WordPress/gutenberg/pull/75757

[bpayton]

Thanks, @wildworks, it makes more sense for this change to live with the command palette itself, as it does in your PR.

[annezazu]

Noting that I got some brief feedback from Matt that he's looking for it to be more like a search bar, similar to what you see in slack. Going to have to rely on someone else for the design at this point but I'll attach another design idea to keep things moving in the right direction.

[annezazu]

Command palette entry point that operates more like a search bar

[wildworks]

he's looking for it to be more like a search bar, similar to what you see in slack.

I guess he wants Command Palette to appear not "modally", but rather in some kind of dropdown directly below that search bar? Unfortunately, ​Command Palette is always rendered via a modal, so if we want to render it in any other context, we may need to create a new component. cc @youknowriad

[westonruter]

Rendering the command palette as a wide search bar will definitely cause existing admin bar items to overflow, as they often do already. So we'll need to prioritize #28983 as well. As I ​commented on Slack:

Related to adding the command palette to the admin bar discussed just now in the ​product review meeting, there is this ticket #28983 to fix issues with too many items in the admin bar getting reflowed onto another line. Assuming we'll want to force the command palette to always be displayed in a prime position, this will result in existing items increasingly pushed out of view. If we don't forcibly remove them, then they will wrap. There seems to need to be a way to have an overflow mechanism (e.g. Priority+) where items that don't fit get displayed in a dropdown.

[audrasjb]

WP 7.0 pre-beta1 Triage:
Unfortunately this enhancement didn't make it before beta 1 code freeze. Thus, let's move it to milestone 7.1.

[pablohoneyhoney]

Comd+K in the omnibar

[pablohoneyhoney]

Sorry, I uploaded the image without context (thanks Trac :)). Left a few permutations on how the field can appear in the omnibar (desktop, as ), with different positions and widths.

• My personal preference is to align it right, when centered the whole omnibar feels unbalanced to me, even more when functions/plugins add their UIs.
• I understand the connection with the editor's, they belong to a different material though.
• Eventually I can this CmdK absorbing more functions, cleaning some of the UIs (ie. New, Help, or a potential site switcher).

Hope this helps, happy to provide specs as needed to include it on time for 7.0 if that's still on the table.
And can follow up as well with iterations of the rest of the omnibar to progress it to a more modern look and behavior.

[matt]

448 centered feels good. It gives us the most flexibility and the opportunity to have a Chrome-like experience in the future.

Thank you, everyone, for your feedback on this. Let's close this in favor of ​https://github.com/WordPress/gutenberg/pull/75757 which appears to be better and getting more focus from its author.

[wildworks]

Let's move the milestone back to 7.0 and see if we can ship this feature in 7.0.

Replying to westonruter:

Rendering the command palette as a wide search bar will definitely cause existing admin bar items to overflow, as they often do already. So we'll need to prioritize #28983 as well. As I ​commented on Slack:

Related to adding the command palette to the admin bar discussed just now in the ​product review meeting, there is this ticket #28983 to fix issues with too many items in the admin bar getting reflowed onto another line. Assuming we'll want to force the command palette to always be displayed in a prime position, this will result in existing items increasingly pushed out of view. If we don't forcibly remove them, then they will wrap. There seems to need to be a way to have an overflow mechanism (e.g. Priority+) where items that don't fit get displayed in a dropdown.

We need to consider how to address this issue.

Furthermore, it's not easy to "visually" center the search bar, as various elements can be injected into the admin bar by consumers.

@brandonpayton, ​https://github.com/WordPress/gutenberg/pull/75757 is required for the Gutenberg plugin and client-side processing, but it is not automatically included in WordPress core. Therefore, PHP code, i.e. server-side processing, basically requires submitting patches directly to WordPress core.

It looks like this PR can't be reopened so I'll submit a new one, but thank you for your efforts!

Trac ticket: https://core.trac.wordpress.org/ticket/64672

## Use of AI Tools

This PR is to backport ​https://github.com/WordPress/gutenberg/pull/75757 into core and does not use any AI tools.

[wildworks]

If you'd like to test this feature, please test the ​Gutenberg PR instead of the ​core PR. The core PR doesn't yet have any client-side processing, so it won't fully work.

You can test the Gutenberg PR directly via the following link:
​https://playground.wordpress.net/?gutenberg-pr=75757&wp=beta

I’ve gone through the updated view, and it looks really good. The changes feel thoughtful and user-friendly. I believe this enhancement will benefit a wide range of users. Thanks for the great work!

[wildworks]

Since the admin bar can easily have items added by plugins, it's often difficult to center the search bar. What do you think about injecting the search bar while keeping the items left-aligned instead? I would like to attach a screenshot.

[wildworks]

Admin bar screenshots. In the image below, I'm experimenting with injecting the admin bar to the left side.

[huzaifaalmesbah]

I think keeping the items left-aligned search bar is a better approach. Since some plugins and themes add items dynamically, so centering can easily break. So left-aligned feels more stable and maintainable long term.

…

Trac ticket: https://core.trac.wordpress.org/ticket/64672

## Use of AI Tools

None

[wildworks]

I've tried the left-aligned search bar version, please let me know what you think.

• Pull reequest: ​https://github.com/WordPress/wordpress-develop/pull/11108
• Playground: ​https://playground.wordpress.net/wordpress.html?pr=11108

[wildworks]

Left-aligned search bar version. How it looks in each color theme

[westonruter]

IMO, it feels a bit strange that there is this persistent search bar appearing in the admin bar, but when you click it, it opens another search bar in a modal. Contrast this with the search 🔍 icon that appears in the admin bar on the frontend. Clicking that search (🔍) icon causes a search bar to expand into view out from the icon. The command palette mocked here appears similar to this except that it is pre-expanded, but it behaves differently. To me it seems like the 🔍 from the frontend could possibly be implemented in the admin as the command palette (and that eventually 🔍 on the frontend could also open the command palette).

In this way, in the admin when you click on 🔍 it could cause the modal to pop-over instead of expanding the search input field.

In the admin (and on the frontend) perhaps instead of "🔍" the shortcut key ("⌘K") could be displayed instead.

In my opinion, we should move ahead with whatever we have now for Beta 3, even if there's still design changes needed. We can always do some CSS tweaks in follow-ups and have people attempt to centre it, and at least the main functionality is in.

It looks like this PR can't be reopened so I'll submit a new one, but thank you for your efforts!

Thank you, @t-hamano!

In my opinion, we should move ahead with whatever we have now for Beta 3, even if there's still design changes needed. We can always do some CSS tweaks in follow-ups and have people attempt to centre it, and at least the main functionality is in.

I agree. If we start small, I think a button would have less impact than a search bar. What do you think?

​https://github.com/WordPress/wordpress-develop/pull/11063

[pablohoneyhoney]

Nice reference from @wildworks, works well color-wise, adjusting to themes. And good point from @westonruter: this connects to some smaller UI options I had above, but making it more prominent feels right now — like in the editor itself, and across other experiences like Slack, browsers, etc. — to teach the UX behavior at a meta level.

Rather than stressing over perfect centering (the bar adapts across UI contexts, and plugins will inevitably break precise positioning anyway), I'd lean into making it front-and-center in the bar by design, owning that prominence intentionally.

Longer term (hoping not so long), I can see this UI absorbing other functions that currently have visual presence elsewhere, and eventually becoming intelligent and contextual.

[westonruter]

Re-using wp_admin_bar_search_menu() in admin for command palette

[westonruter]

To visualize what I had in mind in my comment, see search-admin-bar-item-in-admin.mp4​. This is the existing admin menu item which is already added to the toolbar on the frontend via wp_admin_bar_search_menu(). It's just that here it doesn't short-circuit if is_admin(), and in place of showing the search input field on focus it shows the command palette instead.

Adds a node to the admin toolbar to open the Command Palette. It uses the same magnifying glass icon from the Search form, in the same place.

Trac 64672

Use of AI Tools: None (by me)

[westonruter]

Just realized that MacOS also has the 🔍 icon in a similar place in its Menu Bar. Clicking it opens Spotlight Search, very similar to the Command Palette UI.

[westonruter]

Also: What about on mobile? I don't see any mocks for what that would look like. For the search menu item on the frontend, the 🔍 is hidden on mobile, but I think that maybe due to the way it causes the search input field to expand in the admin menu. However, if tapping on the 🔍 icon causes the Command Palette to open instead, then there wouldn't be a need to hide it.

[westonruter]

See admin-bar-search-command-palette-on-mobile.mp4​ for how the Command Palette could be made available on mobile via a 🔍 menu item.

As per this comment, this would also enable the Command Palette to be made available to mobile form factors.

[wildworks]

Please note that there are currently three versions proposed.

• Left aligned search bar: ​https://github.com/WordPress/wordpress-develop/pull/11108
• Left aligned shortcut button: ​https://github.com/WordPress/wordpress-develop/pull/11063
• Right-aligned search button: ​https://github.com/WordPress/wordpress-develop/pull/11160

I added a screengrab to the description.

Also, suggested patch to show the search icon on mobile:

src/wp-includes/css/admin-bar.css

@@ -1031 +1031 @@
         #wpadminbar li#wp-admin-bar-new-content,
         #wpadminbar li#wp-admin-bar-edit,
         #wpadminbar li#wp-admin-bar-comments,
-        #wpadminbar li#wp-admin-bar-my-account {
+        #wpadminbar li#wp-admin-bar-my-account,
+        #wpadminbar li#wp-admin-bar-command-palette {
                 display: block;
         }

It would be nice to promote the ⌘K/^K shortcut somehow as well so a user can learn they don't have to actually click on 🔍 to open the Command Palette.

One concern with this PR approach might be the duplication of the search bar that triggers the command palette when the editor is opened.

Trac: https://core.trac.wordpress.org/ticket/64672

## Summary

Follow-up to #11108. Makes the command palette trigger a native admin bar group element instead of a regular node in root-default, as ​suggested in review.

• Registers command-palette as its own group under root using add_group(), with the trigger node inside it — this produces a sibling <ul> to root-default and top-secondary
• Converts .quicklinks to display: flex so the three groups lay out naturally: left items, centered command palette, right items
• Both side groups use flex: 1 1 0; min-width: fit-content — equal space when the viewport is wide (perfect centering), but they won't shrink below their content on narrow viewports
• Command palette group uses flex: 0 0 auto between them

Existing float declarations on <li> elements become harmless (floats are ignored on flex items per CSS spec).

## Alternative approach

An alternative would be to bypass the node/group API entirely and render the command palette directly in WP_Admin_Bar::_render() as a standalone <button> element — a sibling to the <ul> groups inside .quicklinks. This would give full control over the markup (semantic <button> instead of <a> inside <li> inside <ul>), but requires modifying class-wp-admin-bar.php and hardcoding the element into the admin bar's render method. The group-based approach here is more straightforward since it reuses the existing API and keeps all the command palette logic in admin-bar.php.

## Test plan

• [ ] Load any wp-admin page: command palette button should appear centered in the admin bar
• [ ] Click it: should open the command palette
• [ ] Check front-end pages: button should NOT appear
• [ ] Resize viewport — left group should push the command palette rightward rather than shrinking
• [ ] Test RTL layout
• [ ] Test mobile viewport (admin bar collapse behavior)
• [ ] Test different color schemes (modern, default)

🤖 Generated with ​Claude Code

[ellatrix]

^ Tried centering through a new top-level group building on Aki's previous work: ​https://github.com/WordPress/wordpress-develop/pull/11171

So the command palette is not accessible on mobile. Why shouldn't it be?

It's the same as #11108, I don't think I changed anything there. I guess it will have to be added explicitly to the mobile version of the admin bar

With several plugins installed, the search bar may become misaligned:

I think that's fine, it still looks ok?

When I open the editor, you may find the search bar overlapping, which can be a bit confusing:

What o you mean here? What overlaps what?

Personally, I think going with ​https://github.com/WordPress/wordpress-develop/pull/11160 might have the least impact. What do you think? cc @sabernhardt

Would need approval from design

Something that looks like an input/search field but isn't one feels wrong.

When I open the editor, you may find the search bar overlapping, which can be a bit confusing:

What o you mean here? What overlaps what?

They're not overlapping, but there are two of these bars right next to each other.

What overlaps what?

I was referring to these two places. There are two search bars close to each other that both trigger the command palette.

@t-hamano Isn't that a problem in your PR too? How has it been addressed elsewhere? Or is there a proposal to unify them.

Something that looks like an input/search field but isn't one feels wrong.

@ocean90 It's the same for the editor document bar 🙂

Isn't that a problem in your PR too? How has it been addressed elsewhere?

Two approaches have been proposed that do not use a search bar in the first place.

• ​https://github.com/WordPress/wordpress-develop/pull/11160
• ​https://github.com/WordPress/wordpress-develop/pull/11063

[matveb]

Regardless of the visual treatment we land on, we should probably remove the Ctrl/Command+K display from the editor header when full screen mode is off. It doesn't make much sense to duplicate the same functionality in such close proximity.

Personally, I think going with ​https://github.com/WordPress/wordpress-develop/pull/11160 might have the least impact. What do you think?

Chatting with @mtias about this and a more condensed command‑K control is okay for beta 3 if needed, rather than the search icon. The search icon alone is not enough.

Here's a couple screen recordings with the latest changes:

# Desktop

​https://github.com/user-attachments/assets/967b30d0-31a6-45fc-8b22-bfd3ff397e34

# Mobile

​https://github.com/user-attachments/assets/111df8fa-f44a-4b3b-8706-e251ae4be5d2

Let's land this ahead of the next beta so we can get more testing. Previously, the smaller command‑K control would have worked to get an initial version in to a prior beta but, at this point, it's important we stick with the design and project leadership direction.

This looks good. Please land this so we have time to test sooner rather than later.

[ellatrix]

In 61912:

Toolbar: Add command palette trigger button.

Props wildworks, hmbashar, bpayton, mcsf, joedolson, sabernhardt, westonruter.
See #64672.

I committed this. Forgot to link this PR in the commit message: https://core.trac.wordpress.org/changeset/61912.

Trac ticket: https://core.trac.wordpress.org/ticket/64672

This adds adds the Command Palette admin bar items to the allowlist of items which are shown on mobile:

​https://github.com/user-attachments/assets/56f7c6dd-099a-4dc7-a32e-9a49d1443879

This applies suggestions from @sabernhardt's PR ​https://github.com/WordPress/wordpress-develop/pull/11160 to follow up to the admin bar item added in r61912.

## Use of AI Tools

None

[westonruter]

Follow-up suggestion to show admin bar item on mobile viewports: ​https://github.com/WordPress/wordpress-develop/pull/11222

I'd like to close this PR as #11063 has been commited

[westonruter]

In 61979:

Toolbar: Show command palette admin bar item on mobile.

• The keyboard shortcut is hidden in favor of a search icon on mobile.
• The background color of the KBD element is made transparent on non-mobile.
• The admin bar item is skipped from being added if the wp-core-commands script is not enqueued.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/11222

Follow-up to r61912.

Props sabernhardt, westonruter, ellatrix, mukesh27.
See #64672.

Committed in r61979 (019eeb8)

[siliconforks]

I just noticed this new feature while running WordPress 7.0-beta5 on a desktop machine. I see that it simply displays "Ctrl+K" in the top bar. Isn't that a bit confusing? I would assume that means that pressing Ctrl+K is equivalent to clicking on it, but shouldn't there be some indication as to what it actually does? Does it ... delete the entire site? How is the user supposed to know?

I see in the discussion above that some people objected to using a search bar:

IMO, it feels a bit strange that there is this persistent search bar appearing in the admin bar, but when you click it, it opens another search bar in a modal.

Personally I agree that it seems a bit odd, but that is the UI convention that everyone is using these days. (See ​https://www.php.net/ or ​https://laravel.com/ for examples of this.) It is probably a good idea for WordPress to follow that convention too. It is certainly less confusing than just having "Ctrl+K" sitting there with no additional explanation or surrounding context.

[westonruter]

Search icon appearing before keyboard shortcut

[westonruter]

Replying to siliconforks:

I just noticed this new feature while running WordPress 7.0-beta5 on a desktop machine. I see that it simply displays "Ctrl+K" in the top bar. Isn't that a bit confusing? I would assume that means that pressing Ctrl+K is equivalent to clicking on it, but shouldn't there be some indication as to what it actually does? Does it ... delete the entire site? How is the user supposed to know?

What about prefixing the 🔍 icon to the keyboard shortcut? This is what @sabernhardt had ​in his PR (although with the admin bar item on the far right, which is where the search item is located on the frontend). See search-icon-with-keyboard-shortcut.png​.

[siliconforks]

Replying to westonruter:

What about prefixing the 🔍 icon to the keyboard shortcut?

Yes, that would definitely be an improvement.

[wildworks]

What about prefixing the 🔍 icon to the keyboard shortcut?

+1