Alex's Blog

I recently had the potentially very painful task of upgrading a site from a hacked up version of Drupal 4.7.2 to the latest version of 5.x. Whilst I doubt theres many D4 sites still out there, I thought I’d share my notes and tips below as the whole process was quite interesting and perhaps it can at least save someone a bit of time. (Note: on the same site, I’ll be doing the D5 to D6 upgrade in the next few weeks too, so I’ll do a separate post for that here).

The first thing to always do, is to make backups repeatedly throughout the upgrade process. I had the following commands handy and ran them right before I did anything serious:

tar -czvf site-backup-`date '+%y%m%d-%H%M%S'`.tar.gz public_html
mysqldump -u sitedb_primary -p sitedb_primary > \
`date '+%y%m%d-%H%M%S'`.sql

The other thing to do before you start,  is to do all your upgrading on a staging or development version of the site first. This is because, theres a high chance you won’t be able to do this whole process straight off the bat, and you probably don’t want to leave your site in maitenance mode over night while you recover for another attempt.

The following guides/screencasts are what I followed to perform a successful upgrade, plus a few notes, I made that weren’t covered:

1. Converting custom content types from Flexinode to CCK: http://docs.indymedia.be/node/1

• Make sure your flexinode fields all have unique names from one another. I had to rename a few of my flexinode body fields before flexiconvert would convert things successfully.
• Keep notes on all your original flexinode names and field names. This is so that when it comes to your themes you can easily update them to the new field names.
• When creating new content types, you must add the add/edit/delete privileges for each new content type before you can access this section.

2. Screencast for upgrading from D4.x to D5.x: http://drupal.org/videocasts/upgrading-to-5

• Disabling any custom theme or custom modules are some of the preparations recommended in the screencast. Before you do this though, make sure you don’t have any php code used for block visibility that might use functions in these custom themes or modules. You can either update them with a function_exists(), or re-write them to work out the condition another way.
• Before running update.php, it might help to do run the following commands on the database “DELETE FROM `variable` WHERE `name` = ‘cache_inc’; TRUNCATE TABLE `themonth_monthlydb`.`cache`;”. I read somewhere that the D4 caching options were different in D5, and if you tried accessing the site after the upgrade without doing this, it would cause your site to die.
• If your going to leave your site in maintenance mode for an hour whilst you conduct the upgrade, and don’t want the default Drupal Alien logo to show up, simply update the public_html/misc/maintenance.css body tag not to reference ‘druplicon.png’. This might be particularly important if you have a popular site and don’t want to scare people!
• For views, if you use the filter by ‘Distinct’, make sure its the first filter in your list, otherwise it doesn’t seem to let you save it.

3. For converting your custom themes and modules to D5: http://drupal.org/node/64279

• For a custom nice_menu’s css file, you can now specify the css filepath via Admin->Themes->Global Settings->Path to custom css file.
• Put all your custom modules in their own folder within public_html/sites/all/custom/
• Where possible try to keep your drupal install on the upgrade path by overriding things, or creating custom modules, rather then touching core or contributed php/theme code .
• When upgrading custom modules, if your in the process of doing things like updating modulename_settings – make sure you disable and then re-enable the module, otherwise, you’ll get some whacky side effects like double admin menu items, etc.

That’s it!

If you are doing an upgrade, I wish you all the luck and patience in the world! And for those that believe in doing a site rebuild over the upgrade, I recommend you try the upgrade first and exhaust all possibilities before giving up, because either re-entering all your sites content, or hacking up a content copy script is more work then it seems.

As you can now see, I’ve moved my blog from blog.akb.com.au to www.akb.id.au. If it isn’t obvious, the id.au domain name space is for identities of those is Australia.You can grab them for around $30 from any good registry, Jumba, TPP Internet, etc.

Basically, the reason for changing, is because subdomains (like blog.akb.com.au) carry less weight in google indexes then TLD’s or Country Second Level domains. The other reason was for my personal preference not to use subdomains, as they just seem a bit too tedious.

Another change I made here, is install this handy Twitter Widget Wordpress plugin which automatically updates this site with my tweets! I’m a bit of a Twitter noob – only opened an account a few weeks back for fun, so feel free to follow me, and I’ll follow you back

I recently had my 1TB hard drive (of which was +750GB full) die on me last weekend, after only 12 months of use. I decided to therefore go through all my old hard drives, that I had copied everything from originally, to see what data might have been left on them. I needed to know when I bought them though, and looking at the label on the drives showned something called a ‘Date Code’ for which there was a 5 digit number?

Anyway, the number is calculated on the financial year, then week number of that year, and the day. It’s all explained on this page, along with a handy date code to real date calculator: Seagate date code.

I might be a bit behind the times here (oh, a good 9 months!), but I’ve finally had a chance to sit down and install Drupal Acquia – and to cut a long story short, I’m very impressed, indeed!

Acquia is the commercially supported version of Drupal. The standard package (which can be downloaded from the acquia site) comes with all those important 3rd party modules: CCK, Views, Wysiwyg, Filefield, Calendar, Date, Google_Analytics, Imagecache, Pathauto, Print, Admin_menu and a whole lot more. Individually downloading, extracting and moving/uploading all these modules can take a fair bit of time normally.

One of the (pretty minor) downsides to using Acquia though, is that the commercial subscription options come bundled (and enabled) with the package, and the default garland themes has a little Acquia branding. Surprisingly though, its pretty easy to disable (aka vanilla-ise it), and I’ve jotted down the whole 2! steps taken below:

1. Simply disable the modules (Site Building->Modules): Acquia Site Information, Acquia Search (if you’ve switched it on) and then Acquia Agent (you might need to disable each one individually). This will remove the subscription messages and the flag shown in your admin menu (top right hand menu).
2. Go to Site Building->Themes->Garland->Configure and tick the ‘User the default logo’. This will switch back on the Drupal alien logo, rather then the acquia logo.

That’s it, pretty simple, huh!

Now a quick note if your a developer:

The 3rd party modules which you’d normally install into ’sites/all/modules’ are instead installed in ‘modules/acquia’. No, don’t put any custom or other 3rd party modules in ‘modules/acquia’ – continue to put them in ’sites/all/modules’ to ensure you don’t contaiminate the acquia installation. The reason you might want to know where the 3rd party modules are that come with acquia, is that you might need to go through the code (perhaps for searching for a theme function, or function parameters).

Not much more to say at this point about Acquia, other then that it rocks!