Add command palette trigger button to admin bar (Left-aligned search bar version)#11108
Add command palette trigger button to admin bar (Left-aligned search bar version)#11108t-hamano wants to merge 2 commits intoWordPress:trunkfrom
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
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? |
| 'href' => '#', | ||
| 'meta' => array( | ||
| 'class' => 'hide-if-no-js', | ||
| 'onclick' => 'wp.data.dispatch( "core/commands" ).open(); return false;', |
There was a problem hiding this comment.
I assume return false is the preventDefault signal. If so, can we comment to make it clear?
There was a problem hiding this comment.
A behaviour I'm noticing:
- Go to a WP-Admin that's taller than the viewport (e.g. Themes, User > Profile)
- Click on the element to bring up the search bar/dialog
- Click anywhere else to dismiss it
- Observed: browser scrolls to bottom
There was a problem hiding this comment.
- Go to a WP-Admin that's taller than the viewport (e.g. Themes, User > Profile)
- Click on the element to bring up the search bar/dialog
- Click anywhere else to dismiss it
- Observed: browser scrolls to bottom
I can't confirm this behavior in my environment 🤔
c68bdd8b9d2a1e020d1f748df8cbefd3.mp4
| return; | ||
| } | ||
|
|
||
| $is_apple_os = (bool) preg_match( '/Macintosh|Mac OS X|Mac_PowerPC/i', $_SERVER['HTTP_USER_AGENT'] ?? '' ); |
There was a problem hiding this comment.
Where was this pattern sourced? From WP itself? I'm trying to determine how reliable it is and whether the source should be cited.
There was a problem hiding this comment.
Neither WordPress nor Gutenberg has any code to detect the OS on the server side. I used this source as a reference to come up with the logic. There may be a better approach.
| } | ||
|
|
||
| #wpadminbar #wp-admin-bar-command-palette .ab-item { | ||
| width: 200px; |
There was a problem hiding this comment.
Given the layout constraints (use of floats, etc.) of the admin bar, what would it take to achieve a button that tries to take up 443px unless there isn't enough room for other items?
There was a problem hiding this comment.
To achieve this, we'll probably need to flex the entire admin bar.
There was a problem hiding this comment.
I suspect that shifting the admin bar to a fully flex layout would cause a lot of extender issues. Feels pretty risky this late.
There was a problem hiding this comment.
That's true, switching to flex layout now is risky and requires more careful discussion. Related discussions can be found here: https://core.trac.wordpress.org/ticket/28983
There was a problem hiding this comment.
Yeah, Flex was my instinct too, and I share all those concerns.
| /* translators: Hidden accessibility text. */ | ||
| __( 'Open command palette' ), | ||
| ); | ||
| $wp_admin_bar->add_node( |
There was a problem hiding this comment.
Posted this comment on the wrong PR:
Rather than adding this as a new node, maybe it should be added natively to the wp admin bar as something fundamentally different than a node? That way it's not constrained to the current structure and maybe makes it easier to centre with CSS.
You say that's difficult, but why? I'm saying that this could be a built-in feature of the admin bar rather than having to be constrained to the current API.
There was a problem hiding this comment.
I believe all the core menus are added via WP_Admin_Bar::add_menus(). Is there a way to add controls to the admin bar without using this API?

Trac ticket: https://core.trac.wordpress.org/ticket/64672
Use of AI Tools
None
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.