A couple of weeks ago a client decided to move her website and blog from Earthlink, and there was much rejoicing. Earthlink is a terrible place to have a WordPress install. You have to do manual upgrades.
The new host, GoDaddy (not my first choice for hosting, in all honesty, though I have some of my own sites there; their servers are slow as treacle), offers a service called Preview DNS so you can make sure everything works on your new site before actually transferring the domain. This is a handy thing to be able to do and a nice thing for them to offer.
There’s only one problem, as I learned to my detriment. If you install WordPress under Preview DNS, the database is going to be really confused and totally bork your blog when you transfer the domain, because WordPress will be looking for http://www.mydomain.com.previewdns.com when it should be looking for http://www.mydomain.com. This means it won’t call your stylesheet properly and you can’t log in. Eeek!
The nice young man I talked to at GoDaddy hadn’t seen the problem before either, but some of the the other tech support staff there had. In fact, they’d actually put together a help file explaining how to solve the problem of unintentionally changing your WordPress URL.
Fixing it involves editing the MySQL database where WordPress stores all its information. It’s been a long time since I’ve done anything with a MySQL database besides back it up or restore it, but if you follow the directions exactly, you’ll be okay.
First you have to log into PHP MyAdmin. If you’ve forgotten the username and password for this, don’t worry. They’re contained in your wp-config.php file, and you can get to that through FTP. (Or I could, because I set the FTP up with the numerical IP address, not the previewdns.com address.)
Once inside phpMyAdmin, you’ll see a bunch of stuff that doesn’t mean much to you (if you’re like me and stay out of SQL databases). What you need is in the upper left-hand corner.
Click the white button that says SQL (the other one is for the help file) and enter the following code into the box that pops up, replacing the URLs as appropriate.
UPDATE wp_options
SET option_value = 'http://www.newlocation.com'
WHERE option_value = 'http://www.oldlocation.com'
Hit the “GO” button and you should be all set, at least in terms of things like being able to log in, and WordPress finding the theme’s stylesheet.
As it happened, however, there were a few internal links to other posts and other references to the dread “previewdns.com” link. So I needed to figure out how to fix those. This time, it was Lorelle Van Fossen who came to my rescue, with her “Search and Replace in WordPress MySQL Database” article from 2005. With Lorelle’s help, I was able to replace those lingering links in the body of the posts.
Now that I know this, I’ll be less hesitant to venture into my WordPress databases again if I need to—but honestly, I prefer not to need to. I’m sure this isn’t the last site relocation I’ll ever work on, though, so I’ll probably encounter Preview DNS again.
Awesome! This, together with the Lorelle Van Fossen article saved me and my associates many hours of re-work changing the URLs of hundreds of images uploaded when our site was under GoDaddy’s preveiwdns system. GoDaddy should warn people about that!
Many thanks!
Brilliant! Thanks for putting this together in one easy to use place. I’m moving back to maddogdomains (godaddy reseller) after a very short stint on ipage. I personally never had the slow issues with godaddy that you did, but ipage….thats a different story.
I really appreciate the easy to follow instructions. This will hopefully save me some serious time!
I know this is a very old blog post, but I saw it and thought I might leave a comment anyway, in case anyone searching in the future ends up here.
Lorelle Van Fossen notes in that blog post:
“Again, I never do this without a backup, and even I have screwed this up, so if I can do it, I’m sure you will, too.”
One way her method can cause problems is if a serialized string is modified. My oversimplified explanation: Basically, there may be indicators in the database about how many characters some strings contain. So if you are ever migrating a site, let’s say for example, http://dev.mysite.com, the string “http://dev.mysite.com” contains 21 characters.
If you do a standard search and replace, but you replace “dev.mysite.com” with “mysite.com,” the string noted above will only 17 characters, but if that string is serialized anywhere in the database, then the database will still expect a 21 character string, which can make things act wonky.
Thankfully there is an awesome plugin that will do the search & replace for you and take care of any serialized strings. I’ve used it many, many times and it’s saved me a lot of aggravation.
You can find it here: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Good luck!