Replace WordPress domain and paths in the database

In the last blog post I explained how I move a WordPress website to another server. In step 7 I told you, that you have t replace the domain in the database. But this is not the only replacement you might have to do. Today’s blog post will give you some more examples of potential replacements and some other things you have to consider.

Let’s have a look at the most basic replacement again. This command will replace the domain in all tables in the database, with the prefix of the current WordPress installation:

wp search-replace "https://staging.example.com" "https://example.com" --all-tables-with-prefix

It will handle replacements in simple strings, as well as in serialized PHP objects. You should also replace the path to the current installation, if it differce between the servers:

wp search-replace "/home/staging.example.com" "/home/example.com" --all-tables-with-prefix

Search for old domain

After you have run the previous commands, the old domain should be replaced in all tables. You can simply check that with another WP-CLI command:

wp db search "https://staging.example.com"

Additional replacements

Unfortunately, many plugins save complex data in other formats. Therefore it’s also advised, to search for the following patterns and replace them, as long as the previous search still returned some values.

Search patternReplacementComment
http://example.comhttps://example.comNew domain without SSL
http://staging.example.comhttps://example.comOld domain without SSL
//staging.example.com//example.comprotocol-relative paths
https:\/\/staging.example.comhttps:\/\/example.comJSON objects (run this for all previous patterns)
@staging.example.com@example.comemail domains (optional, as somethimes not wanted)
staging.example.comexample.comDangerous!
Replacements for domain changes

There are some variants to consider. For the first four are replacements, you should also “escape” all slashes, as objets might have been stored using a JSON string. Replacing email addresses is optional, as your new system might not use it’s own emails (like when migrating from Live to Staging) or if you don’t want to show them in the frontend with the different domain.

The last replacement seems to be the easiest one, as it would do all the revious replacements in one go. But it could potentially break things, as the domain name might be part of an image name in the media library, which would result in a broken path to that image. So it’s best not just to replace the domain name only.

Additional steps

Themes, plugins or the server could use caches. There are different methods to clean those caches.

Fusion Builder (e.g. Avada Theme)

At “Avada/Themename | Theme Options | Performane | Reset Fusion Caches”, just use the button “Reset Fusion Caches” to remove all files from the cache.

Autoptimize

In the adminbar, you will find an entry “Autoptimize” and at the end of that entry a link named “Delete Cache”.

PageSpeed

To flush the PageSpeed cache, you have to connect to your server and run the following command:

touch /var/cache/pagespeed/cache.flush

It might take some seconds for the cache to be fully flushed. After it’s empty, remove the file:

rm /var/cache/mod_pagespeed/cache.flush

For more information on how to flush only parts of the cache, check the PageSpeed docs.

Posted by

Bernhard is a full time web developer who likes to write WordPress plugins in his free time and is an active member of the WP Meetups in Berlin and Potsdam.

Leave a Reply

Required fields are marked *.