Today, I’m going to document 5 things that I think WordPress plugin developers should be doing, if they’re not already.
And there may be some controversial choices here, particularly for those who develop premium plugins. One of the most popular plugins, for example, fails every single one of these.
1. Use PHPCS
PHPCS is a command line tool that can also be integrated with many IDEs (I use it with Sublime Text). It parses your code and checks it off against specific rulesets that you choose.
And, yes, there are some WordPress rulesets available. These will check your code for everything from layout to security concerns to accessibility.
You can find PHPCS on Github, as are the WordPress rulesets. The following rulesets are available…
WordPress-Core– main ruleset for WordPress core coding standardsWordPress-Docs– additional ruleset for WordPress inline documentation standardsWordPress-Extra– extended ruleset for recommended best practices, not sufficiently covered in the WordPress core coding standards. This also includesWordPress-CoreWordPress– all of the above
The great thing about PHPCS is that you can mix-and-match which rulesets you use.
If you want to take this one a step further then WordPress VIP have their own ruleset. WordPress VIP provide hosting for some of the largest, enterprise-scale websites there are, so their rules are heavy on performance and security improvements. It also highlights any issues that your code may have running on their platform (e.g. they lock down the file system), providing solutions.
I run all my plugin code through both the WordPress and WordPress-VIP-Go rulesets.
2. Make use of uninstall.php
If you’ve been running your WordPress site for a while chances are that your database contains a lot of bloat – left over options and even whole tables from plugins and themes that you no longer use.
When developing a plugin it’s vital that you make use of uninstall.php – this is a file that you have in the root folder of your plugin and tells WordPress what to do when your plugin is deleted (note: NOT deactivated). You can use this file to remove anything that would otherwise be left behind.
3. Don’t create database tables unnecessarily
This crossed over with the above recommendation but, essentially, if your plugin creates new database tables, seriously consider whether you should. Really.
Most plugins that create their own tables store post-specific options or general site settings, both of which are covered by existing tables. I suspect developers just like seeing their own tables in somebody’s database.
And the age-old, “but scaling…” argument doesn’t work. Most of WordPress.com runs off a single instance of WordPress and there’s a lot of sites (think of a really large number… no, it’s bigger than that). Really, the only time to consider your own tables if if you’re storing large amounts of non-post specific data that an existing table doesn’t cover off.
4. Use WP Admin correctly
This is the point I bring out this slide to demonstrate the tl;dr of this section…
What I’m talking about here is 3 things in particular…
- Mis-using the menu system
Coloured menu options? Placing your menu at the top of the list? Creating a new menu option for settings?
And these are just a few of the things that developers do for the “look at me, look at me” part of trying to push their plugin. Except, I’ve already installed it so I see it. But I don’t want your minor plugin to be above the Posts section. I don’t want your coloured option to break accessibility.
For more information on what I mean, including some fine examples, please read my earlier post “We need to talk about menus“.
- Introducing your own UI for your plugin
Why? Just “why”?
WordPress has its own UI, backed up by a number of APIs that help you easily output in the same way. So, a plugin developers comes along, adds their own screen and decides to do it their own way. For example…
And this is certainly not the worse.
3. Pushing your premium options
You know who you are, with your premium banner ads and even extra (usually coloured) menu options that take you straight to it.
But I get it, you need to promote your services – after all, it’s probably those that justify your free plugin. However, you need to consider if it’s so detrimental to the user experience that it’s just pissing people off. There’s a discreet side banner (see above screenshot) and there’s taking over the screen.
For example…
What a lot of these plugins have in common is what you can see in the screenshot above – there’s a premium version that they’re trying to sell, hence the need to “stand out”. But, as a potential customer, I find the need to badly integrate a turn-off.
5. Reduce code bloat
There are so many cross-overs in all of the 5 examples and this one is no exception, as now I get to mention the excellent core APIs again. One of the other benefits of making use of them over your own bespoke solution is reducing your code size down.
Developers love adding more and more features, finally getting to the point where they’re incredibly obscure or need even related to the core product. Spinning it off to a separate plugin not only keeps code bloat down but (in the case of those doing this as a business) gives you an additional promotional resource.
I did this recently with my Draft Lists plugin. It started off as a way to list, in a post or in the sidebar, any draft posts. I then added admin options to make it easier to view them in the backend too. It wasn’t until I needed the latter functionality in a website but not the former that I decided to split them. Draft Links was then born. The great thing about this is that I can take any of these in a slightly different direction now – draft links may even get renamed as I intend to use it for all sorts of post status’, not just drafts.
But also, just generally, consider what you plugin does, keep the overhead to a minimum but also remember performance too….
- Functions get written, re-written, patched, patched more. Ensure your code remains performant.
- Code bloat can come from just adding scripts and hooks all over the place, without consideration. Only add these in where they’re actually needed.
Bonus: 6.
I’m no angel when it comes to the above and if you went away and trawled through my plugins you’d find me breaking some of the above rules myself. But that’s not been the case for a while and, as I update them, I’m making sure I do follow them. I think they’re important. Your mileage may vary.
Talk to me!