Having written quite a few private WordPress plugins, I am now about to take on the task of creating a WordPress plugin for the general public (GPL License…obviously). It’s quite a different task from creating plugins for self or a limited use, but nonetheless one i’m looking forward to having in my own portfolio and my place of works.
I’m currently weighing up some options in terms of what to create, but at my place of work (Bytewire) we use WordPress alot for our clients and indeed many of our own projects. We have in this time come across some annoying problems which potentially a great plugin could very much help to overcome. Deciding on a feasible plugin to create is often one of the hardest things for a developer, especially so if it’s your first. I’m not venturing into making a plugin for any other reason than to help others and ticking off a personal milestone.
When developing a plugin for general public use you do have to remember a heck load more stuff, here’s some of the stuff i’m preparing my plugin to be ready for, and to handle.
Developing general release WordPress Plugins
When your developing for the general public you have to remember that your own integrity will be judged by the very integrity of your own plugin. If your plugin breaks a prospective users site, or, simply doesn’t do as it says, the user is likely to be very unhappy and potentially blacklist you as a plugin developer choice for future needs. How can you overcome these problems? Well, the simple answer is – be thorough, very thorough.
- Make sure you check your plugin can function in a WordPress MU setup, by providing different or extra funtionality if is_multisite()
- Comment your code well – WordPress is based on a GPL license, and actively encourages, code sharing and the ability to delve into one anothers code and make changes where seen fit. This helps with learning and extendability.
- Debug your code – Using the WordPress functionality, make sure you debug your code so that you are not using deprecated functions or code
- Build your plugin for the current WordPress version, do not attempt to support older versions of WordPress. As wrong as this may seem, Worpdress actively encourages this and warns all users not on the most up to date versions of WordPress they are not guaranteed a secure service unless they are. This can often be enough alone to persuade many clients and blog owners to upgrade. Generally WordPress wants to encourage upgrades as much as possible and with the possibility now to perform the upgrade in a matter of a handful of clicks, any user could do it. Suggesting to me if a user needs to use your plugin and he can’t without upgrading, WordPress effectively gets what it wants from your support as well.
- Ensure you provide the properly formatted readme.txt file when submitting it to the plugin repository on WordPress
- Make sure you are familiar with Subversion, you are required to use this to make changes to your plugin going forward.
- You are most likely to find that your WordPress plugin is naturally fairly backward compatible, depending on the functions it makes use of, but as a general rule of thumb you could make sure it’s compatible with at least the last two major releases. Given that they are done on a 3-4 month basis, this would give you all users in the last 8 months by default and any that have upgraded in that time. Which is fine.
These are just a few things that are notable about diving into the world of WordPress public plugin development, there but many more. Perhaps as time goes by I will look to add to this post and grow it with my experiences. In the mean time if your a reader and you’ve got any great ideas for a killer WordPress plugin then i’d love to here from you.