Toolbar component update: September 2021

19 tickets closed during the 5.8 cycle, and some of the remaining bugs are already in the 5.9 milestone.

So what else should happen soon? To help set priorities for upcoming releases, please check out the groups of open tickets below. Hopefully you’ll find a ticketticket Created for both bug reports and feature development on the bug tracker. that interests you.

Content and arrangement

The first two tickets here suggest a long-term direction for the toolbar content and the order of links.

• Audit toolbar links and content: includes exploration in the now-inactive Toolbar Experiments pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
• Rearrange top-level toolbar items to make more sense with full-site editing.

These four are potential short-term enhancements.

• Arrange links in New Content menu according to menu_position.
• Combine profile links in Howdy dropdown (or have one of the links direct to a different page).
• Add a Plugins link for administrators.
• Add a New Site link for networknetwork (versus site, blog) installations.

Showing the right elements in the right context

• Remove the dynamic class on front end so page caching does not save the mobile version.
• Show toolbar in the user’s locale on the front end. That might mean fixing #41305 first.
• Show a View Post link after publishing—but before refreshing the page—with the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.
• Show the View Post link at mobile sizes, the way the Edit Post link shows on the front end.
• Show toolbar on Login page if the show_admin_bar filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. is true.

Interactivity

One major proposal is replacing the hover interaction for expanding dropdown menus so that would require intentional clicking (or touchscreen tap, Space or Enter key) with JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. enabled. A change this big needs plenty of testing early in a release cycle, and the code is not ready for that yet.

Ultimately, a good implementation of this could keep users from accidentally opening the profile dropdown when they navigate near the Publish button. And it could fix up to three reported bugs:

• keyboard accessibility (which might have a quick-fix option),
• touchscreen usability for the “My Sites” dropdown, and/or
• iOS double tap traps.

Two tickets address long dropdown menus:

• Access unlimited sites in “My Sites” menu, either by fetching groups or by filtering a long list.
• Add ability to scroll through any long dropdown menus (mostly CSSCSS Cascading Style Sheets.).

Other potential fixes and improvements can help the user experience.

• Add scroll padding to make sure HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. anchors are not hidden behind the toolbar, either in the adminadmin (and super admin) or on the front end.
• Disable dropdown menu expansion when the user drags items on admin screens (which also involves the side admin navigation).
• Convert the Search form to a dropdown instead of stretching wider.
• Make the toolbar fixed on mobile so it does not require scrolling to the top.

CSS-focused changes

The first three CSS tickets below are bugs.

• Adjust top-level links to avoid wrapping onto a second line, where they overlap the content area without a background color.
• Adjust front-end mobile styles for themes with relative position on body element and/or full-height layouts (which may be solved by keeping the toolbar at the top).
• Fix color for plugin-added elements on the front end.

These three are enhancements.

• Simplify CSS. With fewer repeated rules, the files get smaller and easier to read.
• Show WordPress About and Updates links on mobile as long as they can fit.
• Consider using the admin-bar height variable in core in the future. The CSS custom property ticket is committed, so that should be available for themes in 5.9.

Developer-focused features

• Dehook toolbar entirely with show_admin_bar( false ).
• Allow adding data attributes to menu items, or make the attributes less restrictive.
• Add error handling for “Call to a member function add_node() on string” (add_node should return an object).

Options/preferences

• Remove option to view site without the toolbar, and make it show on front end for everyone (unless the filter removes it).
• Add options to help users reduce clutter, or make it easier for plugins to do that.

Props to @marybaum for reviewing and editing this post, plus @sergeybiryukov for reviewing it.

#toolbar