[wp-trac] [WordPress Trac] #65308: Toolbar: keep plugin-added nodes reachable on every viewport

[WordPress Trac]

#65308: Toolbar: keep plugin-added nodes reachable on every viewport
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |      Owner:  (none)
     Type:  enhancement              |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  Toolbar                  |    Version:
 Severity:  normal                   |   Keywords:  needs-design-feedback
  Focuses:  ui, accessibility,       |  2nd-opinion has-screenshots
  javascript, css, administration,   |
  ui-copy                            |
-------------------------------------+-------------------------------------
 == 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`).
 [[Image(overflow-before.png)]]


  * 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: [ticket:26430], [ticket:22059], [ticket:28983].


 == Proposed enhancement ==
 Provide a Core-rendered overflow path for plugin-added top-level admin-bar
 nodes:
  1. At narrow desktop widths, plugin-added top-level nodes that no longer
 fit overflow into a right-side `'''Plugins'''` dropdown.
  2. At tablet and mobile widths, all plugin-added top-level nodes live
 under that dropdown unconditionally.
  3. 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.

 [[Image(overflow-after.png)]]

 === Reference implementation ===

 A working reference plugin is available at [https://github.com/WordPress
 /wp-admin-bar-overflow 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.

 == Related tickets ==
  * [ticket:26430] — same problem statement, earlier discussion converged
 on hiding core links rather than introducing an overflow dropdown.
  * [ticket:22059] — broader "make the admin bar responsive" effort.
  * [ticket:28983] — admin-bar length / wrapping at narrow widths.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65308>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform