I am currently maintaining a few sites using aegir, and one of these sites is going to be passed to another group of developers on a new host in the near future. I would like to know how best to migrate the site to the new hosting environment (which will not be needing aegir, as it's a single site).
It is my understanding that aegir uses a different settings.php format than a standalone drupal site. I am willing to modify the file, however I am not sure how to do so or what other issues I need to be taking into account.
Are there Apache issues I need to be aware of (beyond the usual configuration issues required for running Drupal)?
How are file paths handled moving between environments?
What needs to be done to settings.php and drushrc.php in order to produce a functioning site on the new host?
I've just found a post in this group detailing manual database modifications related to moving a site into aegir - could reversing this process be of any help? See here , particularly the comment containing a database modification script.
Thanks for any insight.
Comments
You'll want to test this
You'll want to test this first, but last time I did this from what I can remember it just requires modifying settings.php. I grabbed one from a standard Drupal install and copied the relevant settings from my Aegir site's custom settings.php. The file system should be about the same, I believe.
Or, to be safe, you could just grab a fresh download of Drupal and copy your sites directory in.
I'm pretty sure the drushrc.php file is specific to Aegir and isn't needed outside of it.
Hopefully one of the developers chime in here to give you the "real way" but this has worked for me.
I broke things at one point
I broke things at one point and needed to very quickly move a site out of aegir to get it working while I solved my problem.
IIRC I just cloned the drupal install, and put the database credentials back into settings.php like an ordinary drupal install does it. Pretty much as butler360 suggests.
I have tried entering the
I have tried entering the site's database credentials (which Aegir seems to have moved into both the drushrc.php file and into the Apache configuration file as environment variables) into a settings.php file (which I copied from a fresh installation of Drupal 6.19) but the site only loads as a blank white screen.
The situation is perhaps being complicated by the fact that I am trying to move the site out of Aegir and onto my local development server as a test. The dev server does not have Aegir installed. In order to get the dev sites to resolve, I have decided to rename their top-level domains to .dev rather than their original TLDs, and modify my HOSTS file to get the names to resolve to my dev server. This way I can manage the real sites and the dev sites from the same workstation (and if there is a better way, please let me know!).
Because of the above requirement, I had to rename the site's folder under [drupal root]/sites/ to reflect the TLD change. I also modified the ServerName directive in Apache to match.
Following this, I noticed that the file paths were incorrect in the files table of the site's database. Using a script (from the link in the original post above), I altered the files table to reflect the new file structure. This all looks good in phpMyAdmin now.
Does anyone see any obvious holes in this strategy? Or an easier way to go about it? It's apparent that I am missing something, because the local site will not load. I am open to any advice.
Thanks in advance.
More diagnosis on the WSOD
More diagnosis on the WSOD (I'm picking up on a new Drupal term, here) by enabling error reporting in the index.php file indicates that it is dying with the following error:
Fatal error: Call to undefined function webform_menu_load() in /var/www/d4/includes/menu.inc on line 410
EDIT: So, a boneheaded error on my part was to neglect to copy the shared modules over to the dev server. I have now done this and have sort of loaded the site successfully, albeit without any theme information being carried over. URL rewriting also seems to be broken, as all non-hardcoded links don't function.
It's progress, at least...
Still open to any additional advice.