WordPress developer Dalton Rooney raised some interesting points about the WordPress plugin repository. Those of you who frequent the repository a lot will be aware of the compatibility box to the right hand side of all plugins. The box allows you to vote whether a specific version of a plugin is working with a specific version of WordPress (it defaults to the latest version of each). It’s an incredibly handy resource that is unfortunately underused as it’s incredibly useful to know whether a plugin works with the version of WordPress you are using.
Dalton today spoke about a minor annoyance about this setup. He notes that his Portfolio Slideshow plugin had previously had 7 votes stating that the plugin worked fine.

Unfortunately, for the latest version of WordPress, some people have reported that it doesn’t work. Since the compatibility box defaults to the latest version of WordPress, this suggests to potential downloaders that the plugin isn’t working correctly.

He quite rightly points out that there is little incentive for people to vote when a plugin is working fine but a great incentive when something isn’t working correctly. I must admit that I have been guilty of this many times in the past i.e. only taking the time to vote when the plugin isn’t working correctly. Due to this, the compatibility box results can be skewed negatively.
Dalton notes that:
99% of the problems I’ve seen with our plugin fall into the following three categories: 1) Didn’t read the instructions. 2) Poorly coded themes missing the header or footer functions or hard-coding scripts, or 3) Conflicts with lousy plugins that hard-code scripts instead of enqueing them.
I’d like to create a little survey that runs whenever someone tries to click that “Broken” button and ask if they read the instructions and the FAQ before they are allowed to vote. And, if a problem is reported to the forum & then marked as resolved, their vote is automatically changed to “Works!”
I can understand Daltons frustration with this. There are thousands of plugins and themes in the repository that are poorly coded. Every plugin has the potential to conflict with something else because of this issue. It’s unfair that anyone can simply check that a plugin is not working without testing it in the proper environment.
As many of you know, I have tested hundreds of plugins in order to review them on WP Mods. I appreciate that Dalton is a plugin developer who spends a lot of time adding good instructions and making sure the code is of a high standard. From my experience, this is not always the case. For every three or four plugins I test out for WP Mods, there is always one that simply doesn’t work.
When I test a new plugin I make sure that no other plugins are activated and always use the Twenty Ten (or recently Twenty Eleven) default WordPress theme. Unfortunately, some just do not work. I have sent many emails to developers advising that I am attempting to review their plugin. Many have resolved the issue though some have not even replied. It’s something that frustrates me as you can spend a lot of time trying to get a plugin to work.
Likewise, not all developers add good instructions for downloaders. Today I reviewed a questions and answers plugin for an article that publishes in a week or so. I could not get the plugin to work but I eventually found a response in the support forums that said that in order to make the plugin work you had to re-save your permalink structure. Unfortunately, there was no note about this in the installation instructions.
Compatibility Procedure Needs To Be Reviewed
Bearing in mind what I noted above, I believe that Dalton is right; the compatibility procedure needs to be reviewed. The compatibility box is an incredibly useful feature and can save others a lot of time by advising them that a plugin is not working, however the procedure in which a vote is cast should be reviewed.
Perhaps instead of a broken link vote the user is taken to a feedback form or support thread where they note the problem they are having with the plugin. This can then be reviewed by the plugin developer. They can then either explain to the user what they are doing wrong or upgrade their plugin accordingly. If they state that they cannot fix it and/or a set period of time passes without a solution, the negative vote would be cast.
This would make the compatibility box more reliable as far as negative votes go though it’s prudent to assume that if the procedure to cast a negative vote is longer, there is less chance of negative votes being cast. This is a good thing though, as with the method, if the vote is not cast as negative, it means that the developer answered the users query and updated the installation instructions or fixed the issue and updated their plugin.
Dalton suggested that if a developer resolves and issue the vote should be changed to confirm that the plugin works. I would change this slightly by adding a negative vote to the previous version but automatically adding a positive vote to the new version. This ensures that users know that they should download the latest version.
Do you agree that the current system of casting votes on whether a plugin works needs to be reviewed? I’d love to hear your opinion on this issue
Thanks,
Kevin






hi Kevin,
thank you very much for your reply! :)
i just developed a foursquare based wp plugin and i run it on wordpress 3.2.1 but some friends of mine had problems with wp 3.1.2. is it somehing so usual?
in addition, thank you for your point of view about compatibility.
the most frustating thing is that i developed the plugin following the codex.wordpress guide!
thank you again!
Andrea :)
- spam
- offensive
- disagree
- off topic
Like