Drupal

I've hated my personal site's theme for a couple of years now. Cleaning it up has been sitting a few items down on my todo list for a long time, and I finally decided to stop waiting for a good time and just move it up the stack this week.

Eww.

I tried out a couple of starter Drupal themes (Ninesixty and Blueprint) but found them light on documentation and simply not as "complete" as my stand-by on nearly every site, Zen. I was adventurous and went for the 6.x-2.x-dev version of Zen, which has some really nice changes under the hood. The dev branch's documentation still needs some updating, but my familiarity with the theme helped me quickly overcome any issues I encountered.

Fewer viewers report wanting to throw up in their mouths when viewing this theme.

My main goal with the new theme was to get a more clean, readable, and more timeless look. I essentially don't want to have to update my site's theme anymore... at least, not unless one of my far-more-talented-than-me graphic designer friends want to help me out with it. *wink-wink* *nudge-nudge*

I'll be going through old posts and cleaning them up as-needed to make everything fit within the new size restrictions, but that may take a few days.

[Update] I've updated the handout to be a single page, cleaned-up a lot of the instruction, and fixed several typos. Please see the revised handout below.

An additional note: If you use the handout to assist your site upgrade process, please do me a favor and fill out a brief survey.

Original post:

Attached below is the handout from the July 2009 ASU Drupal Users Group workshop. Use this handout to help you cover all the steps necessary to upgrade your site from Drupal 5.x to 6.x. It contains a module inventory worksheet and a site review checklist that can be used to help you make sure your site is fully functional after the upgrade.

Note: I created this handout for the ASU DUG workshop as well as an assignment for one of the courses I'm in at ASU. If you use the handout as an aid when performing a site upgrade, please let me know so that I can send you a link to a brief survey about your experience with it. The survey will help me get a better understanding of how you used the handout and how it can be improved.

Attached below are the slides for the April, 2009 ASU Drupal Users Group presentation I gave on maintaining sites using a combination of CVS (to checkout Drupal core and contrib modules) and Subversion (for backing up your site's code base and integrating with locally maintained modules and themes).

Here's a quick rundown of links mentioned in the presentation:

• 5 minute overview of Subversion (video)
• Subversion Handbook
• CVS Handbook
• CVS Deploy module for Drupal

Read on after the break for code samples.

Attached below are the slides for the March, 2009 ASU Drupal Users Group presentation I gave. The presentation contains info on the following topics:

DrupalCon 2009: Washington, DC

• DrupalCon 2009 Website
• DrupalCon session videos listing

CAS

• Download the CAS module
• Download the PHP CAS library

FeedAPI

• FeedAPI module
• FeedAPI Mapper module
• Filter by Node Type module

Miscellaneous Links

• Twitter API module

Last night we migrated our Linode for Gamers With Jobs to a new Xen VPS and we've noticed a significant performance boost. We did, however, start encountering a random issue with segmentation faults in Apache. If you haven't seen this happen before, it tends to begin innocently with one Apache process dying, and therefore giving errors (usually WSOD), but quickly balloons into dozens of dead processes. It essentially hoses Apache.

Apparently the issue is due to eAccelerator, so I reinstalled it and cleared its caches in the hope that it might limit its occurrence. Just in case, though, 2bits has a great fix for it, using the logwatcher script by Firebright, Inc. I was able to quickly get it going, and the only difference is that I used the Debian init.d script provided by Derek Laventure to run it.

For a project at work, we needed to be able to manage, and therefore search, large-scale taxonomies (10,000+ terms). Users needed to be able to search for term names, descriptions and synonyms, so I figured a module using the Drupal search API seemed to be the best bet for a solution. I dove in deep and came back up with Taxonomy Search 2.x.

I've just released version 2.0 of the module, and you can check it out at the Taxonomy Search project page. I'd love some feedback, as this is my first module that utilizes the search API, and there may be some rough edges. Please take a look at let me know what you think!

Attached below are the slides I used for both the March and April ASU Drupal Users' Group presentations I did. The first was on Content Access and Workflows and discussed the setting up effective content creation workflows with corresponding access controls. The second covered an intro Content Creation Kit (CCK) and Views. See the lists below for modules / sites referenced in the presentations.

Content Access and Workflows presentation

Simple Workflow + Actions

• Actions
• Workflow

Workflow NG

• ACL
• Content Access
• Content Creation Kit (CCK)
• Token
• Views
• Workflow NG

Other stuff referenced

• Diff
• Devel

CCK & Views presentation

• Content Creation Kit (CCK)
• Content Templates
• Date
• ImageField
• Views
• Full list of CCK-related modules

Update:
Thanks to an anonymous commenter for letting me know that this is an issue of operator precedence.

This is more a personal note than anything, but I've been banging my head against a wall trying to figure out how to reference an array within a variably-named object property in PHP. Having not found anything very useful when search Google, I figure my post may end up being someone's helpful search result. Maybe I just don't know the right terminology for what I'm trying to do...?

Anyways, I've got a module that needs to modify the string in a CCK text field before it's shown to users on the node edit form. It's a "glue" module that helps us handle course enrollment, and the field in question handles course instructor(s) via a comma-delimited list of usernames. The module takes the user's submitted data, parses it into an array and stores each username in a table joined with course ID for other uses (such as passing to our Sakai installation). The CCK field is referenced in several places, so I use an admin settings form to allow us to say, "This CCK field is the field that users fill out to define instructors." This allows us to avoid hard-coding the CCK field name all over our glue module, but it also led to the headache I encountered today.

When a user goes back to the form to edit the course, I want to present the username list cleanly (alphabetical, no accidental whitespace, etc). Here's the code I tried to use:

The error I kept getting was, "PHP Fatal error: Cannot use string offset as an array." The strange thing is that doing a print_r($node->$field_instructors); works fine. The fix was simple, but difficult to find: wrap the variable property name in curly braces: $node->{$field_instructors}[0]['value']. The full result is below:

I've just put the finishing touches on the 1.0 releases of the Signup Scheduler and Signup Status modules, which I've written about before. While they're both in just their initial release, I feel pretty good about their stability and utility. We've been using both modules in production on the IDEAL site, where users can register for professional development courses. I've also been getting lots of great feedback and bug reports from community members in the issue queues. Special thanks to Mark Dowsett for testing and issue reporting and Derek Wright for working with me on some helpful changes to the Signup module.

The project pages have plenty of details, but most notably the Signup Status module contains lots of goodies that weren't mentioned in my original post, such as plenty of Views integration, signup certificates, signup status change emailing, and more. Check it out if you're interested!

Now that I had a demonstrably working and functional web server going on my Linode (see Just got rolling with a VPS on Linode (Part 1)), it was time to get the rest of my toolkit on the box, setup users and secure the server a bit.

Installing Subversion and migrating repositories

Well, installing Subversion couldn't be any simpler:

Login to old server and dump current repositories:

Copy dump file to new server, and on new server:

Adding users and groups

I decided I didn't want to be logged in as root all the time, especially since I'll most likely be bringing some other folks in to work on the server in the future. So, I setup the admin group, created myself a new user and put myself in both the admin and staff groups.

Next, I wanted to make sure admins could sudo to root, so that they could install programs and do other root-y things. The sudoers file, as far as I can tell, can only be edited with the command visudo:

...and added the line:

Setting up the firewall

This was probably the least-traveled territory in the whole VPS setup for me. Thankfully, there is an awesome resource in the website IP Tables Rocks, with a full rundown of how to lock down unneeded ports. It emphasizes locking down everything, and then only opening up those services you want open. I essentially followed the tutorial, but proceeded to lock down every port except those that I knew I would need for web services and working with the server (22, 80, 443, etc.)

Performance

By this point, I've started working on getting the Gamers With Jobs development site migrated over, and I'm working on nailing down any performance issues. As I said in part 1, the main reason for going to a VPS was the sheer size and load on the GWJ site and how shared hosting was really hosing the speed. Most of the tweaks from here on out are related to the GWJ site.

Tweak MySQL settings

Since the Gamers With Jobs site is very database intensive, getting MySQL to perform optimally given the site's load is important. I'm still tweaking these settings here and there, but here's what I'm at so far. I'm attempting to go for large enough buffers and caches to keep things snappy, but without bloating out the caches to the point that things slow down.

Bringing over the GWJ site required quite a bit of scripting of INSERT and DELETE statements that fudged with table lengths, so I also optimized all the tables with free data space:

Tweak Apache settings

The YSlow utility from Yahoo is a great way to track down potential end-user performance issues, so I ran it against the GWJ dev site and tweaked quite a few things to improve the rating and speed reported there.

First, I needed to enable a few Apache modules:

Then, in /etc/apache2/httpd.conf, I added the following lines to the stanza of the GWJ virtual host definition:

Install memcached

In order to squeeze a bit more performance out of the server, I decided to install memcached and the related Drupal module, which allows you to configure Drupal to store certain cache data in memory. I essentially followed the instructions in Robert Douglass's article on Lullabot, but with a couple of modifications.

First, libevent1-1.3b and memcached-1.2.1-1 can be installed via apt-get on Ubuntu gutsy, all with:

Then, I enabled the Apache module:

Install eaccelerator

Not much to write here, aside from noting that I followed the great article on 2Bits to get going.

Done... sorta

Seeing how I started writing this article a couple of weeks ago and am just getting around to publishing it, I think I'll call it "finished," for now. I hope that someone out there finds this useful!