testing

`

When I was rebuilding www.lifeisaprayer.com in Drupal, I decided to use the testing domain new.lifeisaprayer.com. This presented me with a challenge, once I started working a bit more on the site, as I set up imagecache, the file system, the favicon, the logo, internal images in posts, images inserted into blocks, etc., into my /sites/new.lifeisaprayer.com/files directory.

If I simply renamed the directory to 'lifeisaprayer.com' and went live, I'd end up with tons of 404 errors. Currently, there's no easy way to switch the location of your files directory in Drupal. Lacking an easy method, it's time to get your hands dirty with a little SQL (I entered the following commands via phpMyAdmin, since my host doesn't yet allow SSH access):

• Update the files table (which is used by the system as well as imagecache):
  • UPDATE `files` SET `filepath` = REPLACE(`filepath`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
• Update the boxes table (which is used for all the block content):
  • UPDATE `boxes` SET `body` = REPLACE(`body`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
• Update the node_revisions table (all the node content is in here... you'll need to update both the body and the teaser fields):
  • UPDATE `node_revisions` SET `body` = REPLACE(`body`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
  • UPDATE `node_revisions` SET `teaser` = REPLACE(`teaser`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
• Update the users table 'picture' value (if you're using user pictures):
  • UPDATE `users` SET `picture` = REPLACE(`picture`, `sites/OLDDOMAIN/files/pictures/`, `sites/NEWDOMAIN/files/pictures/`);

Now make sure you clear your cache tables (I just used 'Clear caches' in my Admin menu), then empty your watchdog table (TRUNCATE `watchdog`;) and look for any 404 errors. If you find a bunch, there might be another field you need to update with your new filepath.

Hopefully Drupal core will be better able to handle file moving in version 7—I haven't studied that too much yet, but I've heard files will be treated more as 'first class citizens.' Until then, you can either have fun with the above MySQL queries, or you could use private file handling (which uses a path such as /system/files, and allows your file path to be whatever you'd like).

(One other solution is to set up a folder like /sites/sitename instead of /sites/sitename.com, and set up a symlink to the /sites/sitename folder... that's okay, I guess... but not ideal. It would be best if Drupal could handle this stuff (path aliasing, etc.) out of the box.).

Part 3 of a series: Building out a full Drupal site in a weekend.

Now that my feet are firmly on the ground (and hopefully will stay that way for a time), I have a little time to write about the final stages of the Open Source Catholic website development... even though it's tagged as in 'beta.'

On the plane flight home, I was mostly finished creating the theme for the site. I hadn't opened it up in IE 6/7/8 yet, but I knew the main three or four bugs that would crop up, and prepared for them. I decided to write some postings (two articles, two blog posts, and a website review) for the website, as it's never a good idea to try to build momentum for a website on which nothing exists!

I wrote the posts, edited them a little, then browsed every page on the site once or twice, fixing little CSS bugs and tweaking the design until it was just-so. I had created the header image in Photoshop, and I worked to make it so it would be easy to change if I needed to—especially when (if ever) the site goes out of beta status.

Next, I did a little (VERY little) performance testing, and made sure things were working well on the backend. I didn't Boost the site (I don't think that'll be necessary... at least not yet), but I did turn on page caching, CSS and JavaScript aggregation, and am working on following the rest of the YSlow rules.

The second-to-last step on this site was to open it in Internet Explorer 7 and 8 (I haven't tested 6 yet) to make sure there were no show-stopping bugs. Luckily, there really weren't; just one column that kept floating right behind the content. I fixed that by floating the 'second' column to the right instead of left, and adjusting its margins accordingly.

The last step I have is to monitor the site's performance and metrics, test from an end-user's perspective, and make sure the 'moderator' role has the right permissions/access to do everything he or she will need to to keep the site in tip-top shape.

I haven't tried the Flag module yet, but I may at some point; seems pretty interesting to me! Also, I'm going to try to submit the theme, "Airy Blue," to Drupal.org's theme repository... wish me luck!