If you are managing lots of WordPress installations for different clients, or any other content management system for that matter (eg. Joomla!, Drupal etc.), you need a way to deploy changes quickly and easily.
A problem or annoyance that I come across is when I need to move a development site from my local development environment to an online test area/server where clients can view their website in an online environment, which will operate very differently to just running the same set of files on your own computer which more than likely has a perfectly tuned settings so you can do just about everything.
A very basic tip is for moving your database from your local database to an online database. WordPress already makes this pretty easy and so you could quite easily get away with creating a fresh install each time but after a while even that becomes time consuming as then you need to set the same settings as you have on your local development site.
This becomes even more problematic, doing a manual/fresh install, when you use WordPress as a CMS more than just blogging software as sometimes you may build pages that retrieve information based on a specific post ID. With the ID’s being automatically assigned, you cannot always guarantee you’ll get the same ID’s even if you set up all the pages and all the content in the same order. In part, this is because of the WordPress auto-saving feature which will save a draft, taking up another ID. This will quickly lead to a mismatch in your preconfigured code which cites specific ID’s for specific pages and the actual ID’s that are assigned to the content you are creating.
The way I like to avoid this is by importing the whole MySQL WordPress database from my local development site into my online MySQL database where my live test site will be running.
The main problem with doing this is that all the URLs in the database will refer to ‘http://localhost/’ but now with the site being online, I need to change the base of the URL across all the content and especially in the settings of the website, otherwise the website will not work or the results may be unpredictable.
A quick way to rectify this is directly via the database using the SQL Update statement. While using phpMyAdmin is highly recommended for doing this it is equally possible to do this via the command line if you have the necessary know-how!
The three main SQL queries you’ll be needing are the following:
SQL Query 1: Updating your WordPress Posts Permalinks
1 | UPDATE wp_posts SET guid = REPLACE(guid, 'http://localhost/', 'http://mydemosite.com/') |
The above query will update all you post content for your WordPress install changing every occurrence of ‘http://localhost/’ in your post guid to ‘http://mydemosite.com/’. You may argue that if you are using WordPress as a straight CMS you won’t need to worry about this, which is partly true, but should you use it for both a CMS and to provide a blogging platform, your going to need to change the permalinks for all the posts across the entire site. After all if your using RSS you want people to be redirect to actual post and not some 404 page on some other website.
SQL Query 2: Updating your WordPress Options/Settings
1 | UPDATE wp_options SET option_value = REPLACE(option_value, 'http://localhost/', 'http://mydemosite.com/') |
This query is necessary for the main running of the website. It is where you main homepage URL is stored along with a few other important fields that help index your website correctly. If your sending indexing services the wrong URL it’s not going to help your chances of your website in the search engine stakes at all. There may be additional rows in this table if you have certain plugins installed.
SQL Query 3: Updating the installation path
1 | UPDATE wp_options SET option_value = REPLACE(option_value, 'C:\htdocs\mywebsite\news/wp-content/uploads', '/homepages/1/a123456789/htdocs/mywebsite/wp-content/uploads') |
If like myself you work on a Win32 platform but prefer to host your websites on a Linux server, you’ll definitely need to do this. If your development environment and your server are both Win32 platforms you’ll have to worry about this a little less if you’ve configured them identically, but more often than not, they won’t be identical.
This path is crucial for your WordPress cache and for uploading and storing content like images to accompany your posts as you need to get the absolute installation directory of the folder as it is on the server. This will be different between a Win32/Windows XP and a Linux or Mac environment.
While the basic principle is simple, effectively using the UPDATE SQL statement for updating whole tables, it will save you a lot of time if its something your likely to do on a regular basis.