Background: I have multiple websites running on a rpi4 using nginx and wordpress. I wanted to copy one of the sites to my local network for development and testing purposes. I copied the database, and wordpress files, and setup the config files to listen to port 8082 and to the backup database. The original website is secured and uses certificate for https connections, but obviously the local copy will not.

when I went to the site on my network 192.168.0.213:8082 it went to the homepage, but I couldn't access the login page because I was being redirected to my live website every link I tried. So I updated site url and home url via mysql statement, and was able to get to the login page, and all the other links work, except for the homepage now. Now the homepage is redirecting me to:

192.168.0.213:8082/192.168.0.213:8082/

which is a page that does not exist. I feel like I am super close to achieving what I want if I can fix this one issue. Because it's nginx, there is no .htaccess file, but I am comfortable enough to modify whatever I need and have root access to do whatever. I know sql, command line etc..., but not done this before and stuck. I'm not sure what I'm looking for in the php files to change, or adjust so it's not adding itself to itself.

I tried the fixes I found on here which mainly just say to add 'http://' which I do. I'm still a noob to this, and wondering if I'm just not referencing my local host properly.

And yes, it's a blog site called 'chadsmancave' and the copies of everything are chadsmancavebkp. I can confirm I'm indeed hosting two versions, as changes to the database reflect only in the local vesion, and not in my published version.

Here are some screenshots that will hopefully help:

CodePudding user response：

I move sites almost daily.

First, get and install the official WP CLI installed.

Next, from the site that you are moving from, cd into the WordPress root directory and export the database using:

wp db dump

That will create a SQL dump file in that directory. Move that file to the new location, cd in the WordPress root directory there and import it using the following (obviously replacing the file appropriately):

wp db import your-file-here.sql

Finally, while still in the new location run the search-replace command:

wp search-replace "http://example.com:1234" "https://example.com:5678" --recurse-objects --all-tables --dry-run

The first URL is the old and the second is the new. Make sure to be exact, including protocol (HTTP vs HTTP), domain (www.example.com vs example.com) and port. Never run this without the protocol either, it may or may not do what you expect. Similarly, don't run it with a trailing slash (such as https://example.com/) because that has other implications.

The next argument (--recurse-objects) instructs the CLI to deserialize objects and walk them which is what is needed to safely update the meta and option tables.

The next argument (--all-tables) just means to walk the entire database which includes plugins.

The last argument (--dry-run) means no updates will be made. Always run with it on until you are sure you don't have any typos, then run the command without it.

Note

Also, always take a database backup first before performing and imports or updates, just in case:

wp db dump

Additional note

The search-replace command also has an option called --export that you can use and skip the initial dump. I don't personally do this, however, because if I'm backing up from live to dev, I don't want to incur any extra CPU/IO on the live server, I want that burden to happen on the dev server later on. I could conditionally use it, too, but I just like to have one setup of commands that I use everywhere.

One more note

Browsers, specifically Chrome, tend to remember redirects, at least temporarily. Because of this, when testing that the move did indeed work, I strongly recommend always testing in a private browsing window. I cannot tell you how many hours have been lost by me and other developers because of this. Once you are sure it has been updated, you can go back to a normal browser.

CodePudding user response：

I'm answering this, but going to accept the answer by Chris Haas as it was something he said that solved the issue.

Indeed, I was using Chrome, and it was holding on to that redirect! not f5, or anything would get passed it until I cleared my entire browser data for all time.

Once he said that about browsers and chrome, I went to another machine in my house and typed in the address and it had zero issues. That's when I knew the browser I had been doing all this from was the cause!

Thanks for that. Who knows how long I would have wasted on that, or even called it quits. Add another 5-6 hours on time developers have wasted on this one. XD