Thanks for clarifying. Part of the problem is the double-edged sword of third-party code. The availability of so many great third-party plugins and themes is one of the key features that makes WordPress such a great platform, for both developers and end-users. But we can’t expect the core devs to take the blame every time some non-core code blows up (maybe every once in a while).

I know that changes in core can happen that “break” plugin, it’s happened to me. I’ll give you my example: First of all, note that when I was a core developer myself, I created the “Post Custom Fields” (AKA “post meta”) feature. And the first WordPress plugin I wrote was HeadMeta, which takes advantage of this feature. But even though I wrote both the underlying API code and a plugin based on it, my plugin “broke” one day. Because in my plugin, I bypassed the API and directly accessed data from the $post data structure[1]. *I* didn’t see it break on *my* site, but others did (because I wasn’t triggering the serialization change that happened in core, and they were). Of course, I eventually got enough info from users of my plugin to figure out what was happening, and released an update to my plugin.

The point is, changes *will* occur in core. It must evolve and improve and grow new features.

But did the core devs have any responsibility to avoid changes that would break my plugin? No way. First of all, it’s not their code that broke. Second of all, it was my own fault for bypassing the API (that *I* wrote!) and not noticing sooner that changes occurred in those functions and data structures. Third of all, the changes they made were an improvement that currently benefit many developers.

Is it hard to keep up with the changes that happen in each new version of WordPress? YES! Is the answer that plugin/theme authors should try harder to keep up? YES! And no! I mean, yes, plugin authors *should* try to keep up. But on the other hand, the core team could make it easier.

With every new release, many new functions, classes, and other helpers are added to core. And occassionally, existing functions change or become deprecated. But (as far as I know), there’s no official quick-reference to those changes. You have to pore over tons and tons of changes in Trac, or look at the source, or keep a close eye on some of the xref tools. What would be great is if each release was accompanied by some developer notes detailing “new”, “changed”, “deprecated”, and “removed” status for functions and classes (and to key global variables).

This information should probably become available at “beta” (or maybe even “alpha”) testing stage, updated at RC stage, and cemented at release. And it should be documented well in the Codex, referenced on the wp-testers mailing list, and any place else that might make sense (it might even merit an announce-only mailing list of its own). I think this would go a long way towards helping the wide-spread WP development community stay up-to-date, and help avoid “plugin breakage” problems.

[1] *Technically* the breakage wasn’t really because I bypassed the API, but because they changed what kinds of values the API could return. My code always assumed that it would get a plain string. Change in the API meant that it could possibly return an array. But still, I should have been validating…
Dougal Campbell´s last blog ..Most Useless iPhone 3.0 Feature

I also acknowledge that a good communicator may have to assume such a posture in order to reach an audience, if that audience is so predispositioned. Maybe kid gloves are needed when dealing with WP devs.. not my call… and I don’t make any assumptions of your intent.

I did notice you made some good suggestions re: improvng the process. They were not relevant for this discussion, but now they may be, since you clarified you did not intend to be disrespectful of users. I hereby acknowledge them

For the record I’ve done some coding myself, and I understand the process pretty well. I do not agree with most of the posters complaining about WP security, where they start to slam the plugin developers for not keeping up or WP for not “certifying” plugins (or plugin developers). However, like water, piss flows downhill. Where WP and its devs openly disregard user concerns, or make claims about WP that are unsupported, WP and the devs need to be addressed. You can’t say “it’s easy, the dev community is huge and awesome and there are 2 billion themes available for free and therefore you should use it and trust it” but also say ‘it’s not us, it the plugin developers.. they should keep up and follow the rules” or my all time favorite, “don’t use plugins you don’t trust or test them yourself”.
john andrews´s last blog ..Google Owns Your Internets

But, I still don’t understand your argument. You seem to feel that the WordPress core devs are not paying attention to security. But the fact is that the bug being exploited by this worm was fixed TWO releases and over A MONTH ago. Yes, it’s unfortunate that there was a security problem in the first place. But if you’ve programmed a complex web application like WordPress (or any other fairly large web app), then you know that there are all kinds of code interactions that can be very hard to keep track of.

Sometimes you write some code and you think you’ve covered all the bases and cleaned up all your input. But you forget that your function might be called in some other context with input that you *didn’t* control. Or you’re doing complex things with regular expressions and you just didn’t anticipate some really weird off-balance input coming in which causes it to match in a way that you didn’t intend. And dozens of developers can look over a piece of code and say, “yup, that looks right to me.” But they just didn’t foresee that *one* strange case that causes it to fail. It happens because we’re all human.

In the last couple of releases, there have been several new escaping functions added to the system which are specifically for the purpose of making it easier for plugin and theme developers to generate safer code. This kind of proactive security development is just one example that shows that they *do* take security seriously. It’s nothing flashy, it’s all under-the-hood, system-guts, boring kind of stuff, so most people don’t notice it — just the watchful developers who need to know about those things.

I did not “conveniently neglect” to mention any other reasons that people don’t upgrade. I only provided a *few* examples of excuses that *some* people have used that I’ve read with my own eyes. And this was to illustrate the point that for whatever reason, the WordPress community and developers should do what we can to help these people feel “safer” about upgrading than they apparently do at this time.

