Written by an experienced regional financial controller, the blog is filled with nuggets of information you’ll be hard pressed to find elsewhere. Samples of documents and agreements are but a glimpse of the knowledge you could glean.

Yes, I’m not joking.

And yes, our host isn’t one of these hosts that keep up with this kind of relatively minute mySQL updates. Apparently, many hosts haven’t resolved this problem either - leaving quite a number of frustrated MT users (normally office users). In fact, even when this “isolated bug” is resolved, other errors could as easily pop-up.

Switching hosts is an alternative, but it’s an irritating one. How we wish we could just abandon MT for WordPress right now! Now, that’s a great piece of trouble-free, and financially-free software.

P.S. A blog platform switch isn’t practical given the SERP losses that we would have to shoulder.

Adding a screenshot or the blog logo would probably also be part of such an endeavour. But the real question is how long should the description be. So far, we’re thinking of one paragraph. That is probably just long enough to give a brief (and hopefully, catchy) description of the blog, without inundating our dear readers with stuff they could easily find out by visiting the blog itself.

But until the design of the proposed over-the-header navigation bar is completed, this “description listing” will have to wait (agonizingly) on our To Do list for this blog.

So, why the free articles? Well, we’re doing this as part of an experiment with search engines and free articles. There have been conclusive tests before that have proven that free articles are usually not indexed, and even the originator of the articles could end up being excluded by top search engines like Google and Yahoo! - though MSN seems to be more adept at determining the source of the free articles.

After about a month of posting, and another month of rest, we can report that The Fishing Rod has only had its main page indexed by the search engines. Yes, only one page. The free article permalink pages have completely been avoided. But the once empty Google adverts have begun populating a bit more across all the pages, even though those pages are not shown in the SERPs. We’ve had a few odd advert clicks here and there as well.

In any case, one month is still too short a time period for an experiment such as this one, so we’ll probably be keeping it going for quite a while longer. This means that posting will be restarting soon enough.

Recently, we’ve been thinking of putting up AdBrite on a “network”-wide basis - though is-there isn’t a network per se - which will result in the same AdBrite adverts being shown across all is-there blogs. The benefits of this are obvious: More impressions, clickthroughs and thus, lower ACPCs for advertisers, making each advertising deal more advantageous. More advantageous deals then tend to attract more advertisers.

But the downside is equally clear: Adverts will be contextually irrelevant across many blogs due to the “network”-wide nature of the advertisements. Just look at b5media’s implementation of this to see what I mean. There are advertisements about plastic on entertainment or even blogging blogs like Problogger.

So, it’s clearly going to be pretty hard balancing revenue vs. relevance when such an advertising system does get implemented. However, that is unlikely to stop us from trying it out as “network”-wide Adbrite ads would definitely allow us to access a larger advertiser market.

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.

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.

Here goes:

1. is-there:   WordPress 2.0.1 (previously Drupal)
2. Anime Field:   WordPress 1.5
3. The Acer Blog:   WordPress 1.5
4. House of Dell:   WordPress 2.0
5. GuPiano:   WordPress 2.0
6. EssayRep:   WordPress 1.5
7. FMAccounting:   WordPress 2.0.1
8. Towards Uni:   Movable Type 3.2
9. Lasik World:   Movable Type 3.2
10. CDC:   Movable Type 3.2
11. ZMAng.CV.vc:   Blog:CMS

As you can see, most of the is-there blogs are running WordPress - with quite a few of them still at WP 1.5. This does mean that upgrades to WP 2.0.1 are on our to-do list, but…

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.

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