Setting up a development version of your site

Sometimes you want to test out some new template changes, new modules or plugins, or sometimes you just want to update your site, without affecting your current site now. This is what is known as a “development environment”, but we’ll call it a dev site for this article. There are several reasons to want to have a dev site setup for your website and various ways to accomplish this.

For the purposes of this post we’ll assume that you have a current website ‘www.domain.com’ in the standard cPanel public_html as you would if you were a shared hosting client or had a managed cPanel VPS or dedicated server. We will also assume that you’d like to make a dev copy of so that you can make some changes to the website without losing traffic, breaking your website, etc.

This is a great way to test out new software versions, new designs, new plugins or modules, etc. without breaking your actual live website.

STEP ONE. BACKUP YOUR CURRENT SITE.

Download the site with your favourite file transfer program, use cPanel’s backup function. It doesn’t matter HOW you do it. Just do it. Ensure you pull a database backup as well.

Next, we need to setup the development environment.

The premise is the same for any php based script, be it wordpress, drupal, joomla or something else – you need to setup a separate webroot (the place you put the website files) and a database for your dev site.

Now, in some cases it *MAY* be acceptable to run your dev site off your production/live site database – if you were simply editing some templates or something similar. However for proper separation, you should be using a separate database that you’ve imported a snapshot of the live database into. We’ll walk you through that shortly.

Different scripts will require special treatment. Refer to the scripts documentation regarding ‘server migration’ as the same concerns will apply to making your development copy. With the added possible action of denoting that the ‘hostname’ will be changing from www.domain.com to dev.domain.com as well.

Create the home dir

We will use cPanel’s ‘subdomains’ functionality to create the home directory. Nice and easy, simply login to cPanel, click the subdomain icon, enter your subdomain such as ‘dev.domain.com’ and set the home directory to something on its own. I personally like to make a subdirectory named ‘subdomains’ outside of the public_html directory to put any ‘subdomains’ into. So set it as:

—
/public_html/subdomains/dev.domain.com/
—

Create your database

Also within cPanel, create your database using the database wizard. You’ll need to make note of your dbname, username and password.

Copy over your files

Next you need to copy your files. You can either copy them directly, or use the files from the backup you just took. (You DID just take a backup right? If not you still have time, hurry go backup!)

To move your files you have many options. You can use the cPanel file manager, sftp, or the console. As admins, we have an almost irrational attraction to performing every task via command line and we realise that not everyone is as comfortable in that environment as we are. Luckily, using the cPanel file manager is really easy. Just login to cPanel and click the File Manager icon. Once it’s loaded up, go to the public_html on the left, select all the files on the right, and choose copy. Then in the destination box, type in:

—
/public_html/subdomains/dev.domain.com
—

*** Note: Use whatever you typed for the homedir during the subdomain creation part above.

DONE!

It doesn’t matter how you copy the files as long as when you go to that new directory, your files are there.

Export & Import the DB

Now you just need to export/import the db.

If you do not use Wordpess, we can stay in cPanel to accomplish this task. You can use the phpMyAdmin option to copy the database to the dev one very quickly. Click the phpmyadmin icon, select the live database from the menu tree on the left, then find the tab on the top right labeled ‘operations. Locate the box labelled ‘Copy database to:’ and fill in the destination with the new database name (which should also be listed in the tree on the left at this point). Since the DB already exists, you need to UNCHECK the ‘create database’ or it will give an error accordingly. On future copies if you were wanting to ‘refresh’ the data in dev with live, you’d want to CHECK the ‘add drop table’ option, so that it cleared out the current table contents before copying new data in. Click go, and it will put up a notice that it’s working, and will bring up notice when it’s completed the copy.

Now for WordPress, the above works about 0% of the time. Since WordPress stores its hostname INSIDE the database and REQUIRES the hostname to be CORRECT, you need to modify these values inside the database. Now you can do this by hand, but it’s tricky; especially in the ‘settings’ table where the settings are stored in a serialized format that a standard search and replace will break. The best option we’ve found is a WordPress plugin named ‘wp-migrate-db’. Install the plugin in your live copy of WordPress and use it to export the db. Be sure to update the ‘to’ side so that it has the new hostname and file path. This is usually all that’s required before you can select go. It will generate an ‘sql’ file and place it in your downloads folder. You then go to phpMyAdmin via cPanel, select your new dev database from the menu tree on the left, go to the ‘import’ tab, select your sql file in the downloads folder of your live site and select import.

At this point you need to access your configuration file, and update the config with your new database information. Once that’s done, you should be able to access your new ‘dev’ site.

If not, then there may be some other issues with the domain that need to be set. The same things that need to be done when moving a site. Check for hard coded hostnames, paths, etc. Often these issues are well documented in your scripts migration documentation. A quick browse through the docs can typically resolve these issues quickly.

Time to get to work!

You should now have a working copy of your website sitting in a development environment. This will allow you to make all the changes you wish without affecting your live website, so get to work!

*** Note: If you plan to leave your dev environment up for more than a few hours, there is a chance that a search engine may find it and index it. This can cause issues with ranking, duplicate content penalties and so on. Simply password protect the dev site via cPanel if you plan to leave it online long term.

Pushing your changes from dev to live

Once you are done with making your changes, moving the dev to live is as easy as repeating the process, just in reverse. Ensuring you have backups!

Clean up after yourself!

When you are DONE with the dev site. DELETE IT. Do not leave ‘dev’ copies of software sitting on the server. Old and forgotten software is a hackers delight. No one likes being hacked, so take a few extra seconds and delete your dev environment when you are finished.