![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 2 months ago
Last modified 3 weeks ago
#65308 new enhancement
Toolbar: keep plugin-added nodes reachable on every viewport
| Reported by: | lucasmdo | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Toolbar | Version: | |
| Severity: | normal | Keywords: | needs-design-feedback 2nd-opinion has-screenshots |
| Cc: | Focuses: | ui, accessibility, javascript, css, administration, ui-copy |
Description
Problem
The WordPress admin bar (#wpadminbar) crowds quickly at narrow viewports. When several plugins each register a top-level node via admin_bar_menu, those nodes collide with the right-side items, get clipped behind the right edge, or stop responding to clicks on mobile widths — exactly the cohort that most needs quick access.
Concretely:
- At desktop widths between roughly 783px and ~1100px (depending on how many plugin nodes are present), plugin-added top-level nodes start disappearing under the right-side area (
#wp-admin-bar-top-secondary).
- At tablet and mobile widths (≤782px), most plugin-added nodes are hidden by the existing responsive CSS, with no fallback path to reach them.
Today this is treated as a per-plugin problem (each plugin should "be responsive"), but the constraint is structural: the toolbar is a horizontal strip with fixed-width right-side items and an unbounded number of plugin-registered left-side items. No amount of per-plugin CSS recovers a node that has been pushed off-screen by the next plugin in the stack.
Prior related discussion: 26430, 22059, 28983.
Proposed enhancement
Provide a Core-rendered overflow path for plugin-added top-level admin-bar nodes:
- At narrow desktop widths, plugin-added top-level nodes that no longer fit overflow into a right-side
'''Plugins'''dropdown. - At tablet and mobile widths, all plugin-added top-level nodes live under that dropdown unconditionally.
- Core-owned nodes (
my-account,site-name,comments,new-content,search,updates,customize,edit,wp-logo,my-sites, etc.) remain in their current positions.
The dropdown is similar to a standard WP_Admin_Bar top-level node with children — the same nested-menu pattern Multisite already uses for my-sites. I believe no new rendering primitive is required.
Reference implementation
A working reference plugin is available at WordPress/wp-admin-bar-overflow (GPL-2.0+). It implements the full pattern on top of current Core with no Core changes — entirely as an overlay using existing filters — so the user experience can be reviewed today without a build.
Easiest way to try it: the WordPress Playground demo linked from the repo README boots a preconfigured site in the browser.
Recommended way to evaluate it: install the plugin on a real WordPress site that already has several plugins registering admin-bar nodes (e.g. Query Monitor, Yoast SEO, WooCommerce, Jetpack, an SEO plugin, a caching plugin). The pattern's value is most visible when the toolbar is genuinely crowded by third-party nodes — that's where the overflow behavior, mirroring, and mobile grouping make the difference between reachable and unreachable plugin UI. Reviewing on a near-empty site understates the problem the ticket is trying to solve.
Architecture, filter API, and host-adapter notes live in the repo's docs/ directory for anyone evaluating an in-Core implementation.
Rationale
Why this belongs in Core, not (only) a plugin:
- The constraint is structural. The toolbar is owned by Core; no individual plugin can know what other plugins have added or how much horizontal space remains. Only Core can arbitrate.
- Mobile parity. Today, plugin-added nodes are effectively unreachable on mobile for the majority of WordPress users. Plugins that put critical information in the toolbar (e.g., Query Monitor's error counters, e-commerce order badges) lose that signal on the device class where it's often most useful.
- Backward compatibility for plugin authors. Plugins keep registering nodes the same way; original DOM positions and IDs are preserved. No plugin code change is required for the existing behavior to be usable on narrow viewports.
Backward compatibility
Additive. The change introduces a new top-level plugins (or similarly-named) admin-bar node owned by Core and adds two filter hooks. Existing plugin registrations via admin_bar_menu are not modified. Original nodes remain in the DOM at their registered positions; mirrored entries in the overflow dropdown forward clicks to the originals so click-handlers bound to specific node IDs continue to work.
Sites that prefer the current behavior can opt out via the proposed admin_bar_overflow_enabled filter.
Reddit post: https://www.reddit.com/r/Wordpress/comments/1tju3yw/admin_bar_keeping_plugin_items_reachable_on_every/