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

While stalking people recently, I had a little conversation with Jamison Kelly, who asked,

@michaeltwofish Tell me: what would make a Wordpress geek go to Habari?

Jamison Kelly

It may be a tall order to convince someone who calls themself a 'WordPress geek' that anything else is going to meet their needs, but I'm assuming a willingness to listen. I mentioned a couple of reasons in reply, but I think the question deserves a reply of more than 140 characters.

I think there are great reasons that a WordPress geek might want to move to Habari, and benefit from doing so. These are a few reasons why I think Habari is a good place to be. In the spirit of full disclosure, I should say that I've done much more development on Habari than WordPress.

Community

The first thing that attracted me to Habari was the community, and I've written before about how much I love it. It might not have the size of the WordPress community, but try mentioning some problem you're having with Habari on Twitter, or identi.ca, or FriendFeed. Or drop in to the #habari IRC channel on Freenode (try the LiveHelp plugin if you're not familiar with IRC). The promptness and friendliness of the support is generally fantastic. And I'm not just talking about some peripheral community that's built up around the software, I'm talking about the core developers as well.

Meritocracy

I think one of the reasons the community is so responsive and helpful is that people are rewarded for their participation. This is the idea of a meritocracy, the organisational model that Habari is based on. The people who show the ability, dedication, and willingness to contribute, get given the power to do so. It doesn't matter if that contribution is writing code, or documenting Habari, or marshalling the community, or anything else that benefits the project. The main concrete way that contributions are recognised is through an invitation to the Habari Project Management Committee, jokingly referred to as the Cabal, the main benefits of which are voting rights on the project and commit access to the code base. As of the time of writing, there are 25 people in the Cabal. For a project that had its first developer release less than two years ago, that's convincing evidence of the openness of the project. How many WordPress committers are there ? And where do they work ?

It's a small pond ...

... for now. Being such a young project, the pool of developers and themers is quite small. As such, writing a couple of killer plugins or some quality themes can get you a lot of recognition. By starting developing for Habari early, you can really make a name for yourself as it grows.

In addition, Owen has also written about why theme and plugin authors should choose Habari on licensing grounds.

All of those reasons are soft and fluffy, but there are good technical reasons to use Habari.

An extensible platform

It's incredibly easy to write themes and plugins for Habari. Andrew Rickmann has written a good side-by-side comparison of theming for WordPress and Habari. There are hooks throughout Habari that allow plugins to act or filter based on events. This is much the same as WordPress, though Habari doesn't require that you register your functions. So my action_admin_footer() is the same as my action_admin_footer().

Themes and plugins both extend the Pluggable class, by way of the Theme and Plugin classes respectively. Want to change the way act_display_home() works ? Just define the function in the Theme class in your theme.php file and Habari will use your code instead of core. In addition, the active theme acts just like a plugin, so you write code to can hook events, just like a plugin can.

And if existing hooks don't let you do what you need, you can override system classes. Want to tweak the way Utils::slugify() works ? No need to tweak the core, just copy system/classes/utils.php to /user/classes and change it to work how you'd like.

The ease with which Habari can be extended, customised, and bent to your own evil ends has led one developer recently to implement an issue tracking system on top of it. In three hours.

got irritated by the lack of good, simple issue tracking software written in PHP today. Wrote one on top of Habari in 3 hours. WIN.

Chris J. Davis

Of course, it may be the "WordPress geek" label indicates an emotional position, and not a logical one, in which case I'm really wasting my time. But if you're willing to be swayed, those are some of my - completely subjective - reasons.

Habari users, what are yours ?

<rick_c> when i used wp a lot i used a remote client most of the time. since i'm usually in habari now, i've discovered the reason was i don't like the wp interface.
<rick_c> i've even written in my local habari install, then cut and pasted to my wp blog. :)

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.

While I moved my own blog to Habari a few months ago, I'd been resisting moving my very small number of clients over on the grounds that WordPress is more stable, there are more plugins, it's more well known. However, I was playing with the lazy-k gallery, bending it to my own needs, and that pushed me over the edge. It wasn't anything to do with lazy-k as such—it's a fine little tool—but it just became increasingly obvious as I wrestled that this would be so much easier in Habari from scratch. I was wrestling with WordPress, and I don't feel like Habari requires so much wrestling.

