Support » Developing with WordPress » Error when Changing Site URL

  • I’m trying to redefine the URL used for accessing a WordPress site of mine. In this case I’m referring to a website running on my own computer using XAMPP. The desire is to duplicate an existing website and preserve the ability to access the present Version while testing changes on a new Version. While NOT able to say for certain it does seem, to me, like lots of others would also find this desirable.

    I found what looks to be the WordPress proposed method to do such here . The basic problem I’m encountering is that WordPress seems to invent an invalid URL that produces a browser error saying that said website cannot be found. The invalid URL creation is described as follows:

    1. My intended URL is of the form “”
    2. The invalid URL reported by the browser is of the form “” (which I’d say is very unlikely to ever be valid).

    My own findings when attempting to follow the WordPress proposed methods are as follows:

    1. Edit wp-config.php method : Produced error described above.
    2. Edit functions.php method : This method suggested loading the login page, which I did after making the indicated changes to Functions.php. After entering login information this produced the normal WordPress Dashboard page for administering the website which looked completely normal. This included having the new URL displayed on the “Settings>General” Page. However, when selecting the “Visit Site” link the browser reported the same invalid URL error.
    3. Relocate method : Did NOT try
    4. Change URL directly in the database method : No need to do it. The database had the correct value.

    The Version of WordPress is 5.7.2 and XAMPP is Version 7.4.33. I do run the site using a Child Theme of my own making so I did opt to activate the standard theme upon which the child is based but NO change in results.

    Could definitely use some help figuring out what’s producing this result.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter aajax


    After a bit more troubleshooting I now have a bit more to report.

    First I added another of my websites to the new (7.4.33) instance of XAMPP to try a verify that the problem was being caused by WordPress. This other website does NOT use WordPress and works just fine with this new version of XAMPP.

    Second I updated /etc/hosts on the client computer to designate the invalid URL as an alias for the correct URL. Then also updated the Apache configuration to recognize the same invalid URL but refer it to the same instance of WordPress. The website now works as expected. There is NO sign of the invalid URL that shows up anywhere. The WordPress “Setting>General” show the correct URL for both the “WordPress Address URL” and the “Site Addr5ess URL” which are the same.

    While I’m quite uncertain about the implications of using this configuration for my testing, I’m also quite certain that my hosting service does NOT have a way for me to implement such a workaround.

    Moderator bcworkz


    Editing your machine’s hosts file is the best way to implement an arbitrary domain name on a local WP installation. /etc/hosts is generally correct for ‘nix systems. Windows machines keep it elsewhere which varies by version. Do a search to find out where it is for your specific version. You do need to restart the computer for new hosts configurations to take effect.

    You can even self-issue a SSL cert for your private domain name so that HTTPS is functional. Your browser will initially balk because the cert is not from a recognized cert authority. You’ll need to convince it that you understand the situation and to proceed normally.

    On a new WP installation, the only other thing you need to do is set the correct home and site URL in settings, then set your preferred permalink type. A hosts entry only affects the current machine. Others from a LAN or outside need to still use other methods, if such access is allowed at all.

    For a hosting service, many have some sort of temporary domain name you can use for a while, but you are required to register a proper domain name for a hosted site. Most hosts offer domain registration service if you have no other preference of registrars. It can take up to a day or two for a new domain’s DNS records to propagate though the entire internet.

    You can set a hosts file to recognize a registered domain but to get content from a local installation. The public site for which the domain properly belongs will not be accessible from that computer until the hosts entry is removed. This can be a useful way to develop a site locally, then eventually migrate it to the public site. This way all domain references in the DB will already be correct. The alternative is to do a global search and replace during migration when domain names differ.

    Thread Starter aajax


    Yes bcworkz, I agree with what you say and have done all that you suggest other than trying to also use SSL.

    The problem is that I have a test environment that includes everything needed to run and use WordPress on my own computers for development and testing purposes. Now I want to create a new website that starts off being an exact replica of an exiting website but that needs to be accessed by a different URL. This allows me to experiment with major changes I’m contemplating making on one website and preserve the ability to compare the revisions with the existing website. In that, access both running on the same server being accessed from the same client and browser simultaneously.

    According to referenced documentation it should be pretty easy to change the URL but none of that is working in my case and the result is so bad I loose the ability to even access the website absent the trickery I mentioned. However, I’m NOT at all confident about that situation being a reliable way to test and it certainly does NOT produce something that can then be ported to a hosting service.

    I suppose it is possible that WordPress has at some time in the past been able to allow the URL to be changed but that is NO longer the case. In that, the documentation has NOT kept up with the code. That is what I have to assume at present.

    Moderator bcworkz


    I’ve used the proscribed method many times without issue. Admittedly, not recently, but I cannot imagine why it would no longer work. I’ve also not heard of others having trouble, and I read a lot of forum posts 😉

    If you don’t follow the steps in the suggested sequence, you can have trouble with access, but it is recoverable. The Better Search and Replace plugin option (#1 in the second ordered list linked above) is IMO the easiest way to update the DB’s URLs. But if you’ve lost access due to doing things out of order, the database script (#3) is your best option since WP access is not necessary.

    Nearly all WP devs I know of agree that working on a local installation is the best way to develop on WP. Once you establish a good system of migration I’m confident it’ll work well for you as well. The first time through trying something new will inevitably be a struggle. It’ll get easier with practice and repetition. For developing a new site that does not yet exist, consider using the correct domain name (if known already) as your hosts file entry. Then the DB’s URLs needn’t be updated on migration. Just don’t forget to remove the entry when you migrate or things could get rather confusing 🙂

    Thread Starter aajax


    OK, it looks like the article you reference is also referenced by the article I originally referred to but under a heading titled Moving Site which I’m afraid I concluded to be different from what I was wanting to do. Upon further consideration “Moving the Site” and “Changing the URL” are pretty synonymous and I should have paid more attention to that section. The actions I undertook did nothing to update the database to replace occurrences of the old URL with the new one.

    What I’ve now done is update my original website so that I now have the latest version of both WordPress and all the plugins that I use. Then I installed the “Better Search Replace” plugin and performed the so-called “dry run”. In addition to the wp_options it finds one instance in wp_users and a bunch in wp_posts and that’s it other than wp_options.

    The instructions referenced here specify logging in and then manually changing both URLs found in General>Settings which, I think, is where the main values used for the website are maintained. When changed manually the website becomes dysfunctional (e.g., the article says “expect to see a 404 page”). Therefore, I’m thinking I should be able to use “Better Search Replace” to update the tables other than wp_options first and then change wp_options after that either manually as described are possibly with “Better Search Replace”. At that point I’d expect the website to work correctly with the new URL. Note: in my case neither the server nor the database has changed (other than the desired updates to the existing database).

    Now I’ll need to create a new website by restoring the backups (i.e., to a new database & and new instance of the WordPress files) in order to continue to use the original URL for accessing the original. The new database ends up with a new name in order to run on the same server.

    What am I failing to understand? Keep in mind that even if this is a bit of an experiment I haven’t much to loose on my own testing computers.

    • This reply was modified 1 week ago by aajax.
    • This reply was modified 1 week ago by aajax.
    Moderator bcworkz


    When you follow the step by step instructions, it’s easy to lose track of what each step is doing and why it’s important. If you can wrap your mind around what’s important when, the exact order of the process is less important than doing what’s necessary at the right time.

    For the site to function on a minimal level, the site and home URL settings need to be correct. Everything else can be fixed up later as the final step. You can always patch up the site and home URL settings to fit the DB’s desired location/URL through the phpMyAdmin app. It’s not a serialized value, so it’s safe to manually edit. Ensure you use the correct protocol and there should be no trailing slash.

    This doesn’t fix all the other references such as within the posts table, but it should at least give you access to the back end so you can run the search and replace routine to fix up all the other URLs. Or use the interconnect/it script to fix up the DB in its entirety without needing to log in first.

    If you intend to continue to use your local installation after migrating to production, it’s kind of silly to alter it prior to export, only to need to put it back afterwards. I typically will go ahead and export/import with the URL values being wrong for the intended destination. Thus my local installation keeps working as it always had. Then on the DB at the destination I use one of the above methods to fix the URLs to work for the destination.

    All that’s really required here is to migrate the DB to where it’s needed and to alter all of its URLs to fit the new location. It doesn’t really matter much how you manage that. The only other important thing is to use a proper script that’s capable of managing URLs in serialized arrays.

    Thread Starter aajax


    Well now, I don’t think I’m any closer to explaining what went wrong that produced the very strange result from my original attempts that triggered this post. However, given the discussion herein I opted to go back and start over and it turned out to be quite easy to get the desired result. Keep in mind this is pretty easy to do when I have everything running on my own computers with XAMPP providing the underlying server support. Might to work in other scenarios.

    A basic outline of what worked for me follows:

    1. I restored the original website to its’ normal operating state on a new instance of XAMPP running on another previously uninvolved computer. On the client I have /etc/hosts set to use the IP address of the server for my original domain name.
    2. On the server I then updated the Apache configuration (i.e., file named httpd-vhosts.conf) to specify the new URL as an alias (i.e., ServerAlias) for the original URL. On the client I updated /etc/hosts to also use the same IP address of the server for the new URL.
    3. From the client performed a login using the old/original URL and installed the “Better Search Replace” (BSR) plugin. Ran BSR in trial mode which showed the original URL was only found in the tables named wp_options, wp_users, and wp_posts.
    4. Using BSR changed all of the old URLs to the new one except those in the wp_options table.
    5. Navigated to the Settings>General page and changed the Home & Site URL to the new name. Bingo! The site is now running with the new URL.
    6. Transfer this new instance of the original website which is now running under a different URL to my normal/original test computer which now has 2 instances of my original website running under their own unique URL, which is the result I originally set out to achieve.

    Note: I’m most grateful to bcworkz for the assistance provided in figuring out how to do this. MANY THANKS!

    • This reply was modified 5 days, 19 hours ago by aajax.
Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.