As I look at the planned features for WP 2.7 as reported by Weblog Tools Collection, I’m having a few thoughts:

1. I noted on the 27th that it made sense that WordPress would be hosting themes at wordpress.org/extend to allow for ease-of-upgrading, and it looks like a Theme Update API will help with that.
2. Plugin management and overall WP upgrade management is improving. That’s a net win for everything WP-related, security most of all. [Same goes for theme.] Making users aware that software is due to be upgraded and making it easy for them to do so is what’s going to help solve WordPress’s reputation as a black-hat scammer’s favorite target.
3. There’s still no love for an AJAX-ified TrackBack tool entry. It’s still “(Separate multiple URLs with spaces)”. Criminy.
4. A side benefit of hosting the plugins on wordpress.org/extend is that the WP folks can see which plugins are truly getting the most use. It looks like things like comment threading, XML sitemap generation, and comment subscription are going to make their way into the core codebase. Now, there is an argument to be made that leaving these things to plugins is just fine—that WP’s core should have the absolute minimum number of functions involved, and that anything but basic functionality should be left to plugins. There are many arguments to be made for this philosophy pro and con, but I think that, at the end of the day, WordPress should bring in the most popular plugins into the codebase. Why? If it’s terribly popular, it’ll be seen as quasi-official, and anything that’s gotten that level of praise in the community needs to have a more stringent security review than relying on a third-party developer. Note: This is not a slam on 3rd party devs at all. It’s actually a praise—if you’ve gotten that popular, it’s a good thing. Now, one can argue whether WP’s security reviews and patches are stringent or swift enough [and the answer to that seems to be that there will never be a time when everyone is satisfied by either], but if WP brings it under the umbrella, they’re saying, “This is mission critical.” Also, it reduces user/administrator workload in keeping plugins up-to-date.
5. All that said, it surprises me that Akismet is still a plugin and not a part of the core for this very reason, and I say that as an avid fan of Spam Karma, a financial contributor to same, and someone who considered, briefly, helping the GPL project along from a management / usability review perspective. [That's before I told myself that I didn't want to make the time for it.]

As WordPress progresses towards full-maturity—right now, it’s out of college and in its first job, making lots of dough and acquiring lots of stuff—these are all good things. I’m still very much a happy WordPress supporter.

Well, my request for an agreeable openness went nowhere. :shrug: We have our WP 2.2.3, and it fixes the issues that Alexander and others raised. That is very good. Thanks, guys. And for the record, it was 16 days between notice and release. Very good.

Also, the news about the betas has been great. Beta 3 of WP 2.3 is the last one that’s going up, and the new version should drop on Mon 24 Sep [presuming it's ready; if they miss the date, it's not a big issue, eh?]. These are the questions I have about it, though:

1. Will 2.2.x get any support if security holes are found? 2.1 didn’t, if you’ll remember from the 2.2 release notes, but the jump from 2.2 to 2.3 is going to cause some breakage, I think, and that always slows adoption. I’d hope that a reasonable amount of security support would be provided. I’m not expecting that it’ll be kept up forever, but for say, maybe, a month?
2. Are we going to see a roadmap again? That was always fun.

Well, again we’ve got folks claiming to have found a remote SQL injection in WordPress, one that affects all versions. At least the discoverer, Alexander Concha, did the right thing: notifying the WP folks. He’s chosen not to disclose information about the hole, which means one of two things:

1. It’s bogus.
2. It’s heinous.

Because I’m weird and like to know about these things, maybe I should just ask Mark Jaquith about it, considering that he was great in discussing the WordPress “worm”. Matt’s probably still busy defending himself against straw men, anyway.

So, how about it, boys? Can you address the question? Or will it just be four weeks between notice and release without much comment otherwise? Yes, yes, yes, I imagine that I could look this up in Trac, but I’m an aerospace engineer, not a computer one; your PHP is as fuzzy to me as my Navier-Stokes equations likely are to you.

