One of the most common and tedious tasks for WordPress developers is constantly having to move files from local development to the remote server where it can be accessed online. Typically this will be some kind of staging server where online quirks can be sorted out and the client can have a look at the site before it is published. File updates, if coded correctly, will generally not cause any problem since the internal linking should all be relative. But content changes of any kind will affect the database and require the database records to be adjusted, and that is where the tedium can set it.

Not only are constant updates tedious, they are also where errors are often introduced. So it is a good idea to have a workflow that minimizes that risk and the tedium too.

In order to have a WordPress project move from local to live you have to have an installation of WordPress on each server. If you are using Multisite you can save yourself this step once one version is installed, but you still have to have at least one install per server.

I like to setup a common config file for both local and live so that if Wordrpress itself changes there won’t be any database connection issues, and I don’t have to keep updating the config file. Typically I will start a project with the latest version of WordPress, copy the ‘config-sample.php’ file and rename it ‘config.php’. Then instead of just entering the local database info, I add the info for both in simple if/else logic:

if($_SERVER['HTTP_HOST']=='staging_server_name.com' || $_SERVER['HTTP_HOST']=='www.staging_server_name.com'){
define('DB_NAME', 'staging_server_db_name'); // staging server database name
define('DB_USER', 'admin'); //staging server mysql username
define('DB_PASSWORD', 'xxxxxxx'); //staging server mysql password
define('DB_HOST', 'staging_server_host'); // db host
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('LIVE', true);
}
else
{
define('DB_NAME', 'local_db_name'); // local server database name
define('DB_USER', 'admin'); // local mysql db username
define('DB_PASSWORD', 'xxxxxxxxx'); // local server password
define('DB_HOST', 'localhost'); // db host
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('LIVE', false);
}

Now the whole WordPress site can be uploaded to the staging server and it will connect to the remote database without any extra editing of the config file.

Next, the database files need to be moved. The easiest way is to use phpMyAdmin, and export the entire local database as an sql file. Then, on the remote site, import the local database into your remote database (note: on subsequent updates you will need to delete the remote database first; that is, select all the tables and ‘drop’ them from the database, before doing an import).

The database will still contain links to your local setup, ie: http://localhost/name-of-project. Obviously none of these urls will work on the staging server, so we need to change the links. The easiest way to do that is by running SQL queries right in phpMyAdmin.

UPDATE wp_posts SET post_content = REPLACE(post_content,
'http://localhost/my-project', 'http://my-project.staging_server.com');

UPDATE wp_posts SET guid = REPLACE(guid,
'http://localhost/my-project', 'http://my-project.staging_server.com');

UPDATE wp_postmeta SET meta_value = REPLACE(meta_value,
'http://localhost/my-project', 'http://my-project.staging_server.com');

UPDATE wp_options SET option_value = REPLACE(option_value,
'http://localhost/my-project', 'http://my-project.staging_server.com');

UPDATE wp_links SET link_image = REPLACE(link_image,
'http://localhost/my-project', 'http://my-project.staging_server.com');

UPDATE wp_users SET user_email  = REPLACE(user_email,
'http://localhost/my-project', 'http://my-project.staging_server.com');

When I start a project I copy and paste a blank version of this file and make all the neccesary changes to reflect the project, then just save it in Notepad or any other simple text editor. That way I can just copy and paste it into the SQL query line in phpMyAdmin and make the changes in less than a second. Since the files are usually updated at least once a day this method saves a lot of time.

Occasionally, particularly with child themes, custom headers and menus do not make the transition. All that is needed is to log into the dashboard, re-select the header and where the custom menu will display.

When the project is ready to go live, the same method will work with the new parameters of the live site entered. For maintenance, solving problems, and working on future updates, it is helpful to streamline the process of local to staging to live server.