Now that I’ve already written three WordPress plugins, and even use many other plugins, I have noticed some things that should be considered when creating a plugin. Due to the fairly extensive WordPress Plugin API creating a plugin isn’t very complex, but unfortunately, most of the plugins lack quality. So everyone who wants to create a plugin should care about certain things.

Create something new

The hardest part is probably to find a good idea for a new plugin. The three plugins I have written were founded by a specific need. A certain feature wasn’t included in the main features of WordPress and there was no plugin in sight, that could offer this feature.

Before starting to write a new plugin, you should search for an exisiting plugin in the Plugin Directory, if there is a plugin that is similar to your requirements. If you found a plugin that almost has every feature you need, but lack only a specific one, ask the author to add this missing feature. Maybe he just hasn’t the idea to include it into the plugin.

If you really coudn’t find a plugin available that includes all the features that you need, you can either write a completely new plugin, or build on an existing one. My Backend Localization Plugin for example offers only one feature of the qTranslate Plugins which I also use for this blog. But as you only get this feature together with all the other functionality of the qTranslate plugin, it isn’t very useful to install the qTranslate plugin if you only need this single feature. Therefore, there was a justification, to write a new plugin with only this feature. But I solved the problem in a diffrent way, so I don’t simply copied the part out of the qTranslate plugin. So if you copies an idea, always create something new, that will be useful for other users.

If you don’t have any problem that need a plugin, but you want to create a plugin yourself, just ask your readers, if they need a plugin. Or just check out the ideas of other WordPress users. Maybe you can find a problem that you can solve with a plugin.

Attach importance to the quality

I have tested a lot of plugins for my blog. Most of them had unforunately a very poor quality. Some were not very up to date and were still listed as compatible with the latest version of WordPress. Other plugins were so poorly programmed that they crashed the blog. In such cases, delete the plugin folder via FTP is the only way to reactivate the blog. Even if your plugin works, it should implement the described function and offer, depending on the necessity, a few customization options. Some of the plugins will supposably removed, right after using them the first time, if the user doesn’t like them. In this case the download statistics will only show you haw many users have been attracted by your description to download the plugin, but not, how many of them actually uses the plugin. So before pubslidhing a plugin for the first time, you should test it a lot on your own blog, or even better in a special test blog. To test plugins for downward compatibility, I use a local test blog which I can switch to any version, using Subversion. That allows me to test very quickly and efficient.

Presentation counts

There are many plugins in the directory that don’t have any description. Creating a readme for the WordPress system isn’t very difficult. Just have a look on the readme of any plugin that is installed on your blog. If you create a plugin with a user interface, make some screenshots because no one wants a pig in a poke.

If you have a special post on your blog for the plugin, you still should offer some basic information on WordPress, because some blog ownders install plugins through their blog admin panel without clicking on the link to your plugin homepage. You don’t have to write a novel, just explain the main features and restrictions. if you extended a existing plugin, mention that in your description, so other users recognize, if they already have a similar plugin.

Finally, a request on the use of tags. I have seen many plugins that uses a lot of tags, just to be listed in any group. This is not fair to other developers that really created a plugin for that tag and it also give a dubios impression to your plugin. So some users may even not try out your plugin because they consider that it is not very serious.

Make the plugin translatable

No one expects you to translate the plugin into hundreds of languages, but at least prepares it to be able to be translated. You will be surprised, how quickly an enthusiastic user of your plugin will be found, that offers you a translation file. Since WordPress is used worldwide, and not every user in good in English, you should therefore do all a favor and read the Translating WordPress instruction. In the blog of Ryan Boren you will also find information on how you have to prepare your plugin. Or just search the internet for a guide, there are many detailed guides that will take up the issue.

Take advantage of the various functions of the API

The API of WordPress offers many custom features of common tasks. If you for example, must read data from the database, it takes away almost all the work. Even the creation of complex links goes on all by themselves. Whenever it is possible, you should therefore use the functions from the API.

The features are often available for several versions and have been tested very intensively. In addition, they are explained in the Function Reference in the Codex very good. If you can figure out how a function works by reading the description, I advise you to look into the source code. Many features are self-explanatory. Thereby you can also see if the function in its form fits your need, or if you have to write your own function. If you really have to write your own function, you should comment on them in the source code so that another programmer can reuse it for any other plugin.

Show interest for the users of your plugins

One thing that I have unfortunately seen with many other plugins is the lack of interest by the programmer to the users of their plugins. I found two plugins that were very well programmed and also have a very popularity and spreading. But in both plugins there was serious programming error that made it impossible to use under certain circumstances. Unfortunately, both programmers responded only after several months on a request.Therefore, I have corrected the errors myself in both cases. With each update of one of the plugins, where the mistakes were not corrected, I had to correct the error again.

I always try to answer questions about my plugins very quickly and could also solve the problems so far. Not always will you succeed in reparing the plugin for each user. It often fails because of the combination of plugins that the user has in use. But only you can give the user a hint of what he can possibly do to solve the problem in his case.

Conclusion

Anyone who only writes plugins for himself and has no interest in dealing with any errors, should not publish the plugin in my opinion, because the frustration it is growing on both sides. For the user, this often means that he will never have trust in any of your plugins.

This article isn’t intended to deter anyone from writing a plugin. I’ve seen plugins that have consisted of only 4-5 lines of code and had a real function well implemented. No one is born a master and every one of us constantly learns how to make plugins more effectively and more user-friendly. But you should habe a certain standard, because after all, it is presented to a huge user community, and you want to be proud about your masterpiece.

How it looks at you. Have you made a similar experience in programming yourself? Did you ever get in trouble with faulty plugins and no help? Or did you have not yet dared to become proactive and write a plugin?

I would be happy about a lot of comments and a very lively discussion. And if someone wants to make a comment about my plugins, or perhaps someone could provide a new translation, I would be much happier.