After copying website to local, WordPress homepage redirects to duplicate copy

Question

background: I have multiple websites running on rpi4 using nginx and wordpress. I want to copy one of the sites to my local network for development and testing. I copied the database and WordPress files and set up a config file to listen on port 8082 and backup the database. The original website is secure and uses an https connection certificate, but apparently the local copy does not.

When I access the website on network 192.168.0.213:8082 it goes to the home page but I cannot access the login page because every link I try is redirected to my live website. So I updated the site url and home page url via mysql statements and was able to access the login page and all other links worked except the home page now. Now the homepage redirects me to:

192.168.0.213:8082/192.168.0.213:8082/

This is a page that does not exist. I feel like if I can figure this out, I'm very close to achieving what I want. Since it's nginx, there's no .htaccess file, but I'm happy to modify whatever I need and have root access to do anything. I know sql, command line, etc... but haven't done this before and am stuck. I'm not sure what I'm looking for in the php file to change or adjust so that it doesn't add itself to itself.

I tried the fix found here, basically adding the "http://" that I did. I'm still a noob at this and wondering if I'm not referencing my localhost correctly.

Yes, this is a blog site called "chadsmancave" and all content is copied from chadsmancavebkp. I can confirm that I do host both versions, as changes to the database are only reflected in the local version, not the version I publish.

Here are some screenshots, hope they help:

Answer 1

I'm answering the question, but will accept Chris Haas's answer because what he said solved the problem.

Indeed, I'm using Chrome and it retains that redirect! Not f5, otherwise everything will go through it until I completely clear the entire browser data.

Once he said Browser and Chrome, I went to another machine at my house and typed in the address and got zero results. That's when I knew the browser I'd been using to do all of this was the reason!

Thank you. Who knows how much time I might waste on this, or even give up. Plus the 5-6 hours of developer time wasted on this. XD

Answer 2

I move websites almost every day.

First, obtain and install the official WP CLI that you have installed.

Next, from the site you want to move, move cd to the WordPress root directory and export the database using the following command:

wp db dump

This will create a SQL dump file in this directory. Move the file to a new location in the WordPress root directory cd and import it using the following command (obviously replacing the files appropriately):

wp db import your-file-here.sql

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

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

The first URL is the old one and the second URL is the new one. Be sure to be accurate, including protocol (HTTP vs. HTTP), domain (www.example.com vs. example.com). com) and port. Don't run it without a protocol either, it may or may not do what you expect. Likewise, don't run it with a trailing slash (e.g. https://example.com/), as this will have other effects.

The next argument (--recurse-objects) instructs the CLI to deserialize objects and iterate over them, which is required to safely update meta and options tables.

The next parameter (--all-tables) only means traversing the entire database including the plug-in.

The last parameter (--dry-run) means no updates will be made. Always run with it turned on until you're sure there aren't any typos, then run the command without it.

Notice

Also, always take a database backup before executing, importing or updating, just in case:

wp db dump

Additional information

The

search-replace command also has an option called --export that you can use and skip the initial dump. However, I personally don't do this because I don't want to incur any additional CPU/IO on the live server if I backup from live to the development server, I want this burden to happen later on the development server. I could also use it conditionally, but I just like to have a command set that I use everywhere.

Another point

Browsers, especially Chrome, tend to remember redirects, at least temporarily. Therefore, when testing whether this move actually works, I strongly recommend always testing in a private browsing window. I can't tell you how much time I and other developers lost because of this. Once you're sure it's updated, you can go back to your regular browser.