Question

How to stop 'samename'.net Wordpress redirecting to separate 'samename'.com Wordpress in browser

Posted March 25, 2020 266 views
ApacheWordPressDNSUbuntu 18.04

Having initially set up a samenamedomain.com wordpress droplet, I then setup a separate samenamedomain.net wordpress droplet, each domain pointing to their respective ip addresses. Certbot eventually said the new .net site is good to go. Domain.net/wp-admin loads in the browser just fine. Navigating to the ip address of domain.net loads the domain.net page just fine. However, typing domain.net into the browser automatically loads domain.com, whereas I would like the option to keep them separate.

Both droplets are running one-click deployments of Wordpress on a LAMP stack, Ubuntu 18.04. It feels like some service somewhere is taking liberties trying to be helpful. Any ideas how to fix this?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers

brettles,

WordPress is aggressive with redirects (http code 301). It will check for the correct domain by comparing the value of Settings > General > WordPress Address and/or Site Address with the domain from your urls query (as typed into the browser). These settings correspond to the options in the table wpoptions with optionname = ‘siteurl’ and option_name = 'home’. They are probably the same value for any website installation.

I think WordPress will redirect you to the url that results from substituting the domain in Settings/wp_options into the url of the browser’s request. Whatever redirect it does, the domain settings must be correct.

If you have two different WordPress sites and you make each from scratch, you would simply set the domain with the install or soon thereafter in the administration dashboard. Maybe you copied database data from one site to the next. It’s not that simple.

Can you access the admin dashboard at samename.net? If not, try the database over SSH (see the hints at the end of this).

Did you set the 'siteurl’ and 'home’ values correctly?

See the WordPress documentation for function getoption() for common options: https://developer.wordpress.org/reference/functions/getoption/ .

If you copied the database data by dumping a logical backup (with mysqldump) and then put it into the new database (with mysql < [dump-file]), not only will you have copied the siteurl and home option settings, you will have copied any other site urls in your data. Data editing is necessary for a 'WordPress database migration’. You could search on those words and find useful information.

Maybe start with webpage “Move a WordPress Site by Moving the Database and Files” (https://css-tricks.com/moving-a-wordpress-site/). When you get to the bottom of that webpage, there is a hyperlink with the text 'moving WordPress to HTTPS’ which might also be useful. It illustrates an instructive case of editing urls of the data within the database (e.g. the UPDATE command). You may need to edit your urls to swap 'samename.com’ to 'samename.net’. If you have post content with hardcoded links from one webpage to another, that will have to be changed.

I like to make a copy of my dump file and edit it using the document-wide replacement feature of a text editor (e.g. geany). The sed command would work too. A really large text file might be impractical. You could dump different groups of tables and make several smaller dump files. I would get familiar with the values that need to be replaced because it would be easy to screw up the data in the dump text file. Altering the data in the database at the receiving location requires good SQL skills and likely will not facilitate the use of regular expressions (though I believe it can be done).

Some SQL hints:

# mysql
MariaDB [(none)]> show databases;
MariaDB [(none)]> use some_wordpress_db;
MariaDB [some_wordpress_db]> describe wp_options;
MariaDB [some_wordpress_db]> select * from wp_options where option_name = 'home' or option_name = 'siteurl';
MariaDB [some_wordpress_db]> describe wp_posts;
MariaDB [some_wordpress_db]> select count(ID) from wp_posts where post_content like '%samename.com%';
MariaDB [some_wordpress_db]> select ID, guid from wp_posts;

The post guid is the Globally Unique Identifier. Obviously, it should be globally unique. If you make a duplicate copy, then you want to edit the copy for uniqueness. You might decide the edit the values for sanity as well. See the documentation for WordPress function theguid(): https://developer.wordpress.org/reference/functions/theguid/ .

Good luck!

edited by MattIPv4

Hello, @brettles

What happens when you do a curl or wget to your domain, e.g

curl -IL domain.net or wget domain.net

Can you see any 301 Moved Permanently references? Also have you checked the WPHOME and WPSITEURL values of the domain.net WordPress installation as well?

You can see the values of those by accessing your database and from the WordPress admin dashboard as well.

In order to see those values from the database you can use the command line and execute the following commands:

SELECT * FROM wp_options WHERE option_name='home';

and for siteurl:

SELECT * FROM wp_options WHERE option_name='siteurl';

I will recommend you to check those values as this is where things can go wrong and you end up with a redirect issue. If they’re okay you can still check with curl or wget and see if there is 301 rule somewhere.

Let me know how it goes.

Regards,
Alex

Submit an Answer