And yes, there *has* been some FUD around this issue (in the sense of disinformation). The comments of a certain celebrity tech blogger come to mind. He certainly spread some fear and doubt when he publicly questioned whether he could trust WordPress. But then he admitted that he had not been diligent about upgrading his system, and did not maintain backups.

I am not unsympathetic to your concerns about updates being incompatible with older plugins and themes as the core evolves. I have stated in the past that I wish that when a new feature release was released, that bugfix and security changes would continue on the previous version branch for at least one more normal release cycle (in other words, maintain a stable 2.8 branch after the release of 2.9, and until the release of 3.0, etc.). This would at least give a few months of overlap time for plugin and theme developers to work out any incompatibility issues in a “supported” fashion, without feeling they had to immediately “pull the trigger” for a new version of their code as soon as a new version of WP came out. And it would give running sites a safe window to manage migrations if they find that they are running a plugin that has problems running in a new version of the core.

In any case, the point of the discussion I started was that if people are afraid to upgrade, we need to examine the *reasons* for that fear and begin fixing the processes that create that fear. Where there is FUD, educate. Where there are real problems, correct them. Where there is opportunity to improve, allocate resources to do so.
Dougal Campbell´s last blog ..Most Useless iPhone 3.0 Feature

Still, it’s the security issues that are the bigger focus.

A lot of plugins that haven’t been tested still work. It’s obviously not ideal, but I usually just install them and test them myself.
Ben Cook´s last blog ..Hidden Administrator Attack Hitting Outdated WordPress Sites

“Warning: This plugin has not been tested with your current version of WordPress.”

I’m running the latest version of WP.

So its really easy to complain and moan about a piece of free software that you depend on every second of everyday, but its a lot harder to accept that you need help maintaining it.
Joe Hall´s last blog ..WhosTalkin.com Moves To Media Temple!

In the aftermath of the recent WP worm, there has been the usual raft of FUD flying about. I won’t bother pointing out any particular sources — suffice to say that some of the recent posts about “WordPress Security” were reasonable, and many were not. It seems like every time there is some sort of security issue related to WordPress, regardless of the scope, it becomes a PR nightmare of sorts. Primarily, I think that it goes hand-in-hand with the popularity of WordPress: we are popular, therefore we are a high-profile target, and therefore when something goes wrong, it affects a lot of users, and therefore it gets a lot of attention. It’s the nature of celebrity.

The nature of celebrity? Celebrities have not been entrusted with control of their fan’s livelihoods. Celebrities don’ t promise anything more than entertainment. Wordpress, through its claims, has earned itself popularity, but more so, trust. To scoff at the concern of users who bought the hype about how easy Wordpress is, and how easy it is to use plugins, and how easy it is to download those plugins directly from Wordpress’ own distribution network, shows an incredible arrogance on the part of Dougla Campbell.

For those who don’t recognize it, “FUD” is “fear uncertainty and doubt” and FUD is generally considered fear mongering with inaccurate information, usually as part of a competing agenda. Did I mention the arrogance?

As has been pointed out time and time again, WordPress is easier than ever to keep updated. When a new version is released, a nag appears in the Dashboard. From there, it’s just a couple of clicks to upgrade. And yet, people *still* lag behind. The reasons are varied, and _mostly_ invalid (depending on your perspective). Some of it is simply “fear of breaking something”. Some of it is just simple stubbornness (“I just upgraded, I don’t want to do it again so soon!”). Some of it might be ignorance and laziness (they see the nag, but don’t look at the WordPress News blocks in the Dashboard, or go to the main site to read about it).

Dougal conveniently neglected to mention the other reasons people don’t just upgrade. Like because a previous time they did “just upgrade”, they were nailed with problems that were not fixed until several days later when another release came out, to fix the broken release that had broken their website. Of course they tried desperately to make that first (broken) release work, because they didn’t actually know it had errors until the new new update came out. (the Wordpress developer community seems to be fond of keeping the public in the dark until they are ready to not announce a fix to a broken update, but another update). Like Dougal here, they seem to have no clue about how their own constituents use their software, even though many are using it just the way they have been told to use it.

For working people responsible for websites, that few days of hell between one “bad” update and the next “good” one could at best cause turmoil in the workplace, and at worst, completely corrupt an install.

Or how about the FACT that Wordpress has evolved over time, and many custom themes are not 100% compliant with the *latest* Wordpress API standards? Ever try to get budget approval for a theme rewrite that will look almost the same, but include code changes in line with the new API features?

There are many other of very valid, legitimate reasons why people don’t want to “just upgrade because we told you to upgrade”.

The bottom line is.. Wordpress is NOT easy, it is NOT robust and reliable because of the great community of developers behind it, and it is NOT something to just trust if you are not a programmer. Unless you have a throw-away blog you can just rebuild off a new install whenever necessary, or are a PHP developer capable of wading through the code and developer list discussions… then it is probably awesome.

Unless I am incorrect. I might be; I am just going by my own experiences using Wordpress for several years, and monitoring the dev list and SVN. Your mileage may vary.
john andrews´s last blog ..Google Owns Your Internets

things like ajax dashboards and rssclouds should always be lower down the priority scale. if wordpress needs to call all hands on deck and pull people off of other projects to fix security issues thats what needs to be done
graywolf´s last blog ..How I Got Lost Using Google Maps and the iPhone