moving a wordpress website - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: June 23, 2011, 06:19:29 pm
content: Can anyone advise me on moving a wordpress website from one host to another ?

author: sacherjj
author_rank: Frequent Contributor
timestamp: June 23, 2011, 06:44:09 pm
content: 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.)

author: Simon
author_rank: Unknown
timestamp: June 23, 2011, 07:26:24 pm
content: Quote from: sacherjj on June 23, 2011, 06:44:09 pmThanks, that sounds relatively straight forward. but how do I restore the database on the new instalaion and which configuration settings am i changing ?

author: dengorius
author_rank: Regular Contributor
timestamp: June 23, 2011, 08:41:49 pm
content: 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

author: sacherjj
author_rank: Frequent Contributor
timestamp: June 23, 2011, 08:57:30 pm
content: 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.

author: EEVblog
author_rank: Unknown
timestamp: June 23, 2011, 10:29:56 pm
content: 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 want4) 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 phpMyadminI 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.

author: sacherjj
author_rank: Frequent Contributor
timestamp: June 23, 2011, 10:57:57 pm
content: Quote from: EEVblog on June 23, 2011, 10:29:56 pmEverything should be relative to the root of WordPress, so I believe that is the only path you have to worry about.

author: amigo
author_rank: Regular Contributor
timestamp: June 24, 2011, 02:06:54 am
content: 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.sqlMake 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/mysqltar 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/mysqltar 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.

author: EEVblog
author_rank: Unknown
timestamp: June 24, 2011, 10:59:54 am
content: Quote from: amigo on June 24, 2011, 02:06:54 amMy 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.

author: sacherjj
author_rank: Frequent Contributor
timestamp: June 24, 2011, 01:15:25 pm
content: Quote from: EEVblog on June 24, 2011, 10:59:54 amphpMyAdmin 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.

author: Simon
author_rank: Unknown
timestamp: June 24, 2011, 02:25:24 pm
content: Quote from: EEVblog on June 24, 2011, 10:59:54 amthey are only small websites anyway

author: amigo
author_rank: Regular Contributor
timestamp: June 24, 2011, 09:00:10 pm
content: Quote from: EEVblog on June 24, 2011, 10:59:54 amCompression 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 likeGRANT ALL PRIVILEGES ON db_name.* TO 'username'@'localhost' IDENTIFIED BY 'password';

author: dengorius
author_rank: Regular Contributor
timestamp: June 26, 2011, 12:26:08 am
content: Quote from: EEVblog on June 24, 2011, 10:59:54 amYou 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

author: copiertalk
author_rank: Contributor
timestamp: June 26, 2011, 01:56:48 am
content: 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.

author: Unknown
author_rank: Unknown
timestamp: June 26, 2011, 12:27:28 pm
content: I'm sure that works great with dynamic sites...

author: Simon
author_rank: Unknown
timestamp: June 26, 2011, 12:43:08 pm
content: 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

author: Unknown
author_rank: Unknown
timestamp: June 26, 2011, 02:37:21 pm
content: Quote from: EEVblog on June 24, 2011, 10:59:54 amYour 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.

author: amigo
author_rank: Regular Contributor
timestamp: June 26, 2011, 05:48:22 pm
content: Quote from: dengorius on June 26, 2011, 12:26:08 amThat'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.

author: dengorius
author_rank: Regular Contributor
timestamp: June 26, 2011, 11:57:14 pm
content: Quote from: Simon on June 26, 2011, 12:43:08 pmThere 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 thishttp://core.trac.wordpress.org/browser/tags/3.1.3/wp-config-sample.phpQuote from: amigo on June 26, 2011, 05:48:22 pmTrue, 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.

author: amigo
author_rank: Regular Contributor
timestamp: June 27, 2011, 12:29:23 am
content: Quote from: dengorius on June 26, 2011, 11:57:14 pmThat'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.

author: Unknown
author_rank: Unknown
timestamp: June 27, 2011, 12:56:24 am
content: 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()).

author: amigo
author_rank: Regular Contributor
timestamp: June 27, 2011, 10:54:24 pm
content: Quote from: alm on June 27, 2011, 12:56:24 amHehe, 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).

author: Unknown
author_rank: Unknown
timestamp: June 28, 2011, 10:35:33 pm
content: Quote from: amigo on June 27, 2011, 10:54:24 pmFrom performance point of view, it is. Of course putting an interpreter into the web server is a nightmare from security point of view.Quote from: amigo on June 27, 2011, 10:54:24 pmThat's not CGI, that's something improved like FastCGI. These protocols can compete quite well with mod_php, although setup is slightly more complex.Quote from: amigo on June 27, 2011, 10:54:24 pmTrue. 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.