As WordPress users progress in their career, their site grows as well. When developing a professional website, that not only performs to specs, but is secure, a live development area is not always ideal. I’ve been asked several times to guide people through my development process. In this article, i will show you how to create a staging environment for your WordPress site.
Note: This article is more suitable for the users who want to move from beginner level WordPress development to a little more advance development. This article will help you from cow-boy coding and learn the best practice. This is what you are going to learn by the end of this article.
- Creating a Staging Site
- Using Git and BitBucket
- Pushing Changes From Local Server to BitBucket
- Deploying Changes from BitBucket to Staging Site
What is an Staging Environment?
To work on a WordPress site, we recommend our users to install WordPress locally on their Windows or Mac(I do need to say, if you develop on Mac, i feel sorry for you) computers. Once you are done and satisfied with your website, then you can upload it from localhost to live server.
There is one problem with this approach. What if something that worked on your localhost does not work on the live server? This would cause errors which can be a problem for established sites because it can affect search engine rankings, sales, first impression on users, etc.
Instead of uploading your changes to the live site, you can upload them to a staging site on the same server. A staging site is a separate development area on your site (usually a sub-domain) with restricted access. This is where you can test your changes or use it for all your development. Once you have thoroughly tested your site, you can then upload it to your live site.
If you’re a beginner and don’t want to learn the complicated process highlighted in the article below, then we recommend that you select a managed WordPress hosting provider like WPEngine which offers built-in staging functionality.
Setting up Staging Environment Using cPanel
First thing you need to do is to create a subdomain on your main domain. A subdomain will allow you to run your website in a separate folder, not affecting your main database, files, or uploads.
To do this, log into your cPanel (other control panel’s will be similar, look for Domains or Subdomains), Under the Domains sections, you need to click on Subdomains.
On the next screen, enter the name you’d like to use for your subdomain (typically staging or dev) and then choose your main domain from the drop down menu.
In cPanel, this should automatically fill in the Document Root text box with a location based on the name of your subdomain. You can change this if you’d like, but usually the default will be okay (public_html/staging).
Now you just need to click Create when you are done. It should confirm, and show the subdomain in the table below.
You can verify that your subdomain has been set up by visiting it in your web browser. It should display something similar to this:
Now you need to create a separate FTP account for your staging environment. A dedicated FTP account will only have access to your staging directory preventing accidental changes to your live environment.
In cPanel, navigate to the FTP Account section. Complete the fields in the Add FTP Account section.
The Directory should match the directory you specified when creating your subdomain. Click Create FTP Account to create your new account. This account will only have access to the directory you specified not the entire server.
Copying Data From Live Site to Staging Environment
Now that you have setup your subdomain, the next step is to copy the data from your live site to your staging site. This will allow you to test changes in your staging environment with the same data without affecting your live site.
The easiest way to do this is through phpMyAdmin. Log into phpMyAdmin via cPanel, and select your current live database. Once you have selected your live database, click on the Operations tab in the menu bar.
Here you need to look for the Copy Database To box. In the text box, enter the name of your staging database (if you haven’t created it yet, ensure CREATE DATABASE before copying is checked and give it a name such as example_staging). You need to copy both the structure and the data as well as making sure that you keep the remaining settings as default. Click Go to run the copy. Remember for larger databases this may take some time.
Once your database has copied, you need to select it from the sidebar on the left. phpMyAdmin will now open your newly copied database. You need to clicki on SQL tab in the menu bar of phpMyAdmin.
Now we will replace all references of our live site to the staging site to make sure that everything works fine when we use this database for staging. To do that you need to run the following SQL queries.
1 | UPDATE wp_options SET option_value = REPLACE (option_value, 'ORIGINAL_URL' , 'NEW_URL' ); |
2 | UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'ORIGINAL_URL' , 'NEW_URL' ); |
3 | UPDATE wp_posts SET guid = REPLACE (guid, 'ORIGINAL_URL' , 'NEW_URL' ); |
4 | UPDATE wp_posts SET post_content = REPLACE (post_content, 'ORIGINAL_URL' , 'NEW_URL' ); |
Enter the above queries into the SQL query box, replacing the following values:
- ORIGINAL_URL – your original site URL e.g. http://example.com . You can find this in your WordPress Admin under Settings > General > WordPress Address (URL)
- NEW_URL – enter your new URL, this will be the one of your staging site created earlier (be sure to include http:// – e.g. http://staging.example.com)
- wp_ – If your website has a custom prefix on database tables, make sure you replace wp_ with that.
Click Go to run the queries. A confirmation message will show when this is complete.
After copying your database, you need to copy your WordPress files, plugins, themes, and uploads. First download a fresh copy of WordPress from WordPress.org. Upload the contents of WordPress to your staging site. Note, do not run the WordPress install yet.
Once you have uploaded WordPress, the next thing you need to copy is media files, plugins, and themes. The following folders will need to be copied :
- /wp-content/uploads
- /wp-content/themes
- wp-content/plugins
If they are small, then you can download them from your live site via your FTP client and upload them into your staging folder. However for larger folders, this can often be time consuming. cPanel’s file manager allows you to copy folders directly on the server making the process much quicker.
Login into your cPanel dashboard and click on the File Manager under Files section.
cPanel will launch the file manager. You need to navigate to your live site’s wp-content
directory (typically /public_html/wp-content) where you would be able to see your themes, plugins, and uploads folders.
For each folder, you need to right-click and select Copy. This will bring up a dialog box, choose the location where you want the folder to be copied. We want to copy it to the directory we have created for the staging subdomain. It is also the directory where you uploaded WordPress in the previous step. /public_html/staging/wp-content/
This will copy each folder into your staging wp-content
directory.
You need to repeat this this for each of the above directories (plugins, themes, and uploads).
Note: In some WordPress hosting environments you may not be able to use a file manager in which case you will have to manually download these directories to your computer and then upload them back to staging site or use SSH.
Once you have copied these directories, you are ready to connect your staging installation of WordPress to the database you copied earlier.
Access your staging site, via the subdomain we previously created. If your staging directory doesn’t contain a wp-config.php
file, WordPress will attempt to create one asking for your database connection details. If it does have a wp-config.php file, ensure you edit it to use your new staging database connection details.
Once WordPress has connected to your staging database, it should detect that WordPress has been installed, and prompt you to login. Your login details will be the same as on your current live site.
Any changes you make to your staging environment will now be independent from your live environment. This means that you are free to change settings, install new plugins, edit theme files, and more without affecting the experience for your customers.
Configuring and Troubleshooting Your Staging Environment
Once you have logged in to your staging WordPress installation, there are a number of settings that should be configured before continuing.
Ensure Your Domain is Correct
Look at the URL of your admin screen. If it is your subdomain, then it has detected the new configuration. If not, then the SQL queries run earlier will not have changed your site URL within the staging database. Look for the siteurl and home option_name’s within the wp_options table.
Ensure Your Media has Copied
Visit the media section of your WordPress Administration and check whether your images/videos/etc. are in place. If so, then your uploads directory will have copied correctly. If not, then ensure that the uploads directory is in the correct place (typically /public_html/staging/wp-content/uploads).
Disable XML Sitemaps in WordPress SEO
If you are running WP SEO, then you need to make sure that XML Sitemaps option is disabled. This will help prevent search engines from indexing your staging environment.
Restricted Site Access
To prevent users from accidentally visiting your staging site, you need to install and activate, Restricted Site Access. Upon installation, go to Settings > Reading to configure the plugin.
You also want to go in the Settings » Reading section and make sure to disable indexing of this site by search engines. You want to make sure that you do this to prevent any duplicate content.
You can also password protect the entire directory with htpassword. The method shown in the tutorial is for /wp-admin/ but you can modify it for any site folder.
Update Permalinks
Visit Settings > Permalinks and click Save to ensure your permalink structure is up to date. If you are getting 404 errors on your staging site, then this is often the cause.
Pushing Changes to Staging From GitHub or BitBucket
Most professional developers like to use a version control system like SVN or Git to track their development progress. Using a version control system allows you to go back in time if something goes wrong because all your code history is stored in a central location. It also makes collaboration easier as all changes are stored on a central location, developers have the access to all the changes made to a project.
GitHub or BitBucket, Which One You Should Use
Both, GitHub and BitBucket are project hosting service and both allow you to use Git for your projects. GitHub is more popular among open source project developers and has a larger community of developers. If the project you are working on is an open source WordPress plugin or a theme, then you can host it on GitHub. Your project will be publicly visible and other users will be able to see your source code. To create a private repository on GitHub you would need to upgrade to their paid plan.
On the other hand, BitBucket allows you to create private repositories for free. If you are working on a client’s site or your own personal site, then you would probably want to keep your work private. BitBucket makes it easier for you to do so.
Getting Started With BitBucket
Step 1. Installing Git
First thing you need to do is download and install Git on Windows (or Mac).
Step 2. Creating Your First Repository
Now that you have installed Git, the next step is to signup for a free BitBucket account. Once you have signed up, you will enter BitBucket dashboard where you need to click on the Create new repository button.
Enter a name and description for your repository something that helps you identify your project. To make your repository private, you need to check the box next to Access Level. Lastly, make sure that Git is checked as your repository type. You can leave rest of the options unchanged and click on the create repository button to proceed. BitBucket will now create a blank repository for you.
Since you will be working on your local WordPress installation, click on I have an existing project to push up.
Step 3. Add local directory to Git
You are all set to push your local WordPress project to BitBucket. Launch Git Bash on your computer. Yes, it is a command line tool and you will have to type commands, but don’t worry it is super easy.
If you don’t want to use the command line, then you can use GUI interfaces like Github for Windows (which works for Bitbucket as well) and/or TortoiseGit.
First you need to add your local WordPress project folder as a repository in Git. Remember, you don’t need to add your entire WordPress directory to the project. If you are working on a theme, then you can just add that theme directory as a Git repository.
In Git Bash, first move to your project directory by typing the path to your project directory and then add it to Git:
1 | cd /C/xampp/htdocs/wordpress/wp-content/themes/myawesometheme |
2 | git init |
Now that you have added your project to Git, the next step is to add all files into it.
1 | git add . |
After adding all your files, the next step is to make your first commit.
1 | git commit -m "Adding all project files as the first commit" |
Step 4. Sync changes with your Bitbucket repository.
Now the final step is to Sync your local files with your BitBucket repository. Type in this line in Git Bash to connect your local repository to your BitBucket repository.
1 | git remote add origin https://[email protected]/bitbucketusername/repositoryname.git |
Push all your files to the BitBucket repository.
1 | git push -u origin --all # pushes up the repo and its refs for the first time |
Congratulations, you have successfully synced your local WordPress files with your BitBucket repository. Now lets make some changes to files in your local repository. Once you are done making changes, you need to commit those changes to Git.
1 | git add . |
2 | git commit -m "Added new features" |
3 | git push -u origin --all |
Deploying Changes From BitBucket to Staging Site
Now that you have learned how to use Git with BitBucket, it is time to deploy changes from your BitBucket repository to your staging site. This way you can work on your site locally and test your changes on your staging site without affecting your live site.
To do that, we recommend using Ftploy. The basic free account allows you to setup one project. It monitors changes made to your BitBucket repository and then deploys them to your web server. First you would need to sign up for an account on Ftploy. After that, you need to add your server details.
To configure a new server, select Servers » New Server from the navigation at the top.
Complete the appropriate fields with the settings you created when you configured your staging FTP account earlier.
Click Test Connection to ensure FTPloy can connect to your server, and then click Save Server.
To create a project, select Projects » New Project from the navigation menu, selecting GitHub or BitBucket where appropriate.
If you have previously defined your server, you can select it from the drop down menu (otherwise, enter the details in the appropriate fields). In the Server Path field, enter the path to your themes directory (this will change depending on the structure of your repo, but /wp-content/theme/your-theme will be suitable if your repo contains only your theme).
When you push a change to that BitBucket repository, FTPloy will pick up the changed files and push them to your selected server.
Pushing Changes to Live
If you are using FTPloy to deploy your changes from a repository to your staging server, you could set up a similar process for your live server. However, if incorrect or faulty code was pushed to your repository, that would go out to your live site automatically.
It is recommended to run an automated deployment system such as FTPloy for a staging server and then manually copy over the required files to your live site when you are happy with the changes and have thoroughly tested them on your new staging environment.
I hope this guide has helped someone, somewhere. Any suggestions or input, please leave a comment below! Feel free to share with friends.
- Reveal your Citrix XenServer password in XenCenter - October 8, 2019
- Facebook killed my dog (Day 6 of Facebook Deactivation) - June 22, 2019
- Let me tell you a story - June 20, 2019