moving a wordpress website

[Simon]

Can anyone advise me on moving a wordpress website from one host to another ?

[sacherjj]

Backup all the files.

Backup the DB.  (This can be done with a plugin and it is nice to have it scheduled to email backups to you automatically.  I use Gmail for holding my Wordpress backups from email.)

I would do a core Wordpress install in the new location and make sure it works.  Then you would restore the DB and replace the existing files with those from your original site.

It usually isn't too bad.  You will need to manually change the configuration settings to match the new site (root directory, etc.)

[Simon]

It usually isn't too bad.  You will need to manually change the configuration settings to match the new site (root directory, etc.)

Thanks, that sounds relatively straight forward. but how do I restore the database on the new instalaion and which configuration settings am i changing ?

[dengorius]

you back up the database by exporting it either in plain .sql format or zipped. It is a single file and when you want to restore the db you import that file.

You can do both operation via phpmyadmin.

If you do a new wordpress install on your new hosting most of the settings should be already fine (file paths, db server address etc.). Just skim through the various configurations after you've restored your old db

[sacherjj]

Right.  You can look through the SQL and pull out the parts that would overwrite the config data in the new install.  The app you use to run the SQL script to load the data is dependent on what the host uses.  Usually phpMyAdmin.

[EEVblog]

There can be a few manual steps involved.
1) Backup the database using phpMyadmin (select database, then use Export with default settings)
2) Backup all the files and subdirectories under your wordpress site.
3) Upload all those files to your new server in the directly you want
4) Create a new database on the new server, and a new database user under the same names and password as the old one. You can find this info in wp-config.php Make sure you link the database user to the database. (all this is done in the database section of cPanel.)
5) Use the Import command on that backed up database into the new database in phpMyadmin

I can't remember if there are any paths to worry about, I don't think so. But some plug-in's keep paths so these may have to be manually in the database or installed fresh.

wp-config.php is the key. Those settings must match your new servers database.

Dave.

[sacherjj]

I can't remember if there are any paths to worry about, I don't think so. But some plug-in's keep paths so these may have to be manually in the database or installed fresh.

Everything should be relative to the root of WordPress, so I believe that is the only path you have to worry about.

[amigo]

If you are using the phpMyAdmin route, you have to make sure that your max upload/post size are set high enough in the php.ini so that if the DB file is big it actually gets fully uploaded to the host.

One alternative is to save the DB dump into a file and then manually import it into mysql through a shell, something like:

mysql -u <username> -p <password> < db.sql

Make sure that you are exporting both table structures and data from phpMyAdmin.

Another alternative, if you dare, is to just pack the database from your first host's disk and deploy it on the other host's disk, all done via the shell. Generally in Linux land, mysql stores the database into /var/lib/mysql/<db_name>.

Before doing this you should stop your mysqld so that all tables are closed and flushed.

Then you would do:

cd /var/lib/mysql
tar cvfz wordpress.tgz <db_name>

then FTP the wordpress.tgz to the other host, stop the mysqld there as well, then do:

cd /var/lib/mysql
tar xvfz <location/of/wordpress.tgz>

restart mysqld and it should all be there...data wise.

What's missing would be any special user/table permissions as they would be saved inside the "mysql" database. You could export those as single rows or what not or simply re-create them through phpMyAdmin.

[EEVblog]

If you are using the phpMyAdmin route, you have to make sure that your max upload/post size are set high enough in the php.ini so that if the DB file is big it actually gets fully uploaded to the host.

My cPanel phpAdmin doesn't let me import database files greater than 50MB, of which this forum has now surpassed!
My old Sitecloud host had a 100MB limit.
Not sure if you can get around that using compression?

Dave.

[sacherjj]

My cPanel phpAdmin doesn't let me import database files greater than 50MB, of which this forum has now surpassed!
My old Sitecloud host had a 100MB limit.
Not sure if you can get around that using compression?

phpMyAdmin will automatically detect gzip compression on the SQL file.  This should get you down under the limit.  This is generally a limit with the backend php for uploading files, rather than the DB running the file.

If that doesn't work, you can break up the SQL file into a few parts, by cutting between statements.

[Simon]

If you are using the phpMyAdmin route, you have to make sure that your max upload/post size are set high enough in the php.ini so that if the DB file is big it actually gets fully uploaded to the host.

My cPanel phpAdmin doesn't let me import database files greater than 50MB, of which this forum has now surpassed!
My old Sitecloud host had a 100MB limit.
Not sure if you can get around that using compression?

Dave.

they are only small websites anyway

[amigo]

My cPanel phpAdmin doesn't let me import database files greater than 50MB, of which this forum has now surpassed!
My old Sitecloud host had a 100MB limit.
Not sure if you can get around that using compression?

Dave.

Compression will help, or you could also try to not use full inserts, although generally that option is not selected. But as it was suggested above, splitting the exported DB into chunks would work as well.

In reality, the last method with copying the entire DB folder from one host to the other works the best when there are problems with file size or upload size, etc. Just have to make sure that the proper user name and privileges are re-created on the target host, which is generally a single SQL query like
GRANT ALL PRIVILEGES ON db_name.* TO 'username'@'localhost' IDENTIFIED BY 'password';

[dengorius]

If you are using the phpMyAdmin route, you have to make sure that your max upload/post size are set high enough in the php.ini so that if the DB file is big it actually gets fully uploaded to the host.

My cPanel phpAdmin doesn't let me import database files greater than 50MB, of which this forum has now surpassed!
My old Sitecloud host had a 100MB limit.
Not sure if you can get around that using compression?

Dave.

You won't be able to make any change in the php.ini file unless you're using a dedicated server, and even in that case you'll probably have to ask to the owner of the server to change it for you since you need root access.
Anyway as other people said you can split your db into chunks and restore it one piece at a time

[copiertalk]

umm.

Just tell your new host where the site is and what you wish to keep and they can wget it in a couple of minutes.

Most hosts offer this service free.

[alm]

I'm sure that works great with dynamic sites...

[Simon]

I'll have to do it manually, how do I find out what my database is called and it's user. i used automatic setups so i'm unsure as to which database is for what website

[Uncle Vernon]

My cPanel phpAdmin doesn't let me import database files greater than 50MB, of which this forum has now surpassed!
My old Sitecloud host had a 100MB limit.
Not sure if you can get around that using compression?

Dave.

Your PHP import doesn't need to be a single file some simple cut and past will allow you to rebuild a database image via phpMyadmin running sequential chunks of a much larger export.

[amigo]

You won't be able to make any change in the php.ini file unless you're using a dedicated server, and even in that case you'll probably have to ask to the owner of the server to change it for you since you need root access.
Anyway as other people said you can split your db into chunks and restore it one piece at a time

That's not entirely correct. Many hosts are running either in vhost mode or sandbox, both of which offer you transparent control over all functions of your website, including PHP config, since PHP always runs as a CGI binary.

[dengorius]

I'll have to do it manually, how do I find out what my database is called and it's user. i used automatic setups so i'm unsure as to which database is for what website

There is a file called wp-config.php that contains all the informations about your installation: db name, db host, db username and many other options. It looks something like this http://core.trac.wordpress.org/browser/tags/3.1.3/wp-config-sample.php

That's not entirely correct. Many hosts are running either in vhost mode or sandbox, both of which offer you transparent control over all functions of your website, including PHP config, since PHP always runs as a CGI binary.

True, even tho I haven't encountered that kind of configuration too often.  Furthermore as far as I know php can also run as an Apache module (and that's how you have to set it up in order to obtain the configuration that you mentioned). Anyway a call to phpinfo() will show where the php.ini is.

[amigo]

True, even tho I haven't encountered that kind of configuration too often.  Furthermore as far as I know php can also run as an Apache module (and that's how you have to set it up in order to obtain the configuration that you mentioned). Anyway a call to phpinfo() will show where the php.ini is.

That's strange, because PHP is generally always run as a CGI binary on hosting servers. This way you can setup per-user security so that no two users can access each others files through PHP scripts, or execute arbitrary scripts on the file systems that don't belong to them. PHP binary is executed with the individual user privileges and ownerships while php.ini sits in the cgi-bin/ folder and is user accessible to modification.

Remember, as a CGI binary you do not have to restart the httpd server if you make configuration changes in php.ini, thus you would not affect any other users and their websites on the same system.

[alm]

Plenty of shared hosting services just use mod_php. It's easier to configure and requires less resources (CGI requires initializing the PHP interpreter for every request). PHP code is executed by the apache user in that case. Yes, this provides no separation between users.

You can also set some options from .htaccess (php_flag/php_value) or from the PHP script itself (ini_set()).

[amigo]

Plenty of shared hosting services just use mod_php. It's easier to configure and requires less resources (CGI requires initializing the PHP interpreter for every request). PHP code is executed by the apache user in that case. Yes, this provides no separation between users.

You can also set some options from .htaccess (php_flag/php_value) or from the PHP script itself (ini_set()).

Hehe, you make it sound as CGI is worse than module...

The way it works in most configurations is that CGI process will serve a number of requests and then die, so it does not have to start up every time.

But, there is a way to separate the users in the module environment, using suPHP for example, although it's a bit tricky to setup, but it works (I run it right now).

[alm]

Hehe, you make it sound as CGI is worse than module...

From performance point of view, it is. Of course putting an interpreter into the web server is a nightmare from security point of view.

The way it works in most configurations is that CGI process will serve a number of requests and then die, so it does not have to start up every time.

That's not CGI, that's something improved like FastCGI. These protocols can compete quite well with mod_php, although setup is slightly more complex.

But, there is a way to separate the users in the module environment, using suPHP for example, although it's a bit tricky to setup, but it works (I run it right now).

True. This doesn't give you full control over php.ini, though. I would probably be careful with giving customers permission to change php.ini, since some settings may compromise security or performance of the server.