chris's random thoughts

Drupal travels pretty well — here’s how to do it.

1. If populated, truncate the local instance’s ‘cache’ table. Naturally, I didn’t do this before exporting. In addition to causing issues on the target server, I could have saved some bandwidth by doing this earlier than I acutally did.
2. Create a new database on your target server.
3. Export your local instance’s Drupal database.
4. Import the dump into your newly created target server’s database instance. I gzipped the database export using a newer version of phpMyAdmin than my hosting provider does, and had issues. This was resolved by rexporing using no compression.
5. Modify $DRUPAL_HOME/sites/default/settings.php to reflect your target server’s settings
6. FTP your local instance’s files to your target server.

In optimal conditions, this works. However, on my target environment, I have a couple of unresolved issues beyond my control:

1. Clean URLs don’t work. As I do not have access to httpd.conf, I can’t make the changes outlined in my previous post. This necessitated changing all of the inter-page links to the ugly ‘?q=’ hrefs. There wasn’t that many links to change, so I did it by hand — if there were considerably more, I probably would have sed-ed them. Also, I needed to change the ‘Clean URLs’ entry in the variables table to reflect my unclean environment.
2. Anything that relies upon imap functionality, such as the mailhandler.module, doesn’t work because my hosting provider did not compile it into PHP. WordPress sidesteps this neatly by using a third-party POP3 library. I’m working on a Drupal implementation thereof.

Other than that, it was remarkably painless.

Welp, finally got “Clean URLs” to work on Drupal.

Other than a lot of STFW-ing and swearing, this is what it took…

Please note that my linux box is running a SuSE 9.1 pro install with Apache2.

First, create a directory structure off of your Drupal root like so:

$ cd $DRUPAL_HOME
$ mkdir system
$ mkdir system/test

Second, modify either your httpd.conf or httpd.conf.local thusly:

<Directory $DRUPAL_HOME>
AllowOverride All
</Directory>

Third, from the command line or webmin, restart your Apache daemon (remember, this is SuSE 9.1, so ymmv):

$ httpd-prefork -k restart

Forth, from your web browser, navigate to http://yoursite/?q=admin/settings, “Enable Clean URLs”, and save your changes.

Worked for me!

Recently, I’ve been playing around with Drupal. As a test case, I’ve converted 99.9% of a certain author’s static website on my linux box, and the more I play with it, the more impressed I get.

Setup was pretty easy, and the only real issue I had was figuring Drupal’s category system. As opposed to WordPress’s intuitive categorization system, Drupal requires you to have at least one “term” in a “vocabulary”.

At the moment, I don’t have the patience to get “clean urls” working. It’s not a failure on Drupal’s part. Rather, it’s the default Apache 2 configuration on SuSE 9.1 that’s the issue. Despite “mod_rewrite” being available, it steadfastly refuses to bend to my will.

The next test will be a “live” deploy to see how well Drupal travels. This entails ftp-ing the stuff up to ciulla.org, backing up the local MySQL database, then restoring it on a hosted db instance. Too bad I can’t just gzip it and remotely unzip it on the server side — although I could fake out the server and deploy it as a .war file…