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"
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.
|http://example.com||https://example.com||New domain without SSL|
|http://staging.example.com||https://example.com||Old domain without SSL|
|https:\/\/staging.example.com||https:\/\/example.com||JSON objects (run this for all previous patterns)|
|@firstname.lastname@example.org||email domains (optional, as somethimes not wanted)|
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.
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.
In the adminbar, you will find an entry “Autoptimize” and at the end of that entry a link named “Delete Cache”.
To flush the PageSpeed cache, you have to connect to your server and run the following command:
It might take some seconds for the cache to be fully flushed. After it’s empty, remove the file:
For more information on how to flush only parts of the cache, check the PageSpeed docs.