Often we want to edit our domain’s code, but on a production website, this can be dangerous. Making changes to the production site would not only allow all of the Internet to see unfinished changes but could also cause errors to display. As a workaround, we’ll create a testing domain or “dev” domain to work out any bugs and changes to the site.
As a warning, this is advanced technical work. It’s possible to make mistakes and cause downtime on your live domain. If you are not 100% confident, it may be a good idea to hire a system admin or developer to copy the domain for you.
- Be sure you are logged in as root user.
- I’ll be working from a Liquid Web Core Managed Ubuntu VPS server.
Step 1: After logging in as root, back up the domain using the command below to save a compressed version. It’s essential to have a copy of your site just in case you run into any issues. Replace the brackets and the “domainname” with your site’s name.
tar cfv backup.[domainname].tar /document/root/of/the/domain/
Step 2: We will be moving our backup file, .tar, somewhere off that document root, This way we can still access the data while keeping it safe.
mv backup.[domainname].tar /another/location/on/the/server
Step 3: The tar command created a file that comprises only half of the site, which holds the files. Next, you will want to copy the database for the primary site.
mysqldump [database_name] > /another/location/on/the/server/backup.[database_name].sql
Step 4: Create the new dev account, just like you were adding a new domain to your server. However, you will be creating a subdomain which you can name as dev.[domain].com.
Step 5: Once you’ve created the dev subdomain, copy the files from the main document root to the newly created dev document root. The document root is the location of the files housing your domain, also known as the “path”.
To find the document root location, for either domain, run the following command. Find the document root by replacing “exampledomain.com” for each both the live and dev domain.
conf=$(apache2ctl -S | grep exampledomain.com | perl -n -e '/\((\/.*)\:/ && print "$1\n"'); grep -i documentroot $conf
Step 6: After you have found the document roots for both the domain and dev domain, you will need to copy the files. With the output of the last command, you’ll insert the path for the document roots.
rsync -avh /document/root/of/the/domain/ /document/root/of/the/new/dev/domain
Step 7: Give the correct ownership to the dev domain, as the previous username remains in place. The ‘dev_username’ is a default user, one generated by creating the new account. The following command will change the ownership for you.
chown -R [dev_username]: /document/root/of/the/new/domain
Step 8: After you have done this you will need to create a new database and database user for the dev domain, be sure to keep all this information including the password you set. First, enter the mysql command prompt by running the command:
Next, create the database itself.
CREATE DATABASE [new_database_name];
In our next command, we create the user and their password. Be sure this is a unique username, unused up till now.
CREATE USER '[select_new_username]'@'localhost' IDENTIFIED BY '[password]';
Step 9: Grant privileges for the user on the database.
GRANT ALL PRIVILEGES ON [new_database_name] TO '[new_username]'@'localhost' WITH GRANT OPTION;
Then exit out of mysql by typing “quit” and hitting enter:
Step 10: Once back at the root command prompt, you can start copying the original database into the new database.
mysqldump [new_database_name] < /home/temp/backup.[database_name].sql
With the database dumped you will still need to edit the configuration files for your domain. Typically, there are files which need to access the database and will reference the database, database user, and password. These credentials need updating to the ones created earlier in step 8 of this tutorial. If you are unsure of where these files contact a developer. If you are working with a WordPress site continue on to the next section. Otherwise, if you have updated your dev configuration files with your new database info continue onto step 11.
Editing WordPress Configurations
Fortunately, WordPress is one of the most commonly used content management systems. WordPress is easy to configure we’ll provide a short tutorial on how to change the database and database user in the wp-config.php. First, move to the new document root.
There you will edit the wp-config.php with your favorite text editor such as vim or nano.
In the wp-config.php file, you will see a section that looks like the below. From there you will edit the highlighted characters with the information you used to create the database in the tutorial.
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
/** MySQL database username */
/** MySQL database password */
In the database, clear all mentions of the original domain and replace them with the dev domain. For example with WordPress, in the _options table you need to change two entries of ‘home’ and ‘siteurl’. These can be quickly changed using WP-ClI, which is a is a command line tool for interacting with and managing WordPress sites. To install WP-CLI follow these instructions and continue onto the next step.
If you do have a WordPress website, once you have installed WP-CLI you will want to run the following commands:
su - [dev_username]
wp option update siteurl https://dev.domain.com
wp option update home https://dev.domain.com
Sometimes plugins or themes mention the original domain in the database. If some parts of the dev domain are not working, particularly plugins or themes, you may need to contact a developer to see if the original domain name is still active in the database.
After replacing the names using WP-CLI, you’ll have officially created a dev domain.
Step 11: To complete this tutorial you have two choices: add an A record to your DNS to view your dev site online or edit your local hosts file to view solely on your computer. For our Liquid Web customers feel free to contact The Most Helpful Humans™ with questions you may have in setting up a development environment.