I'm happy things are back to normal on this site after yesterday's permissions headaches. But for a good part of yesterday I was ready to chuck my beloved Drupal for something else. All day yesterday all I could think was, "life's too short to be wasting on tinkering with web publishing software." Alas, it was a single module that was the culprit and I'm back, but not without coming very close to leaving Drupal.

Casting about for a quick fix, I downloaded WordPress last night and migrated my blog over to it. Was really quite simple. I found this process documented on vrypan.net. Worked pretty well, but his process didn't work for me on the first try. I modified his process and SQL statements a little to make this work for my system.

The first time I ran these SQL statements, a bunch of my node categories weren't carried over correctly. To correct this, I flattened my hierarchies by making all the terms have a parent of 0. This kept the categories attached to each node correctly.

Then I noticed that comments were all entered as anonymous. So I modified the SQL statements for the comments table a little so that commentor name, email and homepage are carried over as well.

Here's my new process:

1. Backed up Drupal database using mysqldump:
   

   mysqldump -u [username] -p -h [hostname] [databasename] > drupal.dump

2. Loaded dump file into a new database:
   

   mysql -u [username] -p [newdatabasename] < drupal.dump

3. Flattened taxonomies in MySQL:
   

   UPDATE term_hierarchy set parent=0;

4. Downloaded and installed new Wordpress system
5. Configured the new WordPress system to use the new database that is now loaded with my backed up Drupal database.
6. Ran these SQL statements
   

   DELETE FROM wp_categories ;
   DELETE FROM wp_posts;
   DELETE FROM wp_post2cat ;
   DELETE FROM wp_comments ;

   INSERT INTO wp_categories(cat_ID,cat_name, category_nicename, category_description, category_parent) select term_data.tid, name, name, description, parent from term_data, term_hierarchy where term_data.tid=term_hierarchy.tid ;

   INSERT INTO wp_posts(
   ID, post_date, post_content, post_title, post_excerpt, post_name, post_modified
   )

   SELECT nid, FROM_UNIXTIME(created), body, title, teaser, concat('OLD',nid), FROM_UNIXTIME(changed) FROM node WHERE type='blog' OR type='page';

   INSERT INTO wp_post2cat (post_id,category_id) SELECT nid,tid FROM term_node;

   INSERT INTO wp_comments (
   comment_post_ID, comment_author, comment_author_email, comment_author_url, comment_date, comment_content, comment_parent
   )

   SELECT nid, name, mail, homepage, FROM_UNIXTIME(timestamp), concat('',subject, '
   ', comment), thread FROM comments ;

7. Done

The results were pretty good. I would have to create another set of SQL statements to move over the weblink tables as well. I started exploring the WordPress administration and began to feel the satisfaction with working with a separate administration panel again (boy do I wish that were still an option with Drupal).

Then I started my superficial exploration of how things worked. Things seemed pretty cool. Creating themes and installing modules/plugins are probably where I spend the most time modifying a blog system. I probably wouldn't be put in the largest category of bloggers -- those who just install and publish. I customize and configure a little. I'm not a developer either, but I can modify perl and php code or create my own very simple modules/plugins. So I'm in some middle category, which helps me understand the needs of novice bloggers and those of developers when it comes to using blog systems.

Theme administration looked easy and was not abstracted in WP. The basic idea was that you copied or created a new writable theme directory in wp-content/themes/ and put all the theme files in there. The administrative interface provides forms for editing the files. Not very sophisticated, but simple enough.

The first thing I did was look through these PHP files and try to figure out what I could do there. I specifically wanted to see how the Kubrick theme was putting out the catgories. In the sidebar template I found a function call for list_cats(), a function that took 17 arguments. Yikes. Then I went poking around for it in docs and found some documentation. All of the Template tag docs were great. I found their docs to be pretty easy to explore, but their set of documents is quite smaller when compared with the Drupal Handbook and the separate Developer's Documents. It's interesting to compare the two. The doxygen documentation and the new drupaldocs site make it easy to find your way to known items, but this particular tool for searching documentation is very much for programmers.

I'm sure there are a lot of Drupal users like me -- regular bloggers who don't want to know too much about what's making things work on the backend, but who also need to be able to do a little bit more than display a reverse chronological diary. I find that at difference times I need ease of use in finding readable documentation to figure out how to do things. But at the same time, I'm willing to give up some of that ease of use for more flexibility and functionality even if it means working in a more cryptic environment.

This all reminds me of a usability dilemma I've come across in the past. People will often sacrifice a little ease of use for functionality, price or whatever makes it worth the loss of ease. It's why a lot of people may decide on a sub $1000 PC laptop rather than a Mac 'Book. You determine the point where you give up one for the other. And that's where I am. I so desperately crave ease of use and management. But, I don't see a super simple blog package out there that let's me do the things I want to do, how I want to do them. (Realize that the "how I want to do them is what may separate my choice from yours.) Specifically, as you may have noticed, I get geeky with information description (taxonomy use) and I've got a personal weblink directory that's probably larger than the average blogger's bookmark list. Today it's got 734 links in it, and every one is categorized using the same subject taxonomy that I use to describe my blog entries. And there are RSS feeds for each category. It's pretty damned cool that I can do these things I consider simple, but necessary by just using built in functionalities and in this example, two easy to install optional modules.

This is the stuff that helps with my professional development. Personal knowledge management for me comes in the way of using my subject-classified weblog and linklog to retrieve and synthesize what I learn, observe or use. Drupal has made this possible, but I could have easily, although perhaps more cumbersomely done this in any other tool. But, after having used Drupal for the last 4 years, I think I'd find any software lacking if it didn't have the rockin taxonomy guts to tie it all together out of the box and the modules to make more sophisticated browsing and retrieving also possible.

And finally, the real thing that made me realize why I want to stick with Drupal was only revealed after I actually did look a little bit more at how WP was architected. I thought it was put together very much the way I might put a small application together right now. You know, I actually did roll my own set of light publishing scripts once for a site I did back in '99. It's an experience worth undertaking. But after working with Drupal I am able to appreciate the way things are architected there. Often I learn new ways of doing things just by figuring out how they're done in Drupal. I have the same experience at work where I figure out how some of the Perl stuff our programmers make works so I can use that knowledge in writing the little Embedded Perl pages I write. I think this is ultimately the reason I want to stick with Drupal for now. The idea of working with something that will be a challenge and will force me to learn to do things more elegantly and efficiently is somehow more attractive than using something that simply works and is usable but doesn't do much in the way of changing me more profoundly.

This has been a really odd blog post. I started out in some respects documenting how to migrate away from Drupal and in the end I'm starting to tell you why you wouldn't want to.

I really don't think it matters much what anyone chooses to do their personal publishing. I applaud anyone who tries to do personal knowledge management with software, and open source blog tools in particular. In the end, the choice becomes religious. You choose the one that you believe will deliver what you need, with the features and requirements you can work with, and the level of usability you can tolerate. After my brief taste of the other side, I'm back again to Drupal. It was a 1 day departure. Sometimes you have to go away to find your way back home.