Keyboard focus order mismatch in adminbar in front-end

[joedolson]

When viewing the Admin bar on the front-end, the search tool is added visually in the far right corner, after the profile menu. In the DOM, however, the search bar is located before the profile menu.

These should be reversed in the DOM so that keyboard order matches visual order.

See r19518.

[sabernhardt]

removes float: right and increases priority number for the Search node

[sabernhardt]

To keep the Search form to the right of other links without the float, the priority would need to change. I chose 20: more than recovery mode's 8, with more than one number in between for anyone who wants to have a link between the "Howdy" account links and the Search icon.

At least two of the plugins that add links to the secondary group have a priority of 999 (see ​directory search), so it may be appropriate to increase the priority more.

[joedolson]

I think the question here is what the intent is for plugins with a higher priority. Previously, with the float in place, it was impossible to add items to the right of the search without also customizing CSS. Now, everything will be ordered according to priority.

While some plugins may need to make changes, I'm not sure that's a significant concern. Nothing will actually break here as a result, a link may just appear in a different place than previously expected.

We could certainly increase the value to provide more space; though it's not strictly necessary - you can have multiple items in a single priority, after all.

Can you specify any of the plugins that have a priority of 999? I browsed those results a bit, but I didn't see them.

I think this is basically ready to commit; the only question is what the ultimate priority level should be. I'm inclined to think that 20 offers enough space, and that moving later doesn't really offer any significant advantages.

[sabernhardt]

Yeah, it is not so easy to search for 'parent' => 'top-secondary' and then to find where that specific node is added with the admin_bar_menu action.

• Jetpack uses 999 for its ​Scan and ​Server Sandbox modules (Jetpack also uses 100 for ​Stats, 120 for ​Notifications and 121 for ​Identity Crisis)
• Starter Templates uses 999 for its ​AI Assistant (available upon activation)
• Website Builder by SeedProd uses 999 for its ​Coming Soon page link (need to activate Coming Soon Mode from Landing Pages)

For some additional priorities:

• EWWW Image Optimizer uses 99 for its ​'Detect Scaled Images' link (with ewww_image_optimizer_resize_detection option)
• Polylang ​replaces the WordPress search at the same priority of 4:

  remove_action( 'admin_bar_menu', 'wp_admin_bar_search_menu', 4 );
  add_action( 'admin_bar_menu', array( $this, 'admin_bar_search_menu' ), 4 );
  

• BuddyPress uses 90 for its ​Notifications dropdown menu
• GiveWP uses 1000 for its ​Test Mode

[joedolson]

Based on those values, with the patch as is, it would result in a change in the adminbar for all of those plugins.

I don't think there's anything we can do about the Polylang switch; we should just add that in a dev note and possible contact them directly with a heads up. It's a trivial change for them to make if needed.

But we can make this work for all of the other plugins, just by deciding that our aim is to have the search item as the last element of the adminbar, and giving it a priority of 9999, which would keep it at the end of the adminbar for the vast majority of cases.

[joedolson]

@sabernhardt I think it would be good to get this in sooner rather than later; what do you think about the proposal to just give it a very high priority?

[sabernhardt]

I'm not sure about 9999, but that is probably a better choice than 20 (or a similarly low number). Maybe it's worth mentioning in the dev chat (agenda) first.

I tried a version-based priority to confirm that plugin authors could change it if they do not like where their links appear:

$special_priority = ( version_compare( $GLOBALS['wp_version'], '6.6-alpha', '>=' ) ) ? 2 : 100;

add_action( 'admin_bar_menu', 'wpadmin_toolbar_test_link', $special_priority );

function wpadmin_toolbar_test_link( $wp_admin_bar ) {
	$wp_admin_bar->add_node(
		array(
			'parent' => 'top-secondary',
			'id'     => 'mylink',
			'href'   => '#',
			'title'  => __( 'My Link' ),
		)
	);
}

[sabernhardt]

sets Search menu priority at 9999

[sabernhardt]

I uploaded a patch to consider the 9999 priority.

[joedolson]

The value of 9999 feels quite arbitrary; but I think that any value here is ultimately pretty arbitrary. It's easy for extenders to get around, and in most cases will have the desired result.

We can run it by a dev chat, but it seems like a somewhat trivial issue to raise in a meeting. If we can just get a second opinion from another committer, I think that would be sufficient.

Pinging @audrasjb as the 6.6 tech lead.

[audrasjb]

Thanks for the ping.
Honestly while this is indeed a arbitrarily high value, I think it makes sense in the context of something that shouldn't be overridden, except on rare contexts. And extenders can always override it if they want. To summary, I'm good with this value.

[joedolson]

Thanks, JB!

With that 2nd opinion, I think this is ready for commit.

[joedolson]

In 58215:

Toolbar: Accessibility: Fix keyboard focus order of search form.

Change the priority of the search form & remove float so that the visual position of the form matches it's positioning in the DOM.

This sets the priority of the search form to an arbitrarily high value of 9999 to ensure it will generally be last in the DOM.

Props joedolson, sabernhardt, audrasjb.
Fixes #60685.

[joedolson]

@sabernhardt Dev note for your review.

In [58215], the search input on the front end admin bar is added at a different priority. It was previously inserted at priority 4, then floated to appear at the end of the admin bar. It is now inserted at priority 9999, to load at the end of the admin bar without CSS manipulation.

Extenders placing admin bar nodes after the search or replacing core search should take the new priority into consideration.

### Assign different priority based on WordPress version

$priority = ( version_compare( $GLOBALS['wp_version'], '6.6', '>=' ) ) ? 4 : 9999;
add_action( 'admin_bar_menu', 'wpadmin_toolbar_test_link', $priority );
/**
 * Add a node to the WP admin toolbar.
 *
 * @param object $wp_admin_bar WP Admin Bar object.
 */
function wpadmin_toolbar_test_link( $wp_admin_bar ) {
	$wp_admin_bar->add_node(
		array(
			'parent' => 'top-secondary',
			'id'     => 'mylink',
			'href'   => '#',
			'title'  => __( 'My Link' ),
		)
	);
}

[sabernhardt]

Thanks for writing the note. It's much easier for me to edit than to write.

A few small notes:

• "Toolbar: Search has a much later priority" is one possible heading.
• I recommend hyphenating "front-end admin bar", especially because the next sentence mentions the end of the admin bar (relating to its order).
• To work in 6.6 alpha/beta/RC, I needed to change the version from 6.6 to 6.6-alpha. It may not make any difference for end users, but extenders may prefer that precision in the example.

[pbiron]

For posterity, here's a link to a comment I made on the Dev Note that covers the changes in this ticket

​https://make.wordpress.org/core/2024/06/25/miscellaneous-developer-changes-in-wordpress-6-6/#comment-46841

[sabernhardt]

Follow-up: #61615