So, instead of lazy-k, I'll write an extension to the Simple File Silo, and when that's done, I'll abandon all support for WordPress and move all sites I control to Habari. It's not like my clients know the difference anyway.

Over on wordpress.com,

... everyone’s free upload space has been increased 60x from 50mb to 3,000mb.

• Free Space to Three Gigabytes « WordPress.com

I can't help but feel that this is a step in the wrong direction for a blogging platform. The assumption is that you're using your blog to manage your media. I would only need that much space because there's no easy way to access the media in the places where I've already got it hosted. If I already use Flickr for my images, if I already use Viddler for my videos, why do I want to manage those media separately with my blog? [Yes, I chose to illustrate my point with the only two media silos implemented so far for Habari. It's only because I'm biased.]

Other than that, I'm sure it will make a lot of people happy.

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 others, of both WordPress and Habari. I've done a fair bit of coding over the years, but I certainly wouldn't call myself an expert. All that said, and not wanting to denigrate WordPress, there are two things that stand out for me that make Habari very attractive. First, writing themes and plugins, even in this very early stage of development, is a joy. I find things "just work" often. To me, that structure makes that hacking a lot simpler. Second, the community is simply awesome. The energy, inventiveness and support that's been flying around just in the last couple of months has been a joy to behold.

Frankly, I don't care what's happening on other projects. I'm just enjoying working on this one, even in a very minor way.

(I do think Habari could use some more tests. I don't have much experience with testing, but if someone sets up the framework and a couple of examples, I'll certainly add a bunch of tests.)

Thanks to concise advice from Owen Winkler (aka ringmaster), my test Habari install now has the same URLs as my existing WordPress blog. That means that when I move, all my links will still work. It would have been a pain to redo all my internal links, but those three sites out there in the wild web that link to me are really valuable ...

For reference (lines wrapped for clarity): INSERT INTO habari__rewrite_rules (name, parse_regex, build_str, handler, action, priority, is_active, rule_class, description) VALUES ('display_entry', '%(?P<year>\\d{4})/ (?P<mon0>\\d{2})/ (?P<mday0>\\d{2})/ (?P<slug>[^/]+)[/]{0,1}$%i', '{$year}/{$mon0}/{$mday0}/{$slug}', 'UserThemeHandler', 'display_post', '8', '1', '0', '');

[Update: Don't copy and past the query above, you'll get spaces in your regex that break it. Use this text version instead. Also, make sure you change the table name to the correct prefix, habari__ is the default and most likely.]

Now that WordPress comes with tag support, you might have posts that you only want tagged and not categorised. To set that up in the Connections theme, you'll need to set up a category that you don't want displayed (I used 'Uncategorised' and no, I don't live in America, thank you), and edit post.php. If you enabled tags by following my instructions for enabling tags in Connections, you'll have some code like this: Posted by <?php the_author(); ?> under <?php the_category(' '); the_tags(', tagged ', ', ', ''); edit_post_link(' (edit)'); ?>

The call to the function the_category() outputs a link to the category page for each category under which your post is filed. To output categories conditionally you don't want to output them directly, so you need to use the get_the_category function, which returns an array of category objects. I'll ignore the fact that the function calls should really be plural. Replace the code above with the following code.
Posted by <?php the_author(); ?> <?php $categories = get_the_category(); if (!(count($categories) == 1 && $categories[0]->cat_name == 'Uncategorised')) { echo " under"; $category_url = get_option('siteurl') . '/category/'; foreach ($categories as $category) { echo " <a href=\"{$category_url}{$category->category_nicename}\">"; echo "{$category->cat_name}</a>"; } } the_tags(' tagged ', ', ', ''); edit_post_link(' (edit)'); ?>

Unless there's only one category and it's the one you don't want to display, you want to output the categories. Basically, you need to manually build what the_category builds automatically. Again, I'll ignore the terrible category method naming, some cat_ others category_.