new site();
Moving a site built locally, or on a remote test server, to the production environment always presents a bit of a challenge. Drupal is one of the easier ones I can think of, and here's how you do it. This is for D7, since that's what I moved most recently, but D6 should work similarly.
I am only able to cover the issues I've run into here, but if you have any questions that aren't covered here please feel free to get in touch.
Using phpMyAdmin on the source server, export the entire SQL database to a file. Taking the defaults worked fine for me, including using SQL format rather than CSV or whatever. I have occasionally accidentally created an export that then tried to create a database on the target server--which won't work. So, choose the view that will export all the tables inside the database, but not the top-level database itself, which you will get if you click the name of your database and then choose "export."
Easy enough, just copy the entire directory containing your Drupal installation from the source server to the local machine, then copy them from the local machine up to the target server.
In this case I didn't have an import function per se on the target server, but it did allow me to run SQL from a text file, which accomplishes the same thing if you chose SQL format when exporting in the first step.
Go to /sites/default/settings.php, open it and edit the database settings to match the target server. If you have a hard time figuring out the hostname, check out the address of your phpMyAdmin page in the address bar of your browser and copy everything up to and including the .com. Depending on how your host is set up, this might be your hostname.
If everything has gone well, you should be all set after the above steps. However, you might have one of these problems:
Parse error: syntax error, unexpected '{' in .../includes/bootstrap.inc on line 677
This error means you are not using the PHP version that Drupal 7 wants, which is PHP 5.2+. You can often change the default PHP version your installation will use in your host's control panel, but if you are unable you can make this change in your .htaccess file using AddHandler.
If your site seems to load fine but you get the Internal Server Error page when clicking on any of your links, you've left RewriteBase on in .htaccess, possibly because you had created the site in a subdirectory. Just comment out the RewriteBase line with a hash mark and your links should now work.
If the site looks unstyled, with images missing and so on, you may be having the problem a fellow recently e-mailed me about. In his case, the site was built on the root of his local installation and being moved to a subdirectory of his web server, which is basically two moves in one. Inspect Element in Chrome revealed that it was giving 404's on all of his .css files, all his images, etc., because it was looking for them in the root of the web server rather than his subdirectory (which we'll call "pokey" in the example below).
To resolve his problem we just had to enable RewriteBase in his .htaccess file, so it went from:
# RewriteBase /
To:
RewriteBase /pokey
Just to clarify, this was done in the .htaccess file in his Drupal installation--in /pokey, not in the root. It resolved the initial problem, but led to:
Warning: file_put_contents(temporary:...[function.file-put-contents]: etc.
Changing the RewriteBase in .htaccess may have the unintended effect of redirecting requests for the temporary folder to somewhere it can't use. Drupal is touchy about this, and in a fresh install will not even budge until you have a temp folder with the correct permissions and everything.
In this case since we knew that everything was working before our change to .htaccess, all we had to do was go back into .htaccess and make an exception for the temp folder (which in his case was /tmp), like so:
RewriteRule ^tmp - [L,NC]
Adding this line resolved the errors, and as far as I know everything was pretty smooth sailing after that.