Today we’ll be taking a look at one of the tools we use at iWeb. interconnect/it’s safe search and replace tool which updates hardcoded URLs in the WordPress database. This tool makes working with WordPress easier.
WordPress generates and stores absolute URLs in it’s database. This is the full webpage address including domain name. This makes it difficult to move a WordPress site and is something developers need to do quite often. For example, moving a website between a staging and production server.
This question always sparks a needlessly heated debate (okay, mostly among developers!).
Absolute URLs are generated by WordPress and stored in the database, which means moving a site/changing domain requires an additional step to update the old references. Not updating the old references would leave you with a sorry-looking site with missing stylesheets and broken links/images within the content.
So why doesn’t WordPress generate relative URLs? That’d solve all our problems! Not quite. WordPress content can be displayed in more than one place, from a listing page, one of the many archive pages (categories/tags/author and date archives) to feed readers. An image embedded with the relative URL
../../../wp-content/uploads/2014/02/image.jpg in a blog post at
example.com/2014/02/example-post/ will no longer reference the correct location when viewed at
example.com/tags/example/. Ahh… so just use a root relative URL like
/wp-content/uploads/2014/02/image.jpg. A clever solution. However, this reduces the portability of WordPress, say you want to move WordPress to a subdirectory, you’ve now got to update the old references anyway.
It’s difficult to understand why this sparks such emotion and I agree with Samuel Wood: “I can think of no sensible reason to care whether they’re absolute or relative, as long as the user sees the bloody page in the end”. It boils down to a developer’s personal preference and for the reasons above, WordPress has chosen to go with absolute URLs.
It’d be a time-consuming task to go through the database and replace each instance of an old URL. A simple find and replace would break serialised strings stored in the database. This is where the safe search and replace script comes in.
Originally written by David Coveney of interconnect/it (also known for his impressive hair and the marketing of Skittles to web developers). The safe search and replace tool ensures serialised data is preserved and provides a tidy interface to get the job done.
Robert O’Rourke demo’d a beta v3.0.0 at WordCamp London 2013, with just five minutes and a wonky wireless presenter, Robert’s lightning talk successfully showed off the overhauled UI and impressive new functionality including the ability to search and replace using regular expressions and a button to remove the script once done (with a nagging popup when trying to leave the page). For me though, the most impressive new feature is the ability to preview changes before they’re made.
Steps to move a WordPress site:
wp-config.phpfile to point to the new database
Using the dry run, you can ensure the search and replace is working as expected using the view changes link. Once you’re happy and you’ve hit the live run button, a countdown timer starts, giving you a few seconds to change your mind.Though at this stage you should be sure of what you’re doing!
After the search and replace tool has run, you can again compare the changes made and then delete the script to remove the security implications of having such a script lying around. We’ve found the tool invaluable and you should definitely check it out.