A post over at CMS Critic received some unwarranted flack due to how it was written. However if you can look beyond any fanboyish reactions, some issues the author, Kaya Ismail, brings forth are worth taking some time to think and write about.
What I’ll focus on in this post is the vast plugin directory. Kaya writes a bit about the issues end-users have regarding selecting and installing plugins that don’t actually work. There are multiple reasons as to why a plugin does not work on a site; such as: PHP code errors, permissions issues and plugins conflicts. I’ll write a bit on various ways that WordPress itself and wordpress.org can do to prevent users from installing non-functioning plugins. I’m not taking things like, user experience, performance, scalability, DDOS scenarios, and more into account. There might be potential privacy issues with some solutions as well. Also this is just about reporting non-functioning plugins and I won’t discuss improvements to search and listing of plugins. This post is just a brainstorming session.
Manual feedback – Current approach
The current feedback system is manual. Plugin and theme users need to visit the plugin page in the directory and mark if the plugin works or not. The biggest issue with this is that very few people actually take the time to do this even when a plugin is broken. The second biggest issue is that as an end-user you have no idea if the reports are about actual issues with the plugin or that it didn’t do all the things the reporter wanted it to do. There is not much one can do about the second issue but there are possible solutions to the first. One way to get information is to ask the user when they deactivate the plugin. “Did it work for you? Yes, No”. If the user chooses “No” , show a field for additional information. To limit when it shows up WordPress could disable it when using WP_DEBUG. Would be annoying to have it show up if you are working with activation/deactivation issues as a developer.
Of course one issue with asking users upon deactivation is that it can increase the amount of reports that concern the user expectation and not if the plugin actually works or not. Adding radio buttons; had errors, didn’t do what I wanted, my site looked weird, so the pop-up form could be one way to counter the false reports. If a lot of people report issues but the plugin is not broken that should be cause to review the plugin description.
Solutions for WordPress.org
Automatic checks on WP.org
Automatic code validation on .org could detect minor issues but the amount of false positives would probably outweigh the usefulness of this approach.
Other ways to detect issues would be to activate each plugin on a test site before making it available to users. Having plugins activated and then run updates on them would detect any problems before the issues reach the plugin users. After activation visits to the front end and various backend pages could be made and if any PHP errors are detected the plugin updates would not be going out.
Manual checks on WP.org
This is probably the most cumbersome solution. What this would entail is that a group of testers manually verify if plugins are working as expected. They go to a sandbox install on wp.org and activate and do some rudimentary testing of functionality of a plugin. Then they mark the plugin as working or not working. Plugin downloads/updates are only available to all users after it has gone through this process. You should be able to opt-in to use untested plugins/themes if you are adventurous otherwise you cannot activate the plugin on your own site. A curated list of plugins of sorts. It could even be a service that end-users pay for. This would work best if WordPress by default supported multiple plugin and theme directories.
Automatic checks on end-users sites
Most efficient reporting systems will rely on actual user usage of plugins and themes. There are a number of scenarios where WordPress, in theory, could detect issues and report them.
Activation issues
This one is easy enough. WordPress already activates plugins in a
sandboxy way and detects errors upon activation. One way to improve the plugin/theme directory is to send this information to wp.org along with which plugins and theme that is used. When the WP service has registered some percentage of activation issues compared to installs it marks the plugin as broken. This information can then be emailed to the developer so they can act or not act. While waiting for a new update the directory will show the plugin as broken and inform the user of the risk. Of course if all activations generate errors then the plugin will not be available to be installed at all. The verify upon activation approach also gives the added benefit that plugin authors have to think twice about doing time-consuming tasks during activation or perform actions that require specific file permissions. Those two cases often cause errors for users.
Runtime issues
This comes into effect after some event, usually update/activation of a plugin or theme. Some plugins breaks the site since they generate an error. With regards to runtime errors there are 3 types that are most common. From the PHP documentation:
-
E_ERROR: Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted.
-
E_WARNING: Run-time warnings (non-fatal errors). Execution of the script is not halted.
-
E_NOTICE: Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.
A plugin or theme should not generate any of those types of errors. If it does then it should not be used since the quality of the plugin/theme cannot be trusted. And by trust I include security issues as well. If your plugin generates warnings and notices it is not unlikely that it also contains potential security issues due to not following best practices. Of course sometimes notices occur due to WordPress not handling certain scenarios correctly but that’s something for another time. However the only one of the errors that actually can stop a site from functioning all together is E_ERROR. If a plugin generates such errors during runtime it most definitely should not be installed by anyone.
The question then is how can we make sure that these types of issues don’t make it to the end-user? The first thing that comes to mind for me is to extend the current error handler. WordPress already comes with an error handler implementation but it is only used during activation. Having this run during normal scenarios would make it possible to catch errors, detect which plugin causes the issue and send a report to WordPress. The information that could be sent is the error itself, WordPress version, plugins and theme. Also the PHP and MySQL version might be good to collect. If WP.org has this info it can then mark the plugin as breaking if enough sites report issues. It’s also possible to inform the developer of the issues before the first angry people visit the support forum. Using a custom error handler causes issues with the default logging since its replaced and I’m not sure how to best handle the conflicts with monitoring services that arise from that. One thing is probably certain, those who use monitoring services will probably disable this feature all together anyway.
In conclusion
Well, there are quite a few different approaches to the issue of non-working plugins and themes in the wp.org directory. Some are doable, others not so much. I have just tried to come up with a bunch of ideas. Do you have more ideas on how to make sure that the plugins and themes users download actually work properly? Are there any of my ideas that you wish to expand upon? Go ahead and do so in the comments.