The great thing about WordPress is there are lots of plugins to tailor the environment and make it your own. The bad thing about WordPress is there are lots of plugins to tailor the environment and make it your own. No, that’s not a mistake, it’s a side effect of the vibrant development scene for WordPress plugins.
But this can lead to problems, particularly if you are a developer. A wide selection of near-similar alternatives leads a less savvy blogger to make a change to a different plugin for any issue. Whilst this is good for the blogger, it’s not so good for the developer.
Developers need to have feedback to develop their plugins. They need to know most of all when there are bugs. They need to know why their plugin doesn’t quite fit your environment. Thy need people to help beta-test new features or fixes. Without these, they have a limited selection of environments to test within, bugs take longer to fix, and new features are delayed.
For example, I’ve had an intermittent problem with one of the plugins I use on these pages. Every now and again, it would throw an error message or two at the top of a page. But not all the time, and sometimes the number of messages would change when I reloaded a page. As I’d been tweaking some of my caching settings recently, I shut that down temporarily, but no change.
So the next step was to involve the developer. A click on the “View Details” button of the plugins page gave me a plugin homepage to visit. There a contact form allowed me to fill in all the details, and helpfully select from a drop-down menu the plugin at fault. The next day there was a reply from the developer, a new version of the plugin on WordPress.org, and no error once updated. Today you wouldn’t spot that there was a problem.
So what as bloggers do we need to do?
- Don’t run away..
You chose the plugin over the others because it provided features you needed. If the plugin uses shortcodes, then you are also invested in this plugin over others as you’d have to spend time editing your pages to support another plugin. - Contact the developer and give a clear account of the issue faced, and a suitable page to show an example.
Be prepared to do simple debugging yourself, simplify the environment, disable any caching, and be ready for some exchanges with the developer. - Be prepared to test
If it’s not a simple problem, then there may be a bit of back and forth to get a reliably working fix. The developer builds his or her theory of what is wrong based on the information they are collecting from you (and possibly others.) The more they have the better their understanding of the problem. - Reward the developer for their time
This need not be solely a monetary reward; it can be in ratings of the plugin on WordPress.org, or comments on their plugin homepage. Anything that helps others understand that this developer will help support users.
If you can, reward the developer for their time. This may be a small token amount or a reasonable donation to cover their time in researching and fixing the problem.
Developers should ensure involvement of their users with prompt responses to questions; setting realistic expectations and timescales, and provide clear information back to their user community. It’s normally easy to spot these on the WordPress plugin site. They are the ones that have more frequent updates, clearer changelogs, and good ratings.
“The nice thing about WordPress plugins is that you have so many to choose from; furthermore, if you do not like any of them, you can just code one yourself, or wait for the next developers model.” paraphrasing Andrew S. Tanenbaum
