PodPress Disaster Highlights WordPress Problems
Jul 30th, 2008 | By James Lewin | Category: Podcasting SoftwareWordPress 2.6 has been a disaster for a lot of podcasters.
The update, which WordPress creator Matt Mullenweg said “should be pretty painless,” has broken a lot of podcasts, leading to a lot of kludgie workarounds.
Some, like Dan McKeown, think the WordPress/PodPress fiasco highlights broader problems with the way WordPress is handling releases:
This episode is a good illustration of a few problems with WordPress and the relationship between the CMS and its plugins. First, Automattic, the company that manages WordPress development, is extremely overzealous in pushing new versions on users at the expense of previous features working. Second, the lack of professionalism of plugin developers is a serious danger to the continued functioning of blogs for a wide range of WordPress users, from casual podcasters to large enterprises.
The problem with pushing new versions and features on users is a fairly nuanced one. Let me explain: I do not mean to say that new versions and new features, even at the pace at which they come out, is a problem. Rather, the problem is the assumption by Automattic that all users are ready for major upgrades every three months and have the time to install new versions and find updated plugins. Because the last few new major releases (WordPress 2.5 and 2.6) have included some fairly major changes, they broke the functionality of many plugins that were designed for older versions. That really is okay–I don’t want to stand in the way of progress here–but what I don’t understand is why they can’t maintain the older versions for a little longer while people scramble for new plugins.
WordPress has gotten a free ride from many analysts, despite a history of security problems and new releases that break existing features and plug-in compatibility. In fact, WordPress has had many more security problems over the last four years than other content management systems, like Joomla and Drupal.
I still think that WordPress is the best blogging platform, but the PodPress problems and the history of security problems with WordPress show that Automattic’s constant push to get user to upgrade to a new version is dangerous.
WordPress is a mature content management system with hundreds of thousands of installs, which makes it a nice target for hackers and means that features changes are more likely to break things.
Automattic needs to maintain two versions of WordPress because of this:
- the bleeding-edge version that it’s been releasing every three months or so, and
- a “stable” version that for users more interested in security and compatibility
Let me know what you think – is it time for WordPress to slow down and get more conscious of security and compatibility?
Couldn’t they take the hint also and build podcasting features into WordPress as it is used by a lot of podcasters out there. Sure there is a plug-in but WordPress don’t have control over it. Like Ford making a car and getting the steering wheel from GM. It might work but its less than a perfect arrangement.
On the main question, yes, definately, why didn’t they think of that themselves? There seem to be a lot of developers out there rushing to push up the version numbers at the expense of the userbase, I think eSyndicat is one of the worst for this. Always requiring one of their guys to fix things EVERY time there is an update, and whats worse, THEY write their own plug-ins.
TAKE THE HINT PEOPLE! Customers matter!
I talk a bit about the update issue in this comment on Dan’s site:
http://pacificpelican.us/archives/podpress-meltdown-illustrates-problems-with-wordpress-management/#comment-443
I think it’s up to the plugin developer to keep track of the core software. If the plugin will not be compatible with the upcoming update then the developer should alert their community that this is the case and provide updates on development progress as necessary.
Matt
Thanks for your feedback.
Your comments at Dan’s site pin the blame for the PodPress incompatibilities on MightySeek/PodPress, and there’s probably a lot of truth to that.
However, the constant drive to upgrade WordPress, at the expense of maintaining a stable version, is clearly leading to incompatibilities and security issues, too.
Isn’t this something that the WordPress community will have to address at some point?
The implication seems to be that the developers driving the WordPress project care less for security than they do implementing new features. I know most all of the developers, and I assure you, nothing could be farther from the truth.
This leaves the complaint about slowing down on the release of new versions with newer features. For that, I’d simply suggest not upgrading immediately when a new release comes out. Let the early adopters deal with the problems, and update when it makes sense to do so.
In the case of podPress, there hasn’t been an update for 8 months now, and as Dan explained, adding two lines of code fixes the 2.6 issue. In all, it seems to me to be a lot of heartburn over a little issue.
Two WordPress developers have volunteered fixes for both the 8.8 and 8.9 branches of PodPress – it’s only a few lines of code to cure the problem:
http://azaozz.wordpress.com/2008/07/31/podpress-in-wordpress-26/
James, we do maintain a stable version — the latest one. 😉
We did maintain the 2.0 branch for several years after its release, but its usage was so low and the developer cost so high I don’t know if we’ll do it again.
It’s fascinating seeing this play out in many different communities. In short: WordPress is open source. If there is a market demand to maintain / support older versions, then “some company” should arise to meet that demand.
Now, I’m not going to let WP core off that easy, though. I think there are a number of things that could be done to the code to re organize the way it is structured to make it easier to maintain plugins. As I understand it, some of those changes are underway.
Oh, and nice title: if by “disaster” you mean a lot of people did upgrades to the software that runs their entire website without doing a trial upgrade and/or having a rollback plan in place.
Boris – a lot of podcasters don’t know anything about the idea of staging “releases” for their sites – and when the WordPress creator says the upgrade should be painless, that’s what they were expecting.
For many podcasters that are more interested in podcasting than maintaining a site, the upgrade was a disaster.
You could put the blame on podcasters that should have known better, you could put the blame on WordPress developers, you could put the blame on plug-in developers. In my view, though, these problems are a side effect of not maintaining a separate “stable” version of WordPress and a current version for those that value cutting edge features over stability.
I really don’t like the assumption that ordinary wordpress users (like me) even know HOW TO do a trial upgrade. Do developers expect only developers to use this software?
I totally agree with the original point: there should be a stable version that anybody can use and a developer version for people who like to experiment. The way it is in firefox. If I’d have known it wasn’t like that, I would not have been so quick to update to the latest wordpress version. Which seems to now be responsible for me not being able to even blog… (and since I’m not a developer I’m stumped . where do I start in debugging? I can’t even find information on THAT).