For some years now hungsblog was available under the .de top level domain. However, recently I was able to obtain the corresponding .com. So, naturally I was very excited to migrate the website from one domain to the other and am happy to report all the things to consider while doing so.
TLDR:
The two important things to keep in mind when migrating an existing website to another domain are redirecting the old traffic and updating the siteurl of the new one including all content which mentioned the old website.
Disclaimer: Always create backups. Migrating should also be done by people with appropriate background knowledge, as some changes are almost irreversible and implications and effects depend on the whole system.
Traffic and Server
1. Buying the domain and set DNS entries
2. Redirect traffic from old to new
To tell google and anyone else who uses URLs of the old domain, that we changed to the new one, we need to set up redirects. A Statuscode 301 indicates, that the change is a permanent one. I use a Caddy server and the configuration can be seen below. Because WordPress is a content management system (CMS), even if the siteurl changes (e.g. from hungsblog.de to hungsblog.com) the underlying path structure stays the same. That’s also the reason, why the one liner works as intended and will redirect any url to an old post to the correct new url.
hungsblog.de:443 {
redir https://hungsblog.com{uri} 301
}
3. Notify Google Search Console
If you registered your site with the google search console, it might not be indexed initially, because it is found to be a duplicate of an existing site. This can be done under settings > change address. However you have to have ownership over both domains.
Database
1. Backup Database
I wanted to refactor my database structure anyway so I used this occurance as a happy excuse to do just that.
First we create a new database (new_db). Then we generate a database dump of our old database (old_db) and feed all SQL queries into new_db (see bitnami). Lastly, don’t forget to grant privileges to the wordpress database user to be able to access new_db.
##############
# The process could look like this, but you could also use a DB client of your choice.
# In my case, I use a mariadb instead of a mysql but the idea should be the same.
##############
# create new db
mariadb -u root -p -e "CREATE DATABASE new_db"
# dump (pay attention to your version, as this might be deprecated)
mysqldump -u root -p old_db > backup.sql
# restore
mariadb -u root -p new_db< backup.sql
# grant privileges
mariadb -u root -p -e "GRANT ALL PRIVILEGES ON new_db.* TO <user> "
It is quite important to create the full backup. A “CREATE TABLE AS SELECT * FROM” will not suffice because the necessary table constraints will not be created. This will not be apperent immediately, however when i started to create a new post i get the errors:
Warning: Attempt to read property “post_type” on null in /srv/www/wp-includes/post.php on line 7494
Warning: Attempt to read property “post_type” on null in /srv/www/wp-includes/post.php on line 7495
Warning: Attempt to read property “ID” on null in /srv/www/wp-includes/post.php on line 7499
Warning: Attempt to read property “post_type” on null in /srv/www/wp-includes/post.php on line 7754
Googling the issue gave me a good idea about how this error occured (wordpress). I assume, that whenever you create a new blog post, WordPress creates a new row in the database. The appropriate table normally would have an AUTOINCREMENT constraint, which would then be able to return a new post ID. Using this post ID, the WordPress engine creates an object containing all necessary information. However, if we don’t include the constraint, no ID is generated, nothing is returned, thus no post object can be instantiated and thus we attempt to read a property on a null object.
2. Rename siteurl
To let WordPress build the correct url internally, we also need to change the global configuration for the siteurl. This can be done in the UI under settings > general, or directly in the database.
-- update old links
UPDATE new_db.wp_options
SET option_value = replace(option_value, 'hungsblog.de', 'hungsblog.com')
WHERE option_name = 'home' OR option_name = 'siteurl';
3. Rename all mentions from the old domain
This is a very important step, which a lot of sites forget to mention, especially when you already have content. Although the siteurl changed, content already written and saved in the database did not. This is especially apparent for images. If a post with an image is loaded, the image will most likely have a reference to your old domain. This should not be a probably, as we set the redirect already, however this still can lead to slow loading speed and cause some weird behaviour. In my case, if I’d access the homepage, I would end up in a endless redirection loop.
To clean up the right tables I am refering to templatetoaster. The appropriate statements are as following:
UPDATE hungsblog.wp_posts SET post_content = replace(post_content, 'hungsblog.de', 'hungsblog.com');
UPDATE hungsblog.wp_postmeta SET meta_value = replace(meta_value,'hungsblog.de', 'hungsblog.com');
UPDATE hungsblog.wp_usermeta SET meta_value = replace(meta_value, 'hungsblog.de', 'hungsblog.com');
UPDATE hungsblog.wp_links SET link_url = replace(link_url, 'hungsblog.de', 'hungsblog.com');
UPDATE hungsblog.wp_comments SET comment_content = replace(comment_content , 'hungsblog.de', 'hungsblog.com');
WordPress
Lastly, it is important to tell the WordPress installation, which database it should use. To do that, edit the wp-config.php file and replace the old database with the new one.
