-
Vote on Oct 14!
Apr
15
(2006)
Drupal 4.7 RC3
Filed under: Uncategorized. Tags: drupal.
I just updated the TLC’s copy of Drupal, used to host 10 Drupal-powered websites, to the latest Drupal 4.7 RC3 build. Upgrading the code took under 2 minutes (SSH into the server, curl the updated code down onto the server, then tar -xzf and move the appropriate files into place). Add another 5 minutes to run the update.php script on each site, and you’ve got 10 Drupal sites updated in 7 minutes flat.
The 4.7 release is really a smoking upgrade from 4.6 - it hardly feels like the same software. Modules install and update their own database tables now, piggybacking on the core update.php upgrade script, making it soooo easy to update the code and dozen-or-so added modules.
The multi-site hosting feature is one of the biggest things I love about Drupal. Initially, I was maintaining separate copies of Drupal, with modules etc. painstakingly added to each one and kept in sync. I was essentially managing my own distro of Drupal, which wasn’t the most productive thing to be doing. After some prodding from Patrick, I read up on the sites feature, and now every single one of our Drupal-powered websites runs from a single copy of the code. All modules and themes are automatically available to each site, making maintaining each one pretty much trivial.
I just realized - it’s taken me longer to write the blog post describing how easy updating Drupal is, than it took me to run the update itself…
Comments
4 Responses to “Drupal 4.7 RC3”
Leave a Reply
A lot of guys say to make things even easier you might want to load Drupal into SVN and then do an export or checkout from that. That way if you hack your code, you’ll know what changes you made, etc.
I was thinking of doing that, but several of the modules are taken directly out of Drupal’s CVS repository, and I didn’t want to have any conflicts. Regardless, I may check our distro into our SVN repository for backup and change tracking…
Sami, the SVN technique will also make it easier to stage deployments - can test an update on my desktop easily, commit anything that works, then just svn update on the server to pick up changes. Makes sense. Our Drupal deployment is now in SVN and I’ll try to not edit files directly on the server anymore
The one thing that will get weird is the files directory - don’t want those going into svn, but it will be tricky because they’ll keep showing up in svn status. Must resist “svn add *”