Back to Top

Migrating a Drupal Site

Moving from the dev site to production using cPanel

Honestly, migrating a Drupal installation from one site to another isn't really for the feint of heart. Still, unless you're starting absolutely from scratch, you're likely to encounter situations where you need to stage the new version of your site on a separate domain for a while, then copy it over the top of the existing site.

That was the case for me with ModeNomad, because I started experimenting with this site some two years ago. I had a decent looking site in place, along with some content, but it was time for a makeover that fixed a couple of things I didn't think quite worked on the old site. I confess I also just wanted to learn a bit more about how theming in Drupal worked, so it was time to work with a fancier, more-bells-and-whistles sort of theme.

I'll cover the business of choosing the theme and deploying the new theme elsewhere (probably in several posts, as it's an ongoing project). What I want to focus on here is the basic process of getting a copy of the new site copied off of the "development" site and onto the primary site.

In my case, my hosting provider uses an administration tool called cPanel. This is used quite widely, so unless you're completely rolling your own server (in which case you probably don't need to read any of this), there's a decent chance you've got cPanel running behind your site as well.

Assuming cPanel, the basic setup is to make a copy of the "dev" home directory and a copy of your Drupal installation's database. Then, you delete whatever you've got running on the target site, restore the backup of the directories and the database you just made, and then fiddle with your database user, password, and access rights until the site works again, just like it was working on the Dev site.

I should point out, of course, that this assumes you're ready to part ways with whatever content is stored on the target site before you do the restores I just mentioned. If you get in a situation where you've got new entries on the "old" site and new entries (and all sorts of other new things) on the "dev" site, then you've got a synchronization problem on your hand that is, frankly, outside of the scope of this particular entry. In many instances, if you've let yourself get into this sort of situation, the clearest way forward will be to copy the stuff you put into the "old" site and re-enter it on the new site. On the one hand, this is annoying. On the other hand, it gives you a chance to look back over the old stuff, make some tweaks, refresh things a bit.

cPanel is your friend

Assuming you've stayed out of synchronization trouble, though, cPanel makes it easy to carry out all the steps involved, with maybe just the tiniest bit of scary tweakiness for the database configuration steps at the end.

On the backup side of the deal, the "Files" section of the cPanel main screen has a "Backup" icon that gives you a few options for things to back up. You want to make two backups: first one of the Home Directory, then one of the database your Drupal installation uses (it probably has the word drupal in the name). These backups will be downloaded automatically to your local system.

At this point you'll have a compressed, two-part image of your Web site. Now comes the uneasy part of the operation.

To help maintain your sanity, you'll want to back up whatever's currently living on the target site. This let's you get yourself back to where you started before you had this crazy idea of updating the site, back to whatever you started with.

Then, you can use cPanel to delete whatever site you've had running on the primary (target) site. In my case, I'd used the "Fantastico De Luxe" installer to do a one-click install of Drupal, so all I had to do was go back into Fantastico, then pick Drupal. It showed me the current installation, along with a button offering to remove it (shocking how simple it is, really). It asks you once to make sure you're really on board for this drastic action, and then the whole business is removed.

Now your site is officially broken. So, without further ado, go back to the Backup section of cPanel and this time pick the restore options for Home Directory and SQL database. Upload the files you made from the dev site one at a time, doesn't matter which order. And note that this can take a few minutes and the interface isn't exactly beautiful. You'll wind up with a browser window that lists all the files that were restored. Once it's fully loaded, you're done.

Won't run, of course

In an ideal world, that'd be it. And I think it's possible that it actually would run at this point if you had the same database name and the same user name on both sites. I haven't actually checked this, because I had named my databases differently and created differently named users on the sites. This being the case, I had to carry out two additional steps.

First, when the database was restored, it automatically was assigned a prefix that is unique to my site. Since the domains are different, the prefix was different, and thus I needed to change the name of the database that Drupal is looking for. This is done by going into the file manager within cPanel, then heading into the sites>default directory. There's a file there called "settings.php."

Now, settings.php is set to be read only. Have it set to be writable is a security issue. You're going to (ever so temporarily) make it writable, so you can make a quick edit.

Feeling uncomfortable? Even if I know exactly what I'm doing, the moment when one starts editing what is clearly a critical system configuration file is always a little fraught with anxiety. You can either press ahead or seek professional assistance. There is no dishonor in getting some help on this. On the other hand, there's not really any particular dishonor in trying it, screwing it completely up, and then going out for some help. This is why you made the backup files, right?

So, to the far right of the screen listing settings.php there's a column that has the header "Perms" for "Permissions." Settings should be set to 0444. The numbers mean something, for that's a digression for another day. Basically, you want to change it to 0644, which you can do by clicking on the 0444, which makes it editable. Change the first 4 to a 6 and click the "Save" button that has dropped down from the edit field.

Having done that, you can edit the file. With the row for the file still highlighted, click the edit icon at the top of the window. You'll get a message about UTF encoding, which you can ignore by clicking the Edit button at the bottom of the popup. This will bring up an editor.

There's a bunch of junk in this file. At the top of the file, you'll find everything has a "*" in front of it, meaning the line is just a comment. It provides information but has no effect on the system. Scroll down till you get to a section that doesn't have the asterisks--it looks like this:

$databases = array (
'default' =>
array (
'default' =>
array (
'database' => 'nomadxxx_drupal',
'username' => 'nomadxxx',
'password' => 'xxxxxxxxx',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => '',

I have changed some of the names to protect ModeNomad's site security, but you get the idea. You need to put the correct name of the database with the target site prefix where it says 'nomadxxx_drupal".

You furthermore have to make sure that the username and password used here exist within the database installation you've got on the target site. Your site probably requires the same prefix used for database names in front of database user names. So you're going to have to edit the username to something that includes that prefix. You can either use an existing admin user on the target site who's password you know (it is, alas, possible to forget these things), or you can create a new user name and a new, horrifically complex password, which you'll re-enter in the database in just a moment. Toward that end, note down the username and the password. If, as I hope it is, the password is long and impossible to remember, you might want to highlight it and copy it to the clipboard.

Now you save the settings.php file and switch gears to deal with the database. Back in the main cPanel page, select MySQL Database. If you need to, add the new user you just listed in the settings.php file. Create the user. Then--very important--you must add your admin user to the drupal database if they aren't already listed as a user of that database. You can select the user and the database at the bottom of the MySQL Database admin page. You'll then see the correct user listed alongside that database in the list of databases above.

Whether you're using cPanel or not, or whether there have been modifications to it that make what I've described here a bit different, this is the basic process. And if everything is in order and the Drupal gods are smiling on you, you can now go to your website's home address and the new version of the site will pop up, looking exactly as it did on the dev site. It's a silly thing, but this always fills me with something very close to glee.

Robert Richardson is the principle nomad here at the Mode.
0 Comment(s) to the "Migrating a Drupal Site"
  • Latest
  • Popular
  • Tags
The Tango pocketable PC
Two additional pocketable PC type concepts I wanted to menti...
Tuesday, February 11, 2014 - 21:33
Dell Wyse Cloud Connect
Two or three products have crossed my desk of late and they'...
Sunday, February 2, 2014 - 11:30
If you've been thinking to yourself, watching the news of la...
Sunday, January 12, 2014 - 21:35
Well, it's hard not to be intrigued by this. It's a 3D print...
Friday, January 10, 2014 - 22:46

Fatal error: Class CToolsCssCache contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (DrupalCacheInterface::__construct) in /home/nomadic/public_html/sites/all/modules/ctools/includes/ on line 52