PHP

This is a collection of notes I took while setting up a Drupal-ready Apache / MySQL / PHP environment on OS X using Homebrew and PEAR / PECL. I believe it should work to recreate an environment from scratch, but I've not run through the notes from start to finish on a fresh environment to validate. Hopefully this will help you get your own environment up and running easily!

Note: Mark Sonnabaum's Megalodon might be of interest to you, as well. For me, it involved learning a few too many things, and I also wanted as much as possible in my environment to be handled via a package manager like Homebrew or PEAR.

Update: Per Mark, Megalodon does entirely use Homebrew and Chef, I just misunderstood it. I look forward to seeing what I can do with it, once I dig in and understand it a bit more.

Update: Thanks, @stevepurkiss, for pointing out the typo on the first line for brew tap... That's been fixed!

Update: Thanks, @cashwilliams, for pointing out some issues with the my.cnf and order of packages being installed. I've updated a couple of the instructions below to reflect his findings.

Update: I've added instructions for initial setup of Drupal coding standards for PHP Code Sniffer.

A development virtual machine can be really handy. It gives you a sandbox of sorts where you can feel free to test and experiment knowing that in a worst-case scenario you can just delete the VM and start over. It can also be a great way to practice server configurations and sketch out "real-world" server setups. Here's the process I follow to setup my Ubuntu 10.04 LTS Drupal development VM in VirtualBox. Aside from the VM-specific steps, these instructions should work for a regular Ubuntu server (VM or not).

I've put up on Google Code a small new project that I'm working on called the PHP Gamercard API. It's basically a set of classes for working with Xbox Live Gamercard data. It takes advantage of a web service provided by Duncan Mackenzie for retrieving structured data about individual Gamertags. You can expect to see something in Drupal that takes advantage of this, once I've got some time to write a module that utilizes it.

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:

function ideal_courses_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  // ... (irrelevant stuff here)
 
    case 'prepare':
      $field_instructors = variable_get('ideal_courses_field_instructors', NULL);
      // The line that fails is below:
      $node->$field_instructors[0]['value'] = ideal_courses_instructors_as_string($node);
    break;
 
  // ... (more irrelevant stuff here)
}

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:

function ideal_courses_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  // ... (irrelevant stuff here)
 
    case 'prepare':
      $field_instructors = variable_get('ideal_courses_field_instructors', NULL);
      // Fixed line is below:
      $node->{$field_instructors}[0]['value'] = ideal_courses_instructors_as_string($node);
    break;
 
  // ... (more irrelevant stuff here)
}

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:

apt-get install subversion

Login to old server and dump current repositories:

svnadmin dump /path/to/repository > repository.dump

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

svnadmin create /path/to/repository
svnadmin load /path/to/repository < /path/to/dump/repository.dump

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.

addgroup admin
adduser jrbeeman
usermod -G staff,admin jrbeeman

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:

visudo

...and added the line:

%admin  ALL=(ALL) ALL

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.

#
# * Fine Tuning
#
key_buffer              = 256M
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache_size       = 8
#max_connections        = 100
table_cache             = 256
thread_concurrency      = 4
sort_buffer_size        = 1M
read_buffer_size        = 1M
read_rnd_buffer_size    = 4M
myisam_sort_buffer_size = 64M
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M
#
# Turn on slow query logging to help track down performance killers
#
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 5
#
# Some further table-type tweaks
#
[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
 
[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

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:

-- Get the table names...
SHOW TABLE STATUS WHERE Data_free > 0;
-- ...and run the following for each
OPTIMIZE TABLE TABLE_NAME;

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:

a2enmod deflate
a2enmod expires
a2enmod cache

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

# Gzip html, css, js, etc.
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/json
# Set expires headers on html, css, js, etc.
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/html "access plus 1 seconds"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType application/x-javascript "access plus 1 month"
</IfModule>
# Set ETags
FileETag MTime Size

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:

apt-get install memcached

Then, I enabled the Apache module:

a2enmod mem_cache

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!

Note: A large part of this is taken from Victor Kane's article on Awebfactory about setting up Drupal on a fresh Linode, but I've documented some other things here and did some things a little differently than he did, so I figured it'd be worth writing up a post on the process. I've kept the details thin here in places where Victor's notes are more than satisfactory, but I've made sure to note where that happens.

Update: Be sure to check out part 2 of this article, as well.

I've spent the last several months of my off-work hours plugging away at helping the folks over at Gamers With Jobs get rolling with an upgraded version of Drupal, and in the process we decided to move from a shared hosting environment to a place where we've got a lot more control over performance and site configuration. In the meantime, Victor Kane's article on getting Drupal up and running on a Linode came across my RSS reader and provided the kick in the pants I needed to really investigate it. I looked at several VPS options, but in the end Linode seemed to be the best. They offered a seven day money back guarantee, which honestly isn't much, but it was long enough for me to feel comfortable giving it a shot without being out sixty bucks, so I decided to try it out.