WordPress plugins come in literally thousands of shapes and sizes. In my view a good plugin should have an intuitive admin user interface, work properly out of the box, and generally act as an extension of the WordPress installation without drawing attention to the fact that it has been developed separately.
Here’s a list of things that I look for when I have a choice of plugins to use, and that I try to consider when building my own. If you build plugins, take a look and see if you comply, or even agree.
Note: some of the screenshots are taken from ZigEvent, an events calendar plugin currently under development by ZigPress.
If your plugin has admin pages, do your best to make them look and operate as much like the standard WordPress admin pages as possible.
So, if you have an admin page that lets users review and edit many entities (like events in an events calendar for example), why not make it look and work like the admin posts page? This has two advantages: firstly your plugin will be easy to use because it gives consistency to users, and secondly you can make use of the CSS files that are loaded by default, reducing bandwidth requirements and development time.
Unless there is a very good reason why not, all widgets should be multi-widgets. This is easy to achieve by extending the WP_Widget class. All the built-in WordPress widgets can have multiple instances, so users will expect your widget to be the same.
If your plugin has a settings page, it’s quite easy to offer an option for the plugin to delete its options, any database tables and any uploaded files when deactivating.
However, if you provide this feature, make sure you warn the user of the implications of using it, especially if you use the plugin’s options to store usage or other cumulative data.
If your plugin features shortcodes, tell the user what they are somewhere in the Admin UI. This is a timesaver, nothing more, but it will endear your users to you and increase your karma. Or it would, if there was such a thing as karma.
If some folders need to be write-enabled, check that they are when the plugin is activated. If they are not, alert the user so they can correct the problem.
If you publish your plugin in the WordPress plugin repository, you will (hopefully) be aware that there is a specific format that your plugin’s readme file should follow.
There are good reasons for following this format. Recently I went to update the plugin MM Forms Community, and clicked the “View version 1.2 Details” link on the admin plugins page. This opens a lightbox panel with a stripped-down version of the plugin page in the WordPress repository. I clicked the “Changelog” tab to see whether I should bother updating, and was presented with the words “See changelog file”.
Need I say that this is not helpful?
Before I activate a newly-found plugin for the first time, I always check the source code, doing a search for the words “mail” and “google”. It’s amazing how often I find that the plugin author has either set the plugin to send him/her an email on activation, or register an impression on their Google Analytics account. Obviously, any such code gets stripped out before I activate the plugin for the first time. If it then fails to work, it goes in the trash.
If you absolutely need installed copies of your plugin to exchange data with a remote server, please make it clear to people (and give the reason) before they download and install it.
Don’t fill up the admin pages with advertising panels! The All in One SEO plugin is a key culprit here. If donations are part of your business model then of course a small donation panel is fine, but large advertising panels or banners are annoying and almost certainly ineffective.
It also means that functionality relevant to the user could be completely hidden without scrolling. Look at the screenshot on the right. Can you tell that there are important settings on that page?
Not everyone releases their plugins using the GPLv2 licence, despite the exhortations of the guys at Automattic. That’s understandable, and I am not here to criticise. However, if your plugin is released under a different licence, please make this clear to potential users before they download or buy your plugin.
When you create the comment block at the top of your main plugin code file, you can (and should) enter a “Plugin URI”. This is converted into a Link on the plugins page in the WordPress admin console.
Ideally this should always link to a specific webpage concerned solely with your plugin – download link, install guide, feature list, etc. If your plugin doesn’t have a permanent home on the web, people are more likely to mistrust it.
If you’ve used the All in One SEO plugin (and who hasn’t at some point?), you’ll be familiar with this routine:
If your plugin adds markup and/or content to posts and pages (probably via a shortcode), make sure you give every remotely important element a class. Then, if users don’t like the way it looks, they can add some CSS rules without too much difficulty.
Are there other things you like to see in plugins? Are there particular things done by plugin developers that get on your nerves and even stop you using a plugin? Comment below…