HELP! I Accidentally Changed My WordPress Address URL
As noted here: https://wordpress.org/support/article/changing-the-site-url/
- The “WordPress Address (URL)” setting is the address where your WordPress core files reside.
- The “Site Address (URL)” setting is the address you want people to type in their browser to reach your WordPress blog.
Both of these fields exist within the Settings > General page of your WordPress dashboard.
For the majority of WordPress installations these two fields will contain the same entry / domain name when functional. This is because WordPress installations commonly reside within the root directory and, typically, website owners want their homepage to be accessible at the domain root (not in a sub-directory).
WordPress Address (URL)
The WordPress Address URL field is the one which gets most people into trouble. When it’s changed to a different domain name the WordPress installation attempts to look for its files at that new domain. Unless this exercise was planned, this typically results in a redirect to a 404 error page, and the browser’s address bar showing the incorrect domain. The issue here is that the redirect can keep you accessing your WordPress dashboard to revert the change. And this is when some people take their first steps using cPanel, File Transfer Protocol (FTP), or database editing using PHPMyAdmin. And, in some cases, access to these other tools is not available and you’re stuck with only a WordPress admin account to comfort you while the login page just keeps redirecting to the wrong domain giving you a 404 error. Don’t fret, click here and follow these steps and we’ll see if we can get this sorted out.
Site Address (URL)
This setting controls the formatting of URLs internal to the website. So, for example, if you update this to a different domain the WordPress website will continue load but all of the links will be formatted with the new domain and, when clicked, will take the user to the new URL / domain. This setting is easier to fix as it doesn’t impact your ability to directly access your WordPress dashboard or the login page for your WordPress installation.
If you have cPanel Access you’re in good shape. Easiest: You can access PHPMyAdmin from cPanel and modify the database directly. Or you can setup an FTP (File Transfer Protocol) account and use it to revert your changes. If you choose to setup an FTP account, make sure you give yourself access to the WordPress installation directory. Sometimes it will default to give you access to a user specific FTP directory only.
PHPMyAdmin
From your cPanel, open PHPMyAdmin. In the left-hand pane, select the database in use for the WordPress installation in question. Next, select the wp_options table. You should notice the top two entry records are “siteurl” and “home”. You can double click on either of these to gain the ability to edit the text directly. Once you’ve reverted the change back to the functional URL / domain you should be able to access the website normally. Note that the redirect to the incorrect domain may be saved in your cache. If so, you will need to clear your web browsers cache, or access the page via an incognito or private tab (which will bypass your local cache) in order to see the updated changes.
File Transfer Protocol (FTP) Access
Access the website via FTP and navigate to the WordPress installation’s root directory. There you will find the wp-config.php file. You will need to download this file. I recommend downloading a copy and renaming it to include “backup” in the file name. With this if you accidentally cause an issue while editing you will have an original to fall back on. Open the wp-config.php file in a text editor and add the following code just before the comment line that says “That’s all, stop editing!” You’ll need to edit “http://example.com/wordpress” to match your functional domain / site URL.
define( 'WP_SITEURL', 'http://example.com/wordpress' );
If you also need to update the Site Address (URL). You’ll need to edit “http://example.com” in the following example:
define( 'WP_HOME', 'http://example.com' );
This is a temporary fix and will not update the records in the database. Instead it overrides the database settings so long as the rules are present. So, once you’ve made these changes simply login the WordPress dashboard, go to Settings > General and revert the changes there as well. Once that’s done you should go back into the wp-config.php file and remove any lines of code you added from this step.
I bet by now you’ve been given enough crap about not having the necessary access credentials to fix an issue such as this, so I’ll spare you. When this works please consider leaving a comment letting me know, and / or shoot me a message on reddit.
Things you need to know:
- I’m stepping through this process on a Windows 10 machine, and I have little experience working with Macs. I will include alternative links to Mac solutions where possible, but know that these haven’t been tested or vetted on a Mac machine.
- With regard to the WordPress Dashboard Login page: domain.com/wp-admin/ is not the same as domain.com/wp-login.php. The first is a redirect to the second. But the second is directly accessing the WordPress login page. I will indicate precisely which URL you need to use when you need to use it.
- Wikipedia: HOSTS file: The computer file hosts is an operating system file that maps host to IP addresses.
- Each line in the HOSTS file which begins with a # (number sign, pound symbol, hashtag, tic-tac-toe board) is a comment and will be ignored.
We’ll begin by getting the functional hosting account’s IP address and editing the HOSTS file.
To get the IP address for your hosting server you can use this Google Toolbox Dig tool: https://toolbox.googleapps.com/apps/dig/. Simply enter your functional domain into this tool and click the A button. The tool should run its operation and return the necessary results. The IP address which returns within the listing should be your hosting account’s IP address. If you’re using Cloudflare, or another related DNS service, this IP address will probably be incorrect. And I’m not sure if you can still use it for this purpose (although you might be able to). You may need to undertake other methods to determine your hosting account’s IP address. In that case, this link might represent a good place to start.
Now we need to locate and edit the HOSTS file on your machine. This link should help you understand where to find yours: https://support.rackspace.com/how-to/modify-your-hosts-file/
Once you’ve located the HOSTS file you’ll need to open it so that we can make some edits. Your system may require that the application editing the HOSTS file be launched with administrator approval. It might wait until you’ve typed out all of the edits and try to save before telling you this, also.
Now, we need to edit the HOSTS file by adding the IP address for your original, functional hosting server next to the functional domain name. You should go ahead and do this again adding the www. sub-domain with the second entry as shown:
127.0.0.1 mydomain.com
127.0.0.1 www.mydomain.com
Of course, you need to use your hosting server’s IP address and the functional domain you were using previous to the issue. Once done, save the file. If prompted provide administrator permission to authorize the save.
Now flush your DNS resolver cache. This link should help you understand how to clear your DNS resolver cache on your machine: https://kinsta.com/knowledgebase/clear-dns-cache/.
On a Windows PC, open a command prompt by hitting the start button and then typing cmd and pressing enter. Next type in ipconfig /flushdns and press enter. If successful, you should receive the following message:
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Now you’ll want to either clear your web browser’s cache, or open a Chrome Incognito window or a Firefox Private tab, or your web browser’s equivalent. These options typically allow you to bypass your local cache.
Once that is complete attempt to visit yourdomain.com/wp-login.php in your browser. If everything is going to plan at this point you should see an unstyled login page, and the address bar should show the URL you just entered (that is to say, it didn’t redirect you to the false domain this time, YAY!). If you were redirected, check to make sure you weren’t using the yourdomain.com/wp-admin/ URL. That one will still redirect you. If that wasn’t the case, I’d recommend starting over from the HOSTS file modification step to see if you missed something.
If the form did display you might be tempted to login at this point, but it is doomed to fail. Why? Because the login form itself is set to submit to the incorrect domain still. Even though the page loaded and didn’t redirect you, it still thinks it should exist at the URL / domain indicated in the database. To overcome this, we need to edit the HTML for the form’s action attribute to make it submit to the proper URL / domain BEFORE we attempt to login. We can do this locally using Developer Tools.
Now we’ll use developer tools within a modern browser to modify the form’s action attribute so that it’s submitted to the proper domain / hosting account / database. This link should help you understand how to use developer tools for modern browsers: https://www.lifewire.com/web-browser-developer-tools-3988965.
Within Google Chrome, while viewing the login page, hit the F12 key. Or go to Chrome Menu > More tools > Developer tools. The developer tools will either load into a pane within your browser tab, or it will load in a detached window. Either way, click on the Elements tab to make sure it’s active.
Now you’ll need to locate the HTML for the login form within the developer tools window. We can do this by clicking in the developer tools window and pressing CTRL + F. This will allow you to search for a string. Type in loginform and press enter. This is the default ID given to the login form, so it should take you directly to the line which we need to edit.
<form id="loginform" action="http://incorrect-domain.com/wp-login.php" method="post" name="loginform">
Once that’s located you’ll likely notice that the action attribute is using the incorrect URL / domain. Just double click on that URL and edit it so that it contains the correct domain. This edit only exists locally on your machine. If you refresh the page, or leave and come back, you will need to edit this section of HTML again.
Now you’re ready to login with your WordPress account admin credentials.
If the login attempt failed because the form’s action URL wasn’t updated to use the correct URL, you will be redirected to the incorrect domain’s login page directly: incorrect-domain.com/wp-login.php and likely an error page of some sort.
If the login attempt failed due to invalid credentials, but the action URL was updated correctly, you will receive the standard WordPress error explaining the issue and the login form will bounce as it normally does with incorrect credentials being submitted.
If the login attempt was successful you will be redirected to the incorrect domain, BUT to this URL: correct-domain.com/wp-admin/. This is good. The login cookie for the WordPress installation on the correct website was set successfully on the correct domain with our login attempt, and has been cached. Now just edit the URL in the address bar to use the correct domain name instead of the incorrect one, but leave the /wp-admin/ in the URL. So you should edit it from incorrect-domain.com/wp-admin/ to correct-domain.com/wp-admin/. Once that’s done, press enter.
You should now see the website’s WordPress dashboard load, but it will be unstyled. It will just be a bunch of links and texts which make up the WordPress dashboard.
From here we can navigate to, and edit, the WordPress Address URL and the Site Address URL. You can do so by scrolling down and clicking on the General link underneath the Settings menu item. Or, by visiting this URL directly: correct-domain.com/wp-admin/options-general.php
Just locate the fields on that page and update their values. When done, click the Save Changes button at the bottom of the page. Upon saving you should see the WordPress dashboard refresh properly, with styling information.
This is a good time to edit your HOSTS file to remove the rules you added. Or just add a # at the beginning of each line to have them be ignored. You want to remove these from your local machine before testing in order to make certain it’s working properly publicly. Otherwise, you might get false positives seeing it work locally only due to your HOSTS file edits.
Now visit your website at its correct domain / URL to confirm it’s working properly.
Have an idea, or content you think should be add to this post? Or did I get something wrong, or did you find a typo? Awesome, I’d like to hear from you. Please consider leaving a comment on this post or reaching out by email to let me know.
