We’ve been building WordPress plugins for a long time now, and we’ve built a lot of them. In this post we’ll be doing something a little bit different than normal whereby we put together a list of 5 things we’ve learnt during this process to assist others looking to build their first plugin, property related or not.
1: Try and get it right first time
Hindsight is a wonderful thing, and it’s not possible to know what the future holds, but maybe just take 5 minutes extra to think about how your plugin will be used and how difficult it might be to change something going forward.
Changing data schemas or templates in the future can be tricky, almost to the point where sometimes you can’t make a change without it breaking sites already using the plugin.
An example of this is as follows:
Our Property Import add on allows you to import properties from different third party estate agency CRMs. When it was initially built it only supported a single import, however minutes before releasing it we pulled the plug and spent an extra day updating it to support multiple simultaneous imports. This was one of the best decisions we ever made as we now see multiple imports being used on a daily basis and changing this would’ve been difficult.
Of course it’s possible to write migration scripts when it comes to a change in data structures but these in themselves are an extra development piece that could be avoided with a little extra thought.
2: Cater for every server configuration
Just because you developed your plugin on an Ubuntu server running PHP 7.2 doesn’t mean everyone else is. Differing PHP versions, PHP configurations and installed libraries means further consideration is needed. Our advice surrounding this is as follows:
Ensure error reporting is at maximum whilst developing the plugin and/or regularly consult the server error logs. That way you catch every warning and notice error.
Test the plugin on different server configurations and PHP versions.
If using PHP libraries, don’t assume they’re installed and handle this accordingly. Our Property Import add on makes use of the PHP SimpleXML library to parse XML files which I thought was always enabled by default. Turns out that in rare scenarios hosts actually disable this so we now check for this and display a notification.
3: Remember other plugins will also be installed
Try to make every CSS class, every option name and every function unique to your plugin so that it won’t conflict with another third party plugin should it, by chance, use the same name.
All of our option names and hook names are prefixed with ‘propertyhive_’, classes prefixed with ‘PH_’ and functions prefixed with ‘ph_’ where applicable.
If we were to develop Property Hive again I’d probably go one step further and also make all custom post type and taxonomy names unique as well, prefixing them with ‘ph_’ or similar. We’ve seen it a few times where third party plugins use a shared taxonomy name such as ‘department’ which has caused issues. Thankfully this happens once in a blue moon but nevertheless, it’s one extra support query that could be avoided.
4: Support your plugin
Talking of support, if your plugin gains traction and you want to build a userbase you’re going to need to support it. The first step regarding this is to try and reduce support even coming in in the first place. Some tips regarding this are as follows:
- Add installation and usage instructions to your plugins README file
- Have an FAQs section
- Write documentation
- Build a good, informative UI with tooltips, clear descriptions and embedded links to relevant documentation
Should support queries still be raised, see it as a positive rather than a nuisance. Think about why the support query was raised in the first place; are they proposing a good feature request, or could your documentation be made clearer to prevent that same query coming in again in the future.
If support queries are being made through the ‘support’ tab on the WordPress plugin repository page, by answering queries there it’s in itself building up a knowledgebase for others to reference in the future, plus it shows that you’re responsive and this is a plugin that others interested in downloading it can trust.
5: Your code will be visible
Having worked in large development teams for a number of years prior to Property Hive, writing neat code that can be understood by others is almost engrained into us.
That said, if you haven’t had this opportunity, or you’re writing a plugin by yourself and don’t prioritise code readability, remember that once your plugin is published everyone will be able to see your code. I feel how code is written says a lot about the quality of a product and that, by seeing code thrown together, riddled with typos and no comments, it gives me little confidence in the plugin, nor the will to support it.
Having neat, easy-to-understand code is also important if you want other developers to contribute back to your open-source plugin. If they can’t understand how things work or figure out where things reside, it’s likely they won’t bother contributing.
For aspiring plugin developers out there we hope this helps you to avoid some common pitfalls. One of the things I love about working on Property Hive is the constant learning curve that never ends so hope to share more posts like this in future.