Lest you think that I am anti-Matt here, I’m not, because I think Duncan Riley was being an ass. Implicit in that comment is agreement with Mark Jaquith’s comments on the saga, especially:

Matt made a huge mistake by allowing [all the SEO-optimized crap on WordPress.org]. I was disappointed in him at the time, both personally and professionally. But he’s learned from that mistake. More than that, he’s lead efforts to warn others about that kind of behavior. That’s what the whole “sponsored themes” thing was about. That’s what the Vanilla comment was about.

See, exactly. While I have butted heads with Matt, I always find him willing to listen. That’s why I’d buy him several, several beers if we ever ended up in Houston at the same time. [Note to self: next time you're headed to JSC for work, ring Matt up.]

Back in July when I last wrote here, Matt asked:

What exactly do you want us to say?

If it’s important, then we’re working as fast as we can to get a release out and promote the heck out of it. (Think 2.1.1.) If we consider it low priority, then it waits for the next regular release, but we get raked over folks who think every little problem is the sky falling.

I think I’ll answer by saying, “What Mark posted about the WordPress Worm being bandied about is exactly what I want to see, Matt.” All I really want to see is, “Yeah, we see the bug; yeah, we’ve got a fix; no, it’s not that big of a deal.” If the bug-reporters have a disagreement with that, you’ve opened the floor for discussion, and as long as you’re cool in how you respond to the discussion and stick to the facts and don’t sling FUD about, things’ll be just fine.

There’s a vulnerability in WP 2.2.1. BlogSecurity is who brought it to my attention. After being burned by vulnerabilities before—and having gotten absolutely slammed over the weekend with HTTP requests—I worry about this security hole.

Note: Coblentz discovered the bug on 21 Jun reported the bug on 22 Jun. When did WP reply? 5 Jul, three days after a second notification. Indeed, the first notification came the same day as Matt Mullenweg raked Wincent Colaiuta over the coals.

Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.

Indeed, it is. In fact, it’s possible that there are other security fixes in the works for WP 2.2.2, ones that have been reported to the devs and not put out on SecurityFocus. Maybe WP 2.2.2 drops tonight. But in the meantime, I have a nagging worry and no response. Unsettling.

I’ve found BlogSecurity’s WordPress Scanner to be invaluable for me; I’ve recently brought a bunch of installs up to current, but I hadn’t considered the vulnerabilities in XSS attacks on templates. But now that I know that those have holes, too, I can patch them up.

Go give WordPress Scanner a shot: all you’ll need to do to let it run is to put <!-- wpscanner --> somewhere in your template. I’d suggest putting it in the Header, where any page that WordPress Scanner comes across would have access to the statement. That way, all pages can be scanned for vulnerabilities. Just be sure to remove it after the scan is over so some black hat can’t use it against you!

It would be awesome if WordPress would include a post-upgrade scanner into the mix, checking your theme for possible holes. Upgrading WP only fixes the core files—any template you’ve used other than the default isn’t going to get fixed, and it could have a hole.

Back when I saw Wincent Colaiuta’s strident slamming of the security holes in WordPress 2.2, I commented, “I think Colaiuta overstates his case here, but the point is taken: this should have been pushed out faster.” I brought it up with Stephen at lunch yesterday, and we talked about some of the issues at play here. I think that they are:

1. Self-hosted WordPress installations not making a big enough deal to the end-user that their install is out-of-date.
2. A lack of a regimented test case suite on multiple platforms [Apache, IIS, etc.] to root out any bugs in release candidates.
3. The delay between discovery and patch release.

WordPress founder Matt Mullenweg has angrily responded. I’m a bit disappointed in Matt, because he takes every opportunity to take digs at Colaiuta’s platform of choice, rather than calmly and rationally dissecting the argument that Colaiuta made. This is perhaps understandable, as WordPress is the foundation of Matt’s career, but for him personally and WordPress in general, I wish that he’d responded with more grace.

• # The SQL problem in 2.2 requires both registration to be enabled (off by default) and the blog to be upgraded to 2.2. It is a serious problem but I’ve heard of fewer than 5 exploits from the flaw. Even if you assume there are 100 blogs for every one we heard about, that’s still an incredibly small percentage of the millions of WordPresses out there, especially considering, as Wincent points out, the problem has been in the public for a while now.
• Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.

Those are the salient points here. The first is pretty important: the flaw was only vulnerable if you go away from WordPress’s defaults. The chances are that the users who are too lazy or unaware of the risks to keep their software up-to-date aren’t going to have changed many of the defaults. I run a community of Webloggers using self-hosted WordPress installs, and I can tell you that very, very few of them—maybe 5%—have ever done anything different than the default options.

The second point is important as well, although there’s not enough apparent testing to me—as a power user who sorta half-monitors wp-hackers, albeit with less frequency right now because I’m covered up with work—to be sure that this is fully the issue here. I don’t have a problem with a quick #.#.X release for a bug such as this, because good tools to keep your installations up-to-date exist. When 2.2.1 was released the other night, I patched 30+ installations in under a half-hour across as many domains on my server, all by hand. [The "40 minutes" comment is how long the 2.2.1 release had been out in the wild.] When I finished upgrading all my RMFO-Blogs users to 2.2.1—the re-architecture took quite some time, and had bitten me in the ass by running 2.0.2 [!] for months and getting my server 0wn3d—today, I went and upgraded about 30 users whom I’d already gotten up to 2.2 in about 15 minutes—again, by hand. I’m working on a shell script to automate this and make it much, much faster for me.

The big thing that’s come to mind for me lately is that WP needs to set an annoyance factor for release updates. At present, WP includes your version at the bottom of every page in the admin—which is good. That’s not enough, though. If you’re running an outdated installation, WP ought to bitch at you every opportunity it gets. How? There ought to be a banner at the top of every single WordPress admin page, using that lovely yellow-fade-to-blue status notice, that annoys the crap out of the user by letting them know that their installation is outdated. If I had that for my RMFO-Blogs users, I can guarantee that this would have them banging on my doorstep to do an upgrade for them. Another possibility is that any WP installation that’s out-of-date could, using WP-Cron, send a daily email to the administrator email address, advising them that their installation is out-of-date, and providing them URLs on where to download the files to upgrade and providing help pages for upgrading.

Security is a serious issue. It should be treated soberly. Matt’s angry, unprofessional response—choosing to sling a lot of mud at Movable Type—simply muddies the conversation. I had hoped for better from him. I do hope that we’ll see better in the future.

As Joe Gregorio notes, WordPress was supposed to support Atom 1.0 starting with the 1.6 milestone [which, as I recall, never happened and became 2.0]. Mark Pilgrim is frustrated, too. So am I, but this should be a surprise to exactly no one.

But being one to work within the system … there’s the new Ideas forum, and well, there’s a topic to support Atom 1.0 support in the next release. I’ve already chimed in. Go rate it up. If we all rate it up, perhaps it will become a priority. [It should be, anyway; WP is shipping to a deprecated version of a specification, something really outside the main WP ethos.]

I complained nine months ago about the lack of Atom 1.0 support in WordPress. It’s still a bit stunning to me that, a few releases later, WP still doesn’t have that support. But today, Sam Ruby pointed to Benjamin Smedburg’s plugin that generates Atom 1.0 output for WordPress. Huzzah!

I’ve gotta say that I find ticket 2972 to be wonderfully right-headed:

Currently, the most recent page (in any of the archives — dated, categorized) is page number 0. When clicking on Next Page, the url shows it being paged=1, thus page number 1. Going back even further, the page numbers increase.

However, when new posts are added, all the content in the pages shift with it.

In my opinion, it would be better if the oldest posts would be on page 1. This way, if new posts are added, consequently new pages are added. AND the content of the pages stay the same.

It’s all about future-proofing, and that’s a very, very good thing.