This is in no way a condemnation of WordPress — I just need “more power!” (Arrr arrr arrr)

I’ve moved all of my blog content to csquared.org, and will eventually redirect the ciulla.org domain there.

Naturally, there’s quite a few product screenshots. To help manage them, I installed Gallery 2 and the Mambo/Gallery2 integration stuff.

On the Mambo side, I needed to add a trailing slash to the component’s “Full Path to Gallery G2″ and enable the mod_gallery_block.

After getting a “ERROR_CONFIGURATION_REQUIRED”, I found that I needed to install and activate the “Image Block” module on the Gallery 2 side.

I was in business… Almost.

When I clicked on the mod_gallery_block on the site, I got a lot of “headers already sent” errors. After searching the web to no avail, I took matters into my own hands. I edited Mambo’s index.php and moved lines 194 through 198 to line 9.

Success!

Now, to work on getting the embedded Gallery 2 content to look like it’s part of the site…

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.

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!

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…

Then it occured to me that I could use WordPress to maintain the static stuff.

So, I read the instructions on the WordPress Codex. Several times. And I changed my options, moved the files, then updated the permalink structure. Several times. I even deleted .htaccess. Several times.

All to no avail.

Then, magically, it just started working. I hate it when stuff just starts to work. That is, provided it didn’t initially work.

edit: I think GoDaddy uses be some kind of caching mechanism. That would explain a lot.

It’s been so effective, I have to write about something else, I suppose…

So, here’s what I’ve been doing for the past couple of days (besides working, of course):

• Working on a CSS-only (read: non-table) version of my resume
• Looking for a very lite content mangement system for the site’s static content
• Fixing overheating issues on the other computers laying around the house and playing family System Administrator
• Playing around with a second-hand copy of SuSE Professional 9.1

CSS-only Resume
Like any decent technology, I have a love/hate relationship with CSS. Why the hell can’t it just do what I want it to do?

Lite CMS
I’ve been playing around with Rodin on localhost. It may do the trick, but I’ll have to tweak the theme a bit.

Family System Administrator
Teri’s machine was overheating, so I plunked down some cash on a couple of fans. One’s an adjustable drivebay fan that sticks out from the front of the case, and the other was a 60mm rear case fan.

Other than hunting down the power pins on the mobo, installing the drivebay fan was a no-brainer.

The 60mm rear case fan came with mounting screws… Assuming you had a freakin’ wood computer case. Wood screws. Needless to say, I was rather torqued.

Fortunately, the drivebay fan worked like a champ, negating the need for the rear case fan.

Naturally, the kids’ computer system was having similar overheating issues, especially when playing a CD-based game. So, back to the computer store. I got the same fan I put in Teri’s machine.

You won’t fool me twice, ya bastads. Wood screws. Grrrrr.

How sad is this?
As I mentioned above, I’ve been playing with SuSE 9.1 I bought a couple of months ago at Half-Price books for 45 bucks. I spent about 45 minutes slapping it on an old laptop, and it works great. Now, I need to put it on my dedicated linux box, which is currently running SuSE 8.something.

Getting to the sad part… Here’s the list of the devices attached to my network right now:

• WRT54g Router
• a 6 port switch
• a 4 port switch
• The Heathen’s WinXP Home box
• Teri’s WinXP Home box
• my WinXP Pro box
• my Linux file/web/MP3 server
• my WinXP Pro “work” laptop
• my Linux “play” laptop
• my Rio Karma MP3 player
• and, my Sharp Zaurus

I am so glad I’ve been replacing all my energy wasting incandecent bulbs.

LIN-you-ex
I’ll have to get around to writing about my favorite Linux story, but the gist of it is a guy I used to work with pronounced “Linux” as “Lin-you-ex”. I usually say that when I’m being extraordinarily geeky — Well, more so than usual.

I couldn’t think of a good title for this post, so for now, “It’s Lin-you-ex.”

TikiWiki is an example of something like this, but it’s serious overkill.

I’ll have to keep looking, I suppose.

The only problem I encountered is an html entities warning, but a quick googling provided the remedy.

Charset Not Supported Workaround documents how to fix it.

Screw it, I can always change later.

However, with a wiki, there’s a bit more involved if you change rendering engines. Although I could write an xform or pull down the site using the (hopefully supported) XMLRPC API, getting around to it is something else entirely. I suppose that should be considered a constraint.

EditThisPagePHP looks good for just knocking together page(s). I played around with it a bit, and it’s really quite easy to install and use, but I don’t think it really meets my needs.

Purple-T-Wiki meets this as well — I could probably learn enough PHP to secure it. The only problem with it is the fact that everything is converted to lowercase. Bah.