First things first, brand new to Drupal…
I’m moving a Drupal 6 site to a different server. All has worked fine so far except the URL. My customer wants to test things out first (it’s a very large site) before the domain is switched over. The home page is viewing fine, but none of the links works. I’ve read several pages/sites about moving Drupal and have tried several things but nothing seems to work. The base URL setting was initially commented out, replaced it with the test site URL. There’s nothing in htaccess concerning the actual domain.
The test domain is set like this: [B]http://ipaddress/~site/[/B], so anything that is [B]http://ipaddress/~site/pagename[/B] is broken. Does Drupal just not like the ~site thing? Should I put a dedicated IP there until we point the domain? Not sure what to do since I can’t even get into the admin section…
Moving Drupal is super easy now that I’ve come up with a system. The toughest part is moving the files. Look up Drupal Drush for a better way of moving and setting up the files. Here’s my system for moving sites from development to production:
- Get the backup and migrate module and install it in your new website. It’s dead easy to use. Go to site configuration by module (/admin/by-module) and select “backup and migrate”. You should be able to leave the settings alone and just backup to a download.
* You’ve just made a backup of the website without any domain specific tables.
- Move your file system over to the new server, adjust the settings file (sites/default/settings.php) to point at your new database or just make a new settings file using default.settings.php and re-saving as settings.php
- Install a new instance on Drupal on the new server. Drupal will install a “vanilla” site using Garland as the theme and it will be entirely blank, no content, no style… This is good. Go into modules and enable backup and migrate.
- Back to configure by module on the new site (/admin/by-module), select “backup and migrate” and then click the restore tab, browse for the backup you downloaded from your development site and click restore now.
If all went well “Boom goes the dynamite” and you are in action
Most Drupal migrations do go well but sometimes differences in PHP will cause a problem here or there, especially if you use heavy use of the date module or sometimes apache won’t play nicely with uploads and will set the permissions on uploaded files (if you are using upload or MCE as a file manager) so that nobody can read them. Otherwise, it should be a breeze.
Thanks for the response Andrew. Discovered that I had to add this to the htaccess file:
once that was there, everything was peachy.
I’ll definitely try your system next time I have to move one of these!
Yes, I can see how that would have worked… I glossed over the part about /~site/ being the major issue. My solution is more for moving sites from one server to another.
That said, I like your solution. It will certainly come in handy for testing sites on shared servers while waiting for DNS changes to make their rounds.
We do the same thing with Drupal 6 only I’ve found it easier to use a subdomain (dev.mysite.com) rather than a subdirectory. Doing so I merely copy the database and files to the production site without issue.
I have a shared account at Site5 that I use exclusively for staging websites. Although it’s shared hosting, they have the latest PHP 5.2.x and MySQL 5.x, lots of memory, adjustable php.ini, terminal access, the works.