Anyone using Dreamhost should (or rather, must) know that the rewrite rules in each new CMS (Content Management System) installation (including Dreamhost’s own One-Click Installs) will break access to Dreamhost’s statistics package. And why should anyone care about the stats package that Dreamhost provides? After all, Dreamhost only provides Analog. But the Analog isn’t the important thing. The important part of the stats package is the CPU usage statistics provided by the stats package.

All shared hosting packages in Dreamhost come with 60 minutes of server CPU usage (at the time of writing of this post). Exceeding it will generally mean isolation into a special “containment” server, and maybe even account termination. Therefore, knowing how much server CPU usage you’re using is terribly important.

So, how do you restore the “broken” stats package? Simple: Click into The Relevant Page in the Dreamhost Wiki! After that, just follow the simple instructions of adding a few lines into your root .htaccess file. At least, that’s what was needed for this blog.

We talked about a To-Do list just one post before this one, and thought of sharing our To-Do list, but just for this blog. If you’ve been a regular of the previous design, you would have noticed several features missing in this incarnation - namely, feed aggregation from the rest of the is-there blogs, and a suitable blogroll.

Hence our To-Do list:

1. Dedicated feed aggregation page. Given our love for 2-column designs, it isn’t likely that we’ll be adding a third column just for is-there feeds. Therefore, it is likely that we’ll setup a separate feed aggregation page which will serve your needs better.
2. Dedicated links page. While this isn’t a network at all, we’re thinking of putting up a links page for the is-there blogs, rather than just stuff them in the sidebar. Though it is likely we’ll still add a footer blogroll to share the Google PageRank juice from the index page.
3. Header bar design. We’re thinking of adding a header bar (not a header replacement) above the normal header itself. It’ll be something like a navigation bar, so nothing surprising there. Among the pages that will be linked to include an advertiser’s destination page, design notes, and probably a couple of FAQs.

And… that’s it for now.

At this stage, you must have noticed that is-there.net has migrated from Drupal to WordPress. Why? Well, we have a number of reasons, some petty, to a few rather major ones:

1. Drupal’s anti-spam modules were failing on us. Even with both the Bad Behavior and Spam modules installed and activated, spam bots were still hitting on the site. Customizing the modules was possible, but…
2. Drupal wasn’t the most suitable CMS for a relatively non-group blog like this one. Generally, CMSes like Drupal are used for community sites and group blogs like Performancing, due to the multitude of features provided for such applications.
3. Drupal: Feed updating through cron jobs wasn’t working. Wierdly, the daily feed updates weren’t going through, forcing manual updates - which if you noticed, were occuring sporadically. WordPress offers plugins that work out-of-the-box, though it must be said that substantial effort was made in trying to get Drupal’s aggregator and aggregator2 modules to work properly.
4. Drupal was relatively CPU intensive - This isn’t really new if you’ve been keeping up with the Drupal forum. We’ve noticed a few threads addressing Drupal’s relatively high CPU usage as well. Of course, we’ll be the first to admit that WordPress isn’t the poster child for CPU usage either, but it’s still better than Drupal (in our experience, that is)
5. WordPress offers far more plugins - providing greater “one-click” customization. Now, this is probably still an understatement. Just subscribe to wp-plugins.net’s RSS feed to see the pace of updates in WordPress’ plugin community. And not all plugins go through wp-plugin-net.
6. Drupal’s admin interface just wasn’t cool enough. Admittedly, we place quite a bit of emphasis on GUI, and WordPress just won by a mile. Let’s not forget the wide range of admin skins that the WordPress community has created too (e.g. Tiger Admin).

That’s about it for now. We’re sure there are quite a few more, but they don’t come to mind at the moment. If we happen to remember more reasons why we switched from Drupal to WordPress, you’ll be the first to see the Part 2 of this series.

Drupal somehow konked on us, so we’ll be switching back to WordPress ASAP. So, till then, please bear with us.

P.S. There are a number of other reasons why we’re switching to WordPress, but that’s definitely content for another post.

All the is-there blogs recently experienced severe downtime (more than 24 hours) due to hardware problems on the host’s side. However, I hope I can say that the problem has been resolved and that this should not reoccur anytime soon.

Hopefully, the downtime did not inconvenience regular readers of each and every one of the blogs (too much). I would like to say sorry for the downtime and thank you for your continued support!

P.S. I’m still not sure exactly what caused this downtime yet, given that the host’s support side has yet to reply.

Well, I’m targeting this blog as my do-it-all blog, where I post anything that happens to be related to my everyday progress as a newbie blogger. In fact, using Drupal is an experiment in itself since I am using WordPress (primarily) and Movable Type for my blogs.

So, I’m not sure what to tell you to expect given that I’m not sure what I’ll write yet. But in any case, thank you for visiting. Hopefully you will find something that interests you.

Oh yeah, the links up there on the header are the blogs I’m currently working on (most of them at least). You can say that I should probably concentrate on my primary blog first before tackling others, but I’m the type that gets too worked up over small details. A solution, therefore, is to busy myself with multiple blogs.