
Disclaimer: I am not a plugin author. This post is filled with my own opinions and is taken from an end user point of view. If you are a plugin author, be sure to add your point of view in the comments.
Traversing through my feed reader after a major version of WordPress is released is always interesting to me because I’ll never know what types of reactions I’ll find. Unfortunately, I’ve been noticing a trend that is unacceptable. The basis of this post will be focused around a line of thought which I find to be anger inducing.
The biggest problem lies in the fact that Wordpress is continually pushing updates too often without much in the way of testing with the most popular plugins. Podpress is huge! how could they have released 2.6 without seeing if one of the most popular plugins will work? To me the fault lies in Wordpress updating too soon. As I am on a hosted install of Wordpress, I can’t roll back, so now I am stuck. From now on, I will clearly be waiting at least two months before pushing any hosted updates of anything Wordpress related! - Comment Written By Jason Of Canonblogger.com
This is the type of comment I’ve been reading lately on blogs which discuss the PodPress incompatibility issue. Time to break this line of thought down. First off, lets take a look at this years timeline of WordPress releases thus far.
- Version 2.5 / March 29, 2008
- Version 2.5.1 / April 25, 2008
- Version 2.6 / July 15, 2008
- Version 2.6.1 / August 15, 2008
- Version 2.7 TENTATIVELY SCHEDULED FOR November 10, 2008
By looking at the release dates for actual versions used by the public, we can see that at one point, two full months went by without a release. Further that with the fact that a maintenance/security release follows a major release one month later. WordPress is publishing software which is extremely popular and this popularity has its pitfalls, mainly with security as the popularity of the platform makes for a nice target. Would you rather WordPress release updates twice a year? What happens if a major security vulnerability is discovered at the halfway point between releases? Would you want WordPress not to deviate from their release cycle? As far as I’m concerned, I’m pretty happy and relieved to see the WordPress development team up on their game, releasing updates to the software multiple times per year. With plugins such as Automatic Upgrade taking the pain out of upgrading through FTP, I don’t understand why the number of updates per year is such a hassle.
One of the statements in the comment above describes the fact that the WordPress team must test out the software with the most popular plugins before releasing it to the public. Since when did the responsibility of testing every plugin known to man for WordPress fall on the shoulders of the WordPress team? The answer, never! In a recent post written by Lloyd Budd he happened to write a statement which I whole heartedly agree with:
I see the Automattic team as the WordPress guide. WordPress is completely community created and supported. Automattic takes on the big (scalability) problems that the community doesn’t have the resources for like: providing the free WordPress.com service and funding usability testing of a new WordPress dashboard experience.
Based on what I’ve seen, what happens with plugins and their compatibility to WordPress is outside of the teams control. I hate to pick on PodPress in this post but it makes for a great example. Before WordPress 2.6 was released, it went through three different Beta releases with one release candidate. The first beta release happened on Monday June 23rd, 2008. The actual release of 2.6 occurred on July 15th. That makes for a total of 22 days which passed between the first beta and the actual release. In my opinion, 22 days is plenty of time to figure out if a plugin is compatible or not. Granted, there may be personal issues, lack of time, or some other reason why the plugin author has not updated a plugin. Suffice to say, a plugin not working lies on the shoulders of the plugin author, not the WordPress development team.
PodPress is a special case in that the WordPress team actually created a patch for the plugin and then sent it to the plugin author. This was reported by Matt himself on a post written by David Peralty. Apparently, the patch never made it to PodPress and to this day, the plugin is incompatible thanks to an issue with the post revision feature. Matt did comment on the fact that there is not much they could do except commit the code directly without Dan’s permission.
Conclusion:
The bottom line is this. WordPress has a good release cycle and in my opinion, provides plenty of time for plugin authors to test their plugins with the newest version of WordPress before the public gets a hold of it. My opinion is that, the WordPress team can not and probably will not take it upon themselves to insure that all major plugins work correctly with current/future versions of WordPress. So the next time you upgrade WordPress and realize your favorite plugin is broke, don’t blame the WordPress team, blame the source.