openswitch

Since switching back to WordPress from Chyrp there have been a lot of people asking me questions. Thankfully none of them have been about the soundness of my mind (which is easily questioned). That’s probably due to the fact that by this point the vast majority of my readers have accepted that I’m always going to be trying out new things and switching stuff up around here. Which reminds me, if you haven’t already, I highly highly encourage you to make sure you’re subscribed to my FeedBurner feed (http://feeds.feedburner.com/openswitch) because that way no matter what goes on with the physical site you’ll always be up to date via the feed as the FeedBurner address will never change. Well, unless FeedBurner goes under but I don’t see that happening any time soon.

So back to Chyrp and why I’m not using it. First of all, there’s nothing “wrong” with Chyrp per se. Seriously. It’s very well coded from what I can tell and it has a fair amount of modules (a.k.a. plugins) and feathers (which let you write different kinds of posts like reviews and such). Alex, the lead developer, is a great guy who answers support questions quickly. I never had a problem with Chyrp that couldn’t be fixed. It worked just as it was designed to: simply.

Though its simplicity is what drew me to Chyrp, it also pushed me away. I guess I needed a bit more from a CMS. WordPress remains much more than I need but Chyrp just wasn’t enough.

Things I need in a CMS which Chyrp does not yet include:

• Simple (read: I don’t need to mess with MySQL) database backup solution
• A very large developer base
• Page caching ability
• Being recognized by other CMS’s

Now, I’ll bet dollars to donuts that Chyrp can and will in the future accomplish all of the things I just listed. But as of right now it hasn’t and that’s important to me.

Simple database backup solution

I’ve got over three years of posts and articles in my database. I’d cry if something happened to them. WordPress and Textpattern both have simple database backup solutions and that’s very important to me. I’d love to see Chyrp have this feature soon.

A very large developer base

This, admittedly, has everything to do with FUD on my part. I want to know that my CMS isn’t going to die a quick death should one person decide to drop out of the process. Now, I have no reason to believe that Alex will give up on Chyrp. From all appearances he’s in this for the long haul. But it’s not beyond the realm of possibility.

I understand that the nature of OS software is that it’s not dependent on one guy, but a community. Yet I’m not sure that Chyrp has a large enough community to pick up the project. And that scares me.

The argument could be made that WordPress rides on the back on Matt, but I believe that if he were to drop out of the process there are more than enough people to pick up and run with the ball. So I suppose this boils down to “I only use popular CMS’s”. But I think it’s with good reason I do that.

Page caching ability

It’s simple, I want some level of caching ability in my site. My host (whom I love) keeps track of the strain my site puts on its CPU and the fact of the matter is when a CMS has to process all the PHP every time it gets a page view you can quickly rack up on that stuff. Most notably with Chyrp was my archives page. When it generated a list of every post I’ve written in the past three years I could literally hear the server CPU groaning under the load.

Being recognized by other CMS’s

This is more important than you would initially think. Imagine that my worst fear came true, that Alex dropped out of Chyrp or (God forbid) something unplanned happened to him and development on Chyrp stalled dead in the water. Then, a security exploit was discovered but there was no one to fix it. Well, common sense would say in that situation I should move to another CMS. But the problem is importing all your Chyrp posts into that new CMS easily. WordPress recognizes a certain set of CMS’s and will import your old posts from them into WordPress at a click. Chyrp is not one of them.

Basically, it comes down to this: a small development team increases the risk of project stall. A project stall would be bad, but not being able to easily import my old posts to a new CMS would be worse.

Other thoughts

There are a few other less pressing issues I had with Chyrp. Well, not “issues”. They were really just instances when I wanted to do something the CMS wasn’t built for. Remember, it’s built for simplicity and tumblelogging. To upload an image while writing I needed to be posting a photo. If I was writing a text article and wanted to upload and insert an image I had to fire up my FTP client . . . annoying.

Editing certain files was annoying. If I wanted to recode how comments were displayed, for instance, there is no PHP/XHTML file for me to edit like with WordPress. I would have to go in and edit the plugin itself. Granted, the plugin was coded in PHP but it’s a bit more complicated than what I can do. You see, Chyrp does not come OTB with commenting ability, you have to add a module. I like that; not everyone wants comments. But the problem with this setup is the comments were inserted on the fly (for lack of a better term) into the post. This just makes it very difficult for a fellow like me to change the way comments were coded and/or displayed.

No collection of template tags. I briefly spoke with Alex about this on the community forums, and he’s got in the works a much more simple templating engine which I’m really looking forward to seeing. But it was very frustrating for me to not have a resource available which laid out all the tags that could be implemented in a Chyrp blog.

Conclusion

I’ll continue to watch Chyrp’s development closely. It’s young, and at one point I’m sure WordPress was in this stage too. Alex is extremely talented as well as being a stand-up guy. I want Chyrp to succeed and should it evolve a little more I’ll strongly consider moving back to it.