Adam Innes · Blog

Drupal 7 Is Out. What Your Server Needs

· 3 min · drupal, php, mysql, lamp

Drupal 7.0 came out on January 5, and if you look after Drupal sites, the first question isn’t whether it’s nice (it is). It’s whether your server can run it. Drupal 7 raises the floor on PHP and MySQL and replaces the whole database layer with one built on PDO. That can bite you on an older shared host.

The new database layer

The 7.0 CHANGELOG describes the database layer as fully rewritten on top of PHP 5’s PDO, with query builders for INSERT, UPDATE, DELETE, MERGE and SELECT, support for transactions and master/slave replication, and SQLite as a new option next to MySQL and PostgreSQL. You’ll also see it called DBTNG in the list of fixes in the Drupal 7.0 release notes.

For module code, the most visible change is placeholders. Drupal 6 used printf style markers like %d. Drupal 7 uses named placeholders, and results can be looped over directly:

// Drupal 6
$result = db_query_range('SELECT nid, title FROM {node} WHERE uid = %d', $uid, 0, 10);
while ($node = db_fetch_object($result)) {
  print $node->title;
}

// Drupal 7
$result = db_query_range('SELECT nid, title FROM {node} WHERE uid = :uid', 0, 10, array(':uid' => $uid));
foreach ($result as $node) {
  print $node->title;
}

The database API documentation for 7.x explains that every query goes through as a prepared statement, so you pass values separately and never quote or escape them yourself. That’s a real security win, and it’s why custom modules with raw SQL need work before they run on 7.

There’s a MySQL detail worth knowing too. The CHANGELOG says Drupal 7 now defaults to InnoDB instead of MyISAM when InnoDB is available, so new installs get the transaction support and row level locks that INSTALL.mysql.txt mentions. Tables on an upgraded site stay whatever engine they already were.

What the server needs

The INSTALL.txt that ships with 7.0 asks for PHP 5.2.4 or greater and one of MySQL 5.0.15, MariaDB 5.1.44, PostgreSQL 8.3 or SQLite 3.4.2 (or greater), with Apache 2.0 or greater recommended. The installer actually checks the database version and refuses to continue below the minimum, so this isn’t a soft suggestion.

The System requirements page in the drupal.org handbook, as it read in mid January, adds a few things. It gives PHP 5.2.5 as the requirement but says PHP 5.2.4 builds with backported security patches, like the one in Ubuntu Hardy, should also work, and it recommends PHP 5.3 for Drupal 7. It says PDO must be enabled along with the driver for your database, and that the PECL version of PDO won’t work. And Drupal 7 core wants a PHP memory_limit of at least 32MB, while the release announcement warns that a site with a number of commonly used modules may need 64MB or more. I’d plan on the bigger number.

On the MySQL side, INSTALL.mysql.txt grants the Drupal user SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX and ALTER on its own database and says Drupal won’t run without all of them. That’s a handy list to give a host.

A quick way to check a box before you get your hopes up is php -v, php -m | grep -i pdo and mysql --version. The command line PHP can load a different php.ini than your web server, so a phpinfo() page is the final word. If pdo_mysql doesn’t show up, fix that first.

Upgrade gotchas worth planning for

The 7.0 UPGRADE.txt is short, and it’s worth reading all of it before you touch a live site. A few steps deserve extra attention.

Start with your modules. The file’s first step is checking the Drupal 7 status of every contributed and custom module and theme, and it says outright that you may decide you can’t upgrade yet. One module you depend on with no 7.x release is a blocker, no matter how ready your server is.

You also need to be on the latest Drupal 6 release first (Drupal 5 sites have to go to 6 before 7). Before running the update you switch to the Garland theme, disable every module that isn’t core, remove sites/default/default.settings.php, and make settings.php writable so the update can convert it to the Drupal 7 format. That conversion matters, because Drupal 6’s single $db_url string becomes a $databases array in Drupal 7.

The file also says to take a full backup of files and database before starting, to try the upgrade on a test copy first, and to back up the database again after the core upgrade runs, before you start updating contributed modules. If anything goes wrong, it tells you to restore from backup rather than trying to push through on a half upgraded site.

The takeaway

If your host already runs PHP 5.3 with PDO and MySQL 5.0.15 or later, Drupal 7 should be happy there and the new database layer is a genuine improvement. The harder part is your module list. My advice is to check the server this week, since that’s quick, and treat the actual upgrade as a staged project on a copy of the site once the modules you rely on have Drupal 7 releases.

← all posts