Hi folks,<\/p>\n
My blog lived at blog.hoja.in since 2016, on its own WordPress installation, next to the TYPO3 site on hoja.in. This year, together with the TYPO3 upgrade, I moved it to The move itself is not complicated, but WordPress stores its own URL in many places, some of them serialized, some JSON-encoded. Here is how I did it, with the commands from my runbook.<\/p>\n The TYPO3 project has its web root in WordPress has two options for its address: My The constants fix where WordPress thinks<\/em> it lives. They do not fix the thousands of old URLs inside post content, image links, widget settings and plugin options. Never do this with a plain SQL Always run it with Read this table. Does the number of posts look right? Is a table missing that you expected? You see After the replacement I searched once more for the bare old host name, in a dry run:<\/p>\n Three rows were left, in For other plugins that store JSON, search for the host name alone, look at the rows, and replace the escaped form explicitly if needed.<\/p>\n Every old link on other sites, in search results and in my own old posts points to blog.hoja.in. Those must keep working, permanently. In the document root of the subdomain I put only one It keeps the path, so After the switch, I check with curl, not with the browser (the browser cache lies after redirects):<\/p>\n The last command must print Keep the old database dump and the old blog folder until you are sure. The rollback in my runbook is three lines: restore the dump, restore the folder, remove the subdomain redirect. Because the old installation was never changed in place, that really works.<\/p>\n Moving a blog is one of those jobs where a dry run costs five minutes and a mistake costs your search traffic. Use the dry run. Cheers!<\/p>\n blog.hoja.in became hoja.in\/blog: WP_HOME and WP_SITEURL, wp search-replace with a dry run, URLs hidden in JSON, a 301 from the old subdomain, and canonical and sitemap checks.<\/p>\n","protected":false},"author":1,"featured_media":115,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[45,41,42],"class_list":["post-114","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-devops","tag-seo","tag-wordpress"],"yoast_head":"\nhoja.in\/blog<\/code>. One domain, one place for visitors, and the blog’s links and authority count for the main site instead of a separate host.<\/p>\nStep 1: put the files in the right place<\/h2>\n
public\/<\/code>, so WordPress went into public\/blog\/<\/code>. Two things make this work next to TYPO3:<\/p>\n\n
.htaccess<\/code> in public\/blog\/<\/code> with RewriteBase \/blog\/<\/code>. For Apache, the rewrite rules of the deepest directory win, so requests below \/blog\/<\/code> go to WordPress’ index.php<\/code>, not to TYPO3’s.<\/li>\nmyblog_<\/code> in my case). Changing it during a move is an extra risk for no gain.<\/li>\n<\/ul>\n# public\/blog\/.htaccess\n# BEGIN WordPress\n<IfModule mod_rewrite.c>\nRewriteEngine On\nRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]\nRewriteBase \/blog\/\nRewriteRule ^index.php$ - [L]\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteRule . \/blog\/index.php [L]\n<\/IfModule>\n# END WordPress<\/code><\/pre>\nStep 2: siteurl and home<\/h2>\n
siteurl<\/code> (where the WordPress files are) and home<\/code> (the public address). When both are wrong, you cannot even log in to fix them, because wp-admin redirects to the old host. I set them as constants in the config instead, which override the database values:<\/p>\n\/\/ wp-config-production.php (on the server, not in git)\ndefine('WP_HOME', 'https:\/\/hoja.in\/blog');\ndefine('WP_SITEURL', 'https:\/\/hoja.in\/blog');\ndefine('DISALLOW_FILE_EDIT', true);<\/code><\/pre>\nwp-config.php<\/code> only decides which file to load: wp-config-ddev.php<\/code> when IS_DDEV_PROJECT<\/code> is set, otherwise wp-config-production.php<\/code>. The local file sets the same constants to https:\/\/hoja.in\/blog<\/code>. So the same code runs locally and on the server, and no password is in git.<\/p>\nStep 3: replace the old URLs in the database<\/h2>\n
REPLACE()<\/code>: many values are PHP-serialized, where the string length is part of the data. s:22:\"http:\/\/blog.hoja.in\/x\"<\/code> with a longer URL inside and the old length in front is broken, and WordPress silently drops the whole option. wp search-replace<\/code> unserializes, replaces and serializes again.<\/p>\n--dry-run<\/code> first. On my local copy, before exporting it for production:<\/p>\nwp search-replace 'https:\/\/hoja.in\/blog' 'https:\/\/hoja.in\/blog' \n --all-tables-with-prefix --precise --dry-run --report-changed-only<\/code><\/pre>\nTable Column Replacements Type\nmyblog_options option_value 4 PHP\nmyblog_posts post_content 10 PHP\nmyblog_posts guid 50 PHP\nmyblog_yoast_indexable permalink 26 PHP\nmyblog_yoast_indexable twitter_image 3 PHP\nmyblog_yoast_indexable open_graph_image 3 PHP\nSuccess: 96 replacements to be made.<\/code><\/pre>\n--all-tables-with-prefix<\/code> includes plugin tables like Yoast’s, which a plain wp search-replace<\/code> would skip because they are not registered core tables. --precise<\/code> makes it use PHP for every row instead of SQL where it can, slower but safe for serialized data. Then run the same command without --dry-run<\/code>. If you start from the production dump instead, replace both schemes:<\/p>\nwp core update-db\nwp search-replace 'https:\/\/blog.hoja.in' 'https:\/\/hoja.in\/blog' --all-tables-with-prefix --precise\nwp search-replace 'http:\/\/blog.hoja.in' 'https:\/\/hoja.in\/blog' --all-tables-with-prefix --precise<\/code><\/pre>\nThe guid column<\/h3>\n
guid<\/code> in the list above. The WordPress documentation on changing the site URL is very clear that the GUID should not be changed, because feed readers use it to recognise posts they already know. --skip-columns=guid<\/code> does that. My runbook does not skip it; if I did it again, I would add the option.<\/p>\nThe URLs that hide in JSON<\/h3>\n
wp search-replace 'blog.hoja.in' 'x' --all-tables-with-prefix --dry-run --report-changed-only<\/code><\/pre>\nmyblog_yoast_indexable.open_graph_image_meta<\/code>. That column holds JSON, and JSON escapes slashes: the value contains http:\/\/blog.hoja.in\/wp-content\/...<\/code>, so a search for http:\/\/blog.hoja.in<\/code> never matches it. For Yoast the clean fix is to rebuild its index after the move, which is a step in my runbook anyway:<\/p>\nwp yoast index --reindex --skip-confirmation<\/code><\/pre>\nStep 4: 301 from the old subdomain<\/h2>\n
.htaccess<\/code>:<\/p>\nRewriteEngine On\nRewriteRule ^(.*)$ https:\/\/hoja.in\/blog\/$1 [R=301,L]<\/code><\/pre>\nblog.hoja.in\/some-post\/<\/code> lands on hoja.in\/blog\/some-post\/<\/code> in one hop. The permalink structure (\/%postname%\/<\/code>) stays the same, so no per-post redirects are needed. If you change the permalink structure at the same time, do it in a separate step; two changes at once are hard to debug.<\/p>\nStep 5: check what search engines will see<\/h2>\n
# one hop, permanent, path kept\ncurl -sI https:\/\/blog.hoja.in\/some-post\/ | grep -iE '^(HTTP|location)'\n\n# canonical of a post points to the new address\ncurl -s https:\/\/hoja.in\/blog\/some-post\/ | grep -o '<link rel=\"canonical\"[^>]*>'\n\n# the sitemap lists only new URLs\ncurl -s https:\/\/hoja.in\/blog\/sitemap_index.xml | grep -c 'blog.hoja.in'<\/code><\/pre>\n0<\/code>. Yoast generates the canonical and the sitemap from its indexables, which is one more reason to reindex. Finally, robots.txt<\/code> of the main site now lists both sitemaps, the TYPO3 one and the blog one:<\/p>\nSitemap: https:\/\/hoja.in\/sitemap.xml\nSitemap: https:\/\/hoja.in\/blog\/sitemap_index.xml<\/code><\/pre>\nRollback<\/h2>\n
Further reading<\/h2>\n
\n