When building a WordPress dev site, there are a few things you need to know in order to make your life as a developer a little less painful. In this article, I’m going to uncover some of the secrets of making this a success for your next client. Whether you’re a freelancer, or an in-house web designer, setting up a dev site for your client/company is a must!  Don’t kid yourself, playing with a live website is going to fail every time. Even if you’re only updating your theme or plugins.

Why Do You Need A Dev Site?

The dev site is your playground, and WordPress has some quirks that you won’t find easy to deal with if you’re going to be running a top ranked website. Understand that any company, big or small, that has a first page ranking on Google, is running a dev site. Let me define what a dev site is within the WordPress framework:

Definition: The WordPress dev site is a duplicate of the live production site for making regular updates and improvements to the live site.

The true perspective of your live site is, the live site is a duplicate of your WordPress dev site. In other words, you don’t write new posts to your live site, you write them to your dev site, then copy your entire WordPress dev database over to the live production database.

The dev site is also where you perform WordPress updates to themes and plugins, as well as customizations to improve functionality and performance.

If your team is good, they’ll have all of these functions automated through bash scripts and cron jobs. All you do is build your site in the dev environment, and update your live site on a scheduled interval.

How Does It Work?

Protecting your live site is key to great success on the web, and once the dev framework is setup, then making daily updates and improvements to your site becomes routine and very safe.  The steps involved go like this:

  1. Backup the live site database and web folder containing all your WordPress files
  2. Copy all backup files to dev server
  3. Update dev site database with live site database
  4. Put live site into a temporary maintenance mode (you see this all the time on big sites)
  5. Be sure the dev site uses the same domain URL structure as the live site (Very important!)
  6. Change live site domain URL to dev site URL (See our bash script on doing this instantly)
  7. Make your updates/improvements
  8. Copy the dev site database and WordPress files back to live production server. Be sure the database is new and does not overwrite the old live site.
  9. Update dev site URL domain back to live site URL
  10. Update WordPress wp-config.php with new database name you created in step 8 above
  11. Take your new site live once again

Problems You “Will” Encounter

 Ever heard of “serialized data”? If your new to the world of WordPress dev, then you need to know that databases use serialized data to maintain the structure and format of the data it holds. This is true for other systems as well, such as networking, but in this case, serialized data is in all databases. If you want to see more about it, Wikipedia has a post.

So what’s the best way to tackle this issue. The answer is quite simple, use a dev site domain name with the same number of characters. For example, our website is: https://codemilitant.com, and the dev site is: https://codemilitant.tbd

Notice that each of our URLs has 24 characters in it. This is the serialized data structure you want for both your dev and live websites. If your dev site is something like: https://codemilitant.local, now you have 2 additional characters, and you’re going to break your WordPress website with mismatched serialized data. That means all your headers will disappear, and your nav menus may become unformatted. You will also see footer elements, and images simply vanish. This will be a nightmare for you every time you want to make improvements on the dev site, and every time you migrate from dev to live. If the URL characters match, you will not have an issue.

ALWAYS BE SURE YOUR DEV DOMAIN URL CHARACTER COUNT IS A MATCH TO YOUR LIVE DOMAIN URL CHARACTERS

TLS (SSL) Dev Certificate

Because of the serialized data in the database, you want to be sure you’re running your dev site with a self-signed TLS, or as many mistakenly call it, SSL.  In WordPress, you will need to update your child theme functions file to make sure you have the following code to allow WordPress to function correctly.

//THIS FEATURE IS ONLY FOR THE DEV SITE – DO NOT VERIFY TLS CERTS
add_action(‘http_api_curl’, function( $handle ){
curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($handle, CURLOPT_SSL_VERIFYHOST, false);
}, 10);

Why must this be done?  Because WordPress uses curl in the background to fetch images, and curl will fail on any dev site if you try to verify the TLS cert when making the transfer. When you move all your upgrades to your live site, be sure this snippet of code is not included in your functions.php file.

Conclusion

With the right bash scripts to update your database, you can achieve a harmony between your dev sites, and your live sites, that will make your sites safe and secure for years to come. If you don’t have the bash scripts to make these transitions easy, then take a look at our bash scripts to help you be a superhero administrator.

Semper Fi

Tom Heibel
Founder Code Militant