Approximate time to read: 4 minutes
Whilst new rules are sorting out many aspects of WordPress development that causes headaches for users (e.g. standardised admin messaging), how plugins (and, in some cases, themes) allocate menus in WP Admin are not currently covered.
As a result, some developers (and it’s note-worthy that most of those that fall into this category are making a living from their plugin work) are happy to push the level of acceptability.
So, in this article I’m going to demonstrate some of the things that developers will do with their menus and compare that to the standard approach taken by the core version of WordPress.
The default, core menus
First, let’s see how they are in a default set-up of WordPress (which, without any list of regulations, is what we’d expect any modifications to also look like).
- The sequencing of main menu options has been thought through, with core options at the top and a strict sequence after that.
- WordPress uses Dashicons to display monochrome SVG icons before any main menu name. Icons are not used on the sub-menus.
- Like the icons, all menu text is monochrome and should style appropriately, according to any Admin Colour Scheme that is applied (head to Users -> Your Profile to change this).
- Top level menus only exist where there are sub-menu options below it. The one exception to this is ‘Comments’.
- All setting screens should be placed under the ‘Settings’ menu. The same, equally, for any tools screens.
- As an extension of point 5, all menus should be considered – is it even needed and, if so, can it go somewhere else (e.g. something related to media being added under the existing ‘Media’ menu.
And, I’d say, that pretty much covers things off. A pretty short and simple list.
Rules? What rules
As I mentioned in my introduction there are no rules governing how plugins should add menu options. If there was, the likelihood is that they would follow the conventions that I’ve laid down above (some more than others).
Of course, plugin developers who are making money from their work want their plugin to stand out (although, it could be argued that they’ve already installed it, so the majority of the battle has already been won) but annoying their customers with menus that don’t make sense isn’t the way to do it. In the case of the use of colour in icons and menu text, this leads to accessibility issues as well.
The more a plugin looks like something that is built into WordPress by default, the more the customer will trust it – it looks as if it belongs and looks part of the trusted, base core product.
So, what I’m going to do is show a single example of various ways in which plugins, in my opinion, get it wrong. I’m not picking on any in particular but I am looking at the most popular plugins, as well as some that I just happen to use myself.
All-in-One SEO is one of those plugins that pushes itself to the top of your menu, despite it having no place there. Just imagine if all plugins did this and you had to scroll down each time you wanted to add a post.
And, yes, Jetpack is equally guilty of this crime.
Why do these plugins believe they’re more important than, say, adding a post or page?
All-in-One WP Migration uses a coloured icon which is hard to read on certain background colours, becoming an accessibility issue. Here you can see it against a green background.
Coloured menu names
Mailchimp for WordPress have a promotional sub-menu option that’s coloured and on a red background you can barely read it.
I don’t think it’s coincidence that when you find this being applied it’s to premium, promotional pages (I haven’t yet found an occurrence of this where it wasn’t the case).
Anyway, as with the coloured icons, this is an accessibility issue – more so, as it’s text rather than an image.
Confusing menu names
‘WP Security’ is the menu name but their plugin is actually named ‘All In One WP Security & Firewall‘. Would you know they’re the same thing? That’s the worst case I’ve seen but, often, developers will abbreviate their plugin name to make it shorter for the menu. That makes sense. But, to me, it also has to still be relevant (although I would argue that if your plugin name isn’t already short and snappy then you’ve possibly lost half the war already).
It’s a similar case for 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.
Icons on sub-menus
Caldera Forms uses icons for all of its sub-menu options and it looks pretty terrible.
I’ve not come across any other plugin that does this, although I’ve maybe not looked hard enough 😉 It’s odd to find something like this which no-one else seems to be doing – it’s not as if they have the “well, others do it” excuse as a result.
Definitely an example of “less is more”.
To Top adds a primary menu option with no sub-menus. Click on it and it takes you to a settings screen. This is a superb example of something that should have been moved to ‘Settings’ (i.e. go to ‘Settings’ -> ‘To Top’ to access the settings screen).
With limited real-estate on screen for primary menus, 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.
Settings and Tools in the wrong place
The MonsterInsights menu has only 3 sub-menu options – Settings, Tools and Addons. The first two should really be under their respective Settings and Tools menus.
Plugins like this, though, are unlikely to do this as, without those two options, it’s hard to justify that single remaining option, which is there to push their premium add-ons. They could of course add promotional material to those existing screen and, if those add-ons really are exactly that, why not add it under “Plugins”.
The trick that many developers are missing is that when you move these under the “Settings” and “Tools” menu, you name them after your plugin. So, in this case you’d have Settings -> Insights and Tools -> Insights, essentially doubling the references made to the plugin (so, hardly hiding it).
Of all of the issues this is probably the one that you see the most, though, and is the only one that my own plugins are – sometimes – guilty of (but I’m trying to fix that).