NOTE: as my reputation is non-existent I can't post more than 2 links. So if I say "include http part" I mean for example domain.com should be http://domain.com
Hi cybmeta. What you are saying is indeed part of the problem I was having.
I found out about this before you posted but was too tired to still update my question right away. The reference you give is indeed a very good resource(in normal circumstances you can fully rely on those steps)! Thanks a lot for your effort!
I want to reply my own answer to give some more detailed response.
- IMPORTANT: DO NOT literally replace all occurences of the old sitename with the new sitename. Some data of your wordpress site is
serialized (json_encode/json_decode) and simply replacing those
domains results in wrong sizes of those strings.
- I already did move the site before (with the process described above) and must have had the same issue but then it was easy to just
create an alias in Apache to get the files accessible through the old
- I verified where the pages are loaded from using the Webdeveloper, Toggle Tools in Firefox
So the problems I've experienced are:
- different domains still being referenced
- serialized data in Wordpress
- one reference to www.domain.com while all others were domain.com
- although data seems to be modified only the first page seems to be loaded from subdomain.domain.com and all others are going back to domain.com (which is very dangerous and easily to be confused and modifying your production site! ALWAYS check what URL you're on)
PART1: Get the existing site to work as it should:
- Backup everything
- Installed plugin Better Search Replace in the original site
- Used Better Search Replace to replace www.domain.com(include http part) to domain.com(include http part) and wordpress2.domain.com(include http part) to domain.com(include http part). First without modifying GUID then with modifying GUID. If the first works, dont't use change GUID
- Verified using the Firefox Tools that all content is now retrieved from domain domain.com
PART2: Actually create a clone of the site
- Install Duplicator plugin
- Create empty directory for clone on the webserver
- Create empty db for clone on the webserver
- In Duplicator create a new package
- I had some unmet dependencies: php-zip and php-json
- I got a warning about Archive/file sizes... I went ahead anyway
- I got a timeout error but went checking in the wp-snapshots directory and I had a valid archive.zip and installer.php (these are generated by Duplicator)
- Copied both files to the empty destination location on that server (used cp -a)
- renamed -installer.php to installer.php (don't do this with the archive file as installer.php references the exact name)
- NOTE: it's best to use cp -a as this keeps ownership and permissions. Otherwise you might run into issues with a blank page being shown in the browser
- Unzip -archive.zip in the directory (using unzip; I only did this the second try as Duplicator failed on this step)
- Browse to subdomain.domain.com/installer.php
- Follow the wizard
- Delete the installer created files from the UI
- NOTE: if you want to redeploy in the same directory you'll have to delete all files in this directory if installer.php finished deploying the site successfully previously (as in: Duplicator Installer.php asks you to test your site in the last page of the wizard)
All this being said I was surprised that wordpress uses all those hardcoded URLs and they're not being rendered when called (which should have made this way easier). But I assume wordpress has a good reason.
I hope this helps someone else from spending a lot of time figuring those things out.