Moving WordPress

In few steps, WordPress can be moved to another host. In my scenario, is located on shared host with cPanel as web administration tool. I also have local Linux installation (Fedora Core 10) with MySQL and Apache. Idea is to move complete installation from public host to my LAMP computer. Why? Because this way I will have test and production site. Test site isn’t public and I can play and try modifications before publishing. Posts can be written locally, and after finishing, just perform copy & paste from test to production site. And last but not least – backup. Have a WordPress site on two physically different places, will speed up recovery if needed.

Before moving WordPress, prepare your local LAMP / WAMP server – means to have Apache, MySQL and PHP installed and configured.

  1. Download and unpack WWW home from shared host backup
  2. Check permissions of WWW root
  3. Check permissions inside wp-content directory
  4. Edit wp-config.php
  5. Edit or disable wp-admin/.htaccess
  6. Delete wp-content/advanced-cache.php symbolic link
  7. Reload database dump
  8. Edit siteurl in table wp_options
  9. Turn off WP-Cache (optional)
  10. Check short_open_tag in PHP and AllowOverride in Apache
  11. Conclusion

1. Download and unpack WWW home from shared host backup
From public host, download home directory backup and MySQL dump. If you have cPanel as WEB administration, under Files section click on Backups icons. After clicking on Backups icon, System Backups page will be displayed with following options:

  • Download a Home Directory Backup
  • Download a MySQL Database Backup

Download Home Directory Backup and MySQL Database Backup. Unpacking only WWW root from tar.gz file on local Linux host can look like:

tar zxf /tmp/  ./public_html/

After unpacking, copy or move “public_html” content to the WWW root of local host. In Red Hat family, WWW root is located at /var/www/html

2. Check permissions of WWW root
After unpacking WWW root and placing to the /var/www/html, check owner and RWX permissions. Shared and local host will certainly have different owner of httpd process. Shared host has (in my case) redips user, while local host will run httpd under Apache user. Just be sure that Apache user on local host have permissions to read from WWW root. If you have WP-Cache module, then some parts of WWW root should be enabled for writing too.

3. Check permissions inside wp-content directory
If you have WP-Cache module installed, then httpd process should have write permissions inside wp-content directory. Please set write permissions with more care if you are not the only user on your local host. Otherwise, giving write permissions to the httpd process (Apache user) on wp-content components can be applied like:

cd wp-content
chmod 777 .
chmod 777 cache/
chmod 666 wp-cache-config.php

4. Edit wp-config.php
I have different MySQL user on public and local host. If this is not your case (you have the same user), then you can skip this step. Otherwise, open wp-config.php and define username and password to access MySQL database on local host (database name will probably be the same).

// define MySQL username and password for local host
define('DB_NAME', 'database_name');
define('DB_USER', 'write_local_username');
define('DB_PASSWORD', 'write_local_password');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

5. Edit / disable wp-admin/.htaccess
If you have wp-admin secured with .htaccess, you will have to edit path to the passwd and group in .htaccess file, or just disable htaccess security for local host. You can disable htaccess security by renaming .htaccess to htaccess (just remove leading dot).

# disable htaccess security for local host
cd wp-admin
mv .htaccess htaccess

6. Delete wp-content/advanced-cache.php symbolic link
If you have installed WP-Cache module, you should check path of advanced-cache.php symbolic link inside wp-content directory. It is very likely that WordPress installed on shared host will have different location compared to local host. To apply this fix, just delete advanced-cache.php, and after disable / enable WP-Cache, symbolic link will be correctly recreated.

# delete symbolic link
rm wp-content/advanced-cache.php

Lately, after login to local WordPress site, you could even completely disable WP-Cache – see step 9 Turn off WP-Cache (optional).

7. Reload database dump
If MySQL dump has create database and use statement in the beginning of the script, then database load can be started like:

mysql -p < redips.sql

Otherwise you will have to create database manually and then run load with named database:

mysql -p redips < redips.sql

Switch "-p" will ask password, and "redips" means to recreate (drop / create) all tables in "redips" database.

8. Edit siteurl in table wp_options
After database loading, siteurl should be changed from public name to local name. If you do not change siteurl, accessing to the local WordPress site will be redirected to the public site. Change can be applied with MySQL Query Browser, or you can do it from BASH command line:

# define BASH variable $URL
# print UPDATE statement and pipe it to the MySQL client
echo "update wp_options set option_value='$URL' where option_name='siteurl'" | mysql -p dbname

Actually, this can be only one line. Replace $URL with URL of the local host in second line and press enter. I hope that is clearer, if it is written in two lines.

9. Turn off WP-Cache (optional)
Probably you will be the only visitor of your local WordPress installation, and you can disable WP-Cache module. You do not need "turbo" performance on local host WordPress version, and after changing PHP code you will not need to refresh cash. After you click on WP-Cache in WordPress administration panel, disabling WP-Cache will recreate wp-content/advanced-cache.php symbolic link.

10. Check short_open_tag in PHP and AllowOverride in Apache
In fresh Fedora Core 12 installation, I had to set in /etc/php.ini file:

short_open_tag = On

My default WordPress theme uses short open PHP tags. Next, please check AllowOverride in /etc/httpd/conf/httpd.conf file.

# AllowOverride controls what directives may be placed in .htaccess files
AllowOverride All

Default settings for Apache AllowOverride directive is "None" and that will break WordPress permalinks.

11. Conclusion
Have a local copy of WordPress site is a really helpful for the purpose of testing and experimentation. I hope this migration cookbook will be useful for you as it is for me.

Leave a Comment