echo "hey, it works" > /dev/null

You should never ever modify core files in WP. If you find you have to, file a ticket for a new hook or filter so your modifications can be a plugin — it makes things so much easier.

• Photo Matt » SecurityFocus SQL Injection Bogus

The security report may well be bogus, and Matt gives some reasonable advice for avoiding security issues, but I think this is a bit rich. Never ever. Emphasised. Okay, go and open a ticket, it will all be fine. I'm fairly sure that the WordPress terms of service (no, no, we're talking about the self-installed software, don't go looking at the WordPress.com terms of service) don't say anything about guaranteeing tickets are addressed in X days. Of course they don't, Automattic is not a support company for self-hosted installs unless you want to pay for "enterprise-level support for large-scale users".

As of this writing there are 944 open tickets, dating back to the start of 2005. Many of those are enhancements, some trivial, some critical. What's going to happen to your ticket? If it's a critical security or data loss issue, it may well get addressed immediately, as I'm sure the original SQL injection attack ticket would have been if there'd been more information, and if it actually exists. Those don't come up very often, and it's likely that it will take a while before your ticket gets addressed. Maybe I'm wrong, and requests for hooks or filters do get addressed immediately, but then you either have to be running out of the subversion trunk or wait for an upgrade anyway.

Now, I am absolutely not criticising the fact that there are lots of open tickets. That's the way things happen in open source software, and to a certain extent it shows the software is a success. But it is unreasonable to suggest that just because you've opened a ticket the problem will go away and you'll never have a reason to change core code.

Chris J. Davis has started working on some image editing software focussing on imagery for the Web. The working title of the project is Simpleshop, because the impetus is the huge number of unused Photoshop features when you only use it for Web images. Knowing Chris, Simpleshop will be a complete misnomer before long and the application will definitely be doing it's own thing rather than simply being a cut-down version of the other 'shop. Chris will open source the project when he has a working prototype.

Owen Winkler has responded to Jacob Santos' post outlining why he wouldn't move to Habari with a point-by-point attempt to change Jacob's mind. Owen was a long-time developer of WordPress and a founding member of the Habari team and so has much experience of both communities. I've only been involved with Habari for a short time, after paddling around the edges of WordPress for a little while, so my perspective is much more as an outsider. Jacob complains about the complex file and directory structure of Habari. I've hacked the core, worked on themes and plugins, from scratch and extending ...

[read more]

Donal asks me, "Why will [Habari] be better than WordPress?" Habari may or may not be better than WordPress, but I'm not sure that's really the right question to ask in my case. While Habari is a lot younger than WordPress, it's been developed from the start with a solid vision by people with a lot of experience with blogging software. That's all good, but it's still not why I became involved. Okay, maybe obsessed, but that's who I am. No, it's because Habari has an open, welcoming and vibrant community, and I feel like I can make a real ...

[read more]

[Making OSS UIs work]

Do 1. Get a Benevolent Dictator 2. Make the Program Usable In Its Default State 3. Design Around Tasks 4. Write a Plug-In Architecture 5. User Testing, User Testing, User Testing!! Do Not 1. Develop Without A Vision 2. Join the Clone Wars 3. Leave the UI Design Up To The End User 4. Make the Interface a Thin Veneer over the Underlying Implementation 5. Treat UI Design as Babysitting Idiots

• Humanized > Weblog: Ten Ways to Make More Humane Open Source Software