Specifically, we need to talk about the administrator menus in WordPress.

Activate a plugin and you may find yourself bombarded with admin messages (some dismissible and some not), feature pointers, new menus of all hues and some even divert the installation process immediately to their own screens. Some of these interrupt any bulk activation process too, preventing other plugins – temporarily – from activating.

Over a series of posts, I’m going to look at just one of these – the menus – and explain what’s going on, why they’re so wrong, and bombard you with that thing that politicians hate: facts.

I installed and activated 109 plugins on a test site – they were a combination of the most downloaded plugins, along with a few that are currently being recommended on WordPress.org, along with a handful of block plugins (when we get to talking about them, you’ll understand why). And, yes, I may work for Automattic but plugins such as Jetpack and WooCommerce are included. The aim was to see just what your average plugin does when it comes to admin menus.

First, let’s look at a good example (or bad example, depending on how you look at it) of the state of plugin menus. The Stackable plugin adds this menu…

There is not a SINGLE sub-menu option here that needs to exist – in fact, that entire main menu item should not be there. But it is.

Over these posts, I’ll explain why – please revisit this one you’ve read through and, I hope, you’ll appreciate why, to me, this is like nails on a blackboard.

Menus everywhere

Let’s start with a statistic…

That’s quite a figure. So, for every 5 plugins you add to your site, you’re likely to have 3 more menus appear in WP Admin. That nice, clear, clutter-free experience isn’t going to last long.

Yet, by my own reckoning (and I’ll get to how I do this later), over a third of these shouldn’t exist.

I mean, it could be worse.

The new breed of block plugin is even worse. And I estimate that over half of these simply shouldn’t be there.

Promoting the brand

Most of the hideousness found in these menus is down to a company or individual trying to promote the premium versions of their plugins – hiding your plugin away a sub-menu doesn’t help it stand out. In addition, you want to use the free plugin to help promote it, so adding sub-menu options for that purpose is pretty standard – 36% of those that add a menu, add a promotional sub-menu.

Here’s All in One SEO, as an example…

Above the obvious “Upgrade to Pro” option, is “About Us”, which is also promotional. Do we need links, directly in the menu, to learn about the developer?

And there’s UltraBlocks. When installed, it shows an identical menu for both the free and pro versions of the plugin. However, both have identical links, so click on “Settings” in the free menu and it opens up both menus and highlights it in both…

I’m hoping this is a bug, so I’ve reported it to the developers. But, I’m suspicious that it isn’t and, again, is a way for them to promote the premium version of the plugin (although presenting what appears to be a bug doesn’t inspire me to buy!).

What’s wrong with a splash of colour?

A lot of plugins use colour on at least one of their sub-menu options. Some even use it for the menu icon.

But, please don’t. They are really, really bad for accessibility.

Although not widely used, it’s possible to change the colour scheme for WP Admin – this is great for people with colour blindness or site issues of any kind. When you change the scheme it changes all the colours used on the menu – unless, of course, you’ve overridden it with your own. The same goes for icons.

Here’s a couple of examples – the first of a menu option that can be barely seen and another of an icon. These were both visible until I changed the colour scheme…

16% of plugins that add their own main-menu option, add a coloured icon.

Icons everywhere

How about icons being used on a sub-menu? Caldera Forms, for reasons I don’t understand, feels the need to do this, despite no-one else doing so. It makes the whole thing look cluttered.

What’s in a name?

I’m not even sure why plugins do this, but some give themselves a menu name that doesn’t actual relate to the plugin that they’re about.

The best example of this is SeedProd. That’s the name of their company but their plugin is to do with adding a Maintenance Mode for WordPress, although they’ve called it ‘Coming Soon‘. So, naturally, their menu is named ‘SeedProd’. Bafflingly confusing.

Setting and tools

Many plugin menus contain sub-menu options named “Settings” and “Tools”. Which, to my mind, is bizarre – there are already two menus called that under which they should sit – why don’t they?

11% had a menu named “Tools”.

Many plugins actually have no sub-menus and the main menu simply leads to a settings screen.

To Top is an example of this. With limited real-estate on screen for primary menus before it becomes over-cluttered, it makes no sense that this takes up a slot of the side, particularly when it’s for settings that many people will visit once, at most.

Let’s look at Monster Insights, as an example…

There are 3 sub-menus here – “Settings” and “Tools” could both go under their respective main menus. “Addons” is purely promotional (and is coloured too). I’d go so far to suggest that the first two have only been added here to justify that third one.

Room at the top

To my mind, positioning is important – a lot of thought has gone into how the default menus are positioned, with the dashboard overview at the top, followed by posts, media, etc. – they’re the most important, right?

Yet, 4 of the plugins I tested push themselves to being under Dashboard, somehow feeling they’re more important. None of them are.

What are we trying to resolve here?

So, to summarise – what the issues that these menus are causing? Other than offending my OCD and sense of taste.

• Accessibility issues
• Pollution of the menu structure, making it difficult to find items in an ever-increasing menu
• Confusion over where to expect to find menu items

What’s the solution?

Longer term, we need to get better at this – either through a voluntary scheme or enforced guidelines. First of all, an end-to-end API solution for menus will help, as it can help to guide and control the addition of menus, enforcing a particular structure and standard.

Maybe Calypso will help.

“Wait. What’s Calypso?”

Calypso is an open source back-end for WordPress that uses React (the same as the Gutenberg editor and the Customizer). It’s currently in use by WordPress.com but I can imagine that this, or something similar, may be the future for WordPress. If so, a step-change will need to occur to get the current menus to work with this – right now, it requires recoding of any plugins but if this ever became part of core, I can’t imagine there being such an appetite so will lead to an solution, where existing calls to add menus will filter through a new API that will convert them to React equivalents. This will then allow a more structured implementation to occur.

Maybe. That’s all a lot of ifs/buts.

Right now, nothing covers any of this in the WordPress coding standards and, if I’m honest, I don’t expect they ever will. The standards do not generally dictate to this level and, even if they did, this would only apply to new plugins – anything existing would be highly likely to be exempt.

What is clear, though, is that something needs to happen.

Shorter term, I have a solution. Indeed, the stats from these posts came from my own investigation into this solution. A plugin that will force structure changes to the menu, looking for all of the issues that I’ve written about and attempt to correct them. Named Bazalgette, work is already under way.

Unfortunately, as much as this will be able to do, there’s a lot it won’t be able to. It’s almost impossible, at times, to interpret the purposes of some sub-menus. For example, if a menu has no sub-menu options, it’s often the case that the only link is one to the plugin’s settings. But not always. But here is what it can do (although all will be optional and switchable)…

• Move Settings and Tools sub-menus to the appropriate named menus (they will then be renamed after the plugin)
• If the main menu doesn’t match the plugin name, it will be renamed
• Colour removed from menu names and non-coloured SVG icons used for all menus
• Remove all promotional menus (“About us”, “Contact us”, affiliate and anything selling premium features)
• Move down any menus pushing themselves to the top
• Documentation links sent to their own top level menu
• If, after all the above, there are no sub-menus left, remove the main menu

If anybody would like to get involved, all code is GPL and in Github.