Note: Both settings should include the http:// part and should not have a slash "/" at the end.
Every once in a while, somebody finds a need to manually change (or fix) these settings. Usually this happens when they change one or both and discover that their site no longer works properly. This can leave the user with no easily discoverable way to correct the problem. This article tells you how to change these settings directly.
Additional information is presented here for the case where you are moving WordPress from one site to another, as this will also require changing the site URL. You should not attempt to use this additional information if you're only attempting to correct a "broken" site.
There are four easy methods to change the Site URL manually. Any of these methods will work and perform much the same function.
It is possible to set the site URL manually in the wp-config.php file.
Add these two lines to your wp-config.php, where "example.com" is the correct location of your site.
This is not necessarily the best fix, it's just hardcoding the values into the site itself. You won't be able to edit them on the General settings page anymore when using this method.
If you have access to the site via FTP, then this method will help you quickly get a site back up and running, if you changed those values incorrectly.
1. FTP to the site, and get a copy of the active theme's functions.php file. You're going to edit it in a simple text editor (like notepad) and upload it back to the site.
2. Add these two lines to the file, immediately after the initial "<?php" line.
Use your own URL instead of example.com, obviously.
3. Upload the file back to your site, in the same location. FileZilla offers a handy "edit file" function to do all of the above rapidly; if you can use that, do so.
4. Load the login or admin page a couple of times. The site should come back up.
5. Repeat the above steps, but remove those lines. IMPORTANT: Do NOT leave those lines in there. Remove them immediately after the site is up and running again.
If there is no functions.php file in the theme:
Create a new text file called "functions.php".
Edit it with notepad, and add this text to it, using your own URL instead of example.com:
<?php update_option('siteurl','http://example.com'); update_option('home','http://example.com'); ?>
Upload that to your theme directory, then proceed as stated above. Remove the file afterwards.
Here are some additional details that step you through transfering a LAN-based wordpress site into an externally accessible site as well enabling editing the wordpress site from inside the LAN.
Two important keys are router/firewall modifications and the "wait 10+ minutes" after making the changes at the end.
-using ssh to log into your server (nano is a server preinstalled text editor)
-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-add lines just after <?php
-refresh your web browser using your external site url
-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-remove those lines you just added (or comment them out)
-access your router (these steps are for pfSense, other routers should have similar settings to look for/watch out for)
-add to firewall/nat table a line like this
-add to firewall/rules table a line like this
-uncheck the box at System/advanced/network address translation/Disable NAT Reflection
"Disables the automatic creation of NAT redirect rules for access to your public IP addresses from within your internal networks. Note: Reflection only works on port forward type items and does not work for large ranges > 500 ports."
Then go do something for ten minutes and when you get back see if the external url http://your.site.url:port/yourblog from a LAN browser brings the page up correctly.
WordPress supports an automatic relocation method intended to be a quick assist to getting a site working when relocating a site from one server to another.
1. Edit the wp-config.php file.
2. After the "define" statements (just before the comment line that says "That's all, stop editing!"),
insert a new line, and type:
3. Save your wp-config.php file.
4. Open a web browser and manually point it to wp-login.php on the new server.
For example, if your new
site is athttp://www.yourdomainname.com,
then type http://www.yourdomainname.com/wp-login.php into your browser's address bar.
5. Login as per normal.
6. Look in your web browser's address bar to verify that you have, indeed, logged in to the correct server.
If this is the case, then in the Admin back-end, navigate to Settings > General and
verify that both the address settings are correct. Remember to Save Changes.
7. Once this has been fixed, edit wp-config.php and either completely remove t
he line that you added (delete the whole line), comment it out (with
true value to
false if you think it's likely you will be relocating again.
Note: When the RELOCATE flag is set to true, the Site URL will be automatically updated
to whatever path you are using to access the login screen.
This will get the admin section up and running on the new URL, but it will not correct any other part of the setup. Those you will still need to alter manually.
If you know how to access phpMyAdmin on your host, then you can edit these values directly to get you up and running again.
When moving sites from one location to another, it is sometimes necessary to manually modify data in the database to make the new site URL information to be recognized properly. Many tools exist to assist with this, and those should generally be used instead of manual modifications.
This is presented here as information only. This data may not be complete or accurate.
You should read the Moving WordPress article first, if attempting to move WordPress from one system to another.
Like many WordPress administrators, you may be running several WordPress installations off of one database using various wp-config.php hacks. Many of these hacks involve dynamically setting table prefixes, and if you do end up altering your table prefix, you must update several entries within the prefix_usermeta table as well.
As in the above section, remember that SQL changes are permanent and so you should back up your database first:
If you are changing table prefixes for a site, then remember to alter the table prefix in the usermeta tables as well. This will allow the new site to properly recognize user permissions from the old site.
UPDATE `newprefix_usermeta` SET `meta_key` = REPLACE( `meta_key` , 'oldprefix_', 'newprefix_' );
In your WordPress Theme, open each template file and search for any manually entered references to your old domain name and replace it with the new one. Look for specific hand coded links you may have entered on the various template files such as thesidebar.php and footer.php.
WordPress uses a template tag called bloginfo() to automatically generate your site address from information entered in yourAdministration > Settings > General panel. The tag in your template files will not have to be modified.
You will need to update your WordPress configuration file if your database has moved or changed in certain ways.
At this point, your WordPress blog should be working.
If you make a mistake, you can Restoring Your Database From Backup from your backup and try this again. So make sure it is right the first time.
There are other things you may wish to change in order to correct URLs when moving sites.
How To: Move Your WordPress Blog to a New Domain - Using the Export/Import feature to move a blog to a new domain
When doing the above and changing the URLs directly in the database, you will come across instances of the URL being located in the "guid" column in the wp_posts tables.
It is critical that you do NOT change the contents of this field.
The term "GUID" stands for "Globally Unique Identifier". It is a field that is intended to hold an identifier for the post which a) is unique across the whole of space and time and b) never, ever changes. The GUID field is primarily used to create the WordPress feeds.
When a feed-reader is reading feeds, it uses the contents of the GUID field to know whether or not it has displayed a particular item before. It does this in one of various ways, but the most common method is simply to store a list of GUID's that it has already displayed and "marked as read" or similar.
Thus, changing the GUID will mean that many feedreaders will suddenly display your content in the user's reader again as if it was new content, possibly annoying your users.
In order for the GUID field to be "globally" unique, it is an accepted convention that the URL or some representation of the URL is used. Thus, if you own example.com, then you're the only one using example.com and thus it's unique to you and your site. This is why WordPress uses the permalink, or some form thereof, for the GUID.
However, the second part of that is that the GUID must never change. Even if you shift domains around, the post is still the same post, even in a new location. Feed readers being shifted to your new feeds when you change URLs should still know that they've read some of your posts before, and thus the GUID must remain unchanged.
Never, ever, change the contents of the GUID column, under any circumstances.
One exception is attachment media: Attachment media locations are stored as a URL in the GUID. If the default uploads folder needs to be changed to a different location, then the media URL will need to be changed in the post_content and guid columns of the posts table. For example, if the default uploads folder is changing from wp-content/uploads to images:
UPDATE wp_posts SET post_content = REPLACE(post_content,'www.domain.com/wp-content/uploads','www.domain.com/images');
UPDATE wp_posts SET guid = REPLACE(guid,'www.domain.com/wp-content/uploads','www.domain.com/images');
wp-cli is a super useful shell tool.
wp search-replace 'http://example.dev' 'http://example.com'
Or, if you only want to change the option, you can do:
wp option update home 'http://example.com' wp option update siteurl 'http://example.com'