Applies to:
WordPress Hosting
Introduction
Staging is a feature of the WordPress hosting platform that allows you to create a duplicate of your site from within the client control panel, called a staging site. You can use this staging site for development and testing changes to your site before transferring files and database back to the live site through the staging control system.
Staging sites do not count towards the total number of sites within your container, but do have some limitations and are not designed to be used in production.
WordPress Hosting Staging Sites
Structure
Staging sites always are created as a sub domain of the existing site with the following format:
staging.yourdomain
Staging sites are complete duplicates of the site at the time of creation. The only difference is that all URLs are updated to the staging address. All files in wp-content are duplicated except for my-config.php, and the database is the cloned. All user logins remain the same.
Please Note: You can login to the admin area, either using the wp-login page or via the staging tab in the 34SP.com client control panel
Accessing files and Database
Just like your normal site, you can add plugins and themes through the WordPress admin area of your staging site. You can also access the staging site via SFTP with the same details you would use to access your normal site.
To access the staging site you will need to go up one level from the directory that you first login to and then change into the staging site directory.
For example, if the directory for your normal site is:
/var/www/vhosts/example.com
Then the directory for your staging site will be:
/var/www/vhosts/staging.example.com
Staging sites have their own log files, available at:
/var/www/staging.example.com/statistics/logs/
Staging sites database can be accessed via PHPMyAdmin tool within the staging site tab inside the 34SP.com client control panel
Creating a staging site
You can create a staging site by going to the 34SP.com client control panel, selecting the WordPress hosting site you wish to add a staging site to and then selecting the staging tab.
If a staging site has not been created, an option to create a site is available. Once clicked, your staging site will be ready in a couple of minutes.
Accessing your site
If your nameservers are with 34SP.com we will automatically add www.staging and staging records to your DNS settings. If you manage your nameservers elsewhere you will need to add these records yourself to include an A record with the IP address of your container.
Pushing and pulling
Once a staging site has been created, content and database files can be pushed and pulled between the staging and normal sites. When content is moved from the live site to staging it is referred to as being pulled, while moving content from staging to the normal site is referred to as pushed.
Once a staging site is created the staging tab interface changes to allow pushing and pulling.
Buttons on the left of the page pull content from the live site to staging, while buttons on the right push content from staging to the live site.
The database and your files are treated as separate items so to push or pull an entire site, you will need to push or pull both the database and files.
Pushing or pulling the database will copy the database over, changing relevant paths and URLs within the database to ensure your site’s functionality. After pressing copy database you should not need to update any paths either pushing or pulling.
Files are moved from the wp-content folder and include plugins, themes and uploads.
When you press a button to push or pull content, the action occurs immediately and your browser will wait until the process completed before refreshing the page. Please be patient as this can make the page appear to have stopped responding while the process occurs and on large sites it may take some time.
Rollback live
Once either files or the database have been pushed to live a “rollback” button will appear, allowing you to revert changes to the time of the deployment.
Rollback reverts either file changes, or database replaces with a copy of either the files or databases at the time of the deployment. It will wipe all changes.
While a rollback cannot be undone, the staging site remains unchanged, so the changes can be pushed assuming changes were not made to staging in the mean time.
You cannot rollback a version of staging, rollback is only available when pushing staging to live.
Deleting a staging site
You can delete a staging site by going to the 34SP.com client control panel, selecting the WordPress hosting site you wish to remove the staging site from and then selecting the staging tab.
The delete option is available from the settings button within the staging tab, if a site has been created.
Differences between live and staging
Your staging site is as close as possible to your live site, but there are a few noticeable differences:
- No Fast-CGI cache
- No mod_pagespeed
- Single PHP worker
This means that your staging site will have noticeably lower performance than a normal site, but also means you can make changes and immediately see their effects without worrying about things being cached.
Preventing search engines crawling your staging site
To prevent your staging site content being crawled and indexed which might cause issues with search engines like Google, the staging site adds additional header, that tell search engines not to crawl the site or cache/archive its contents. These headers are not copied over to your live site when changes are pushed, but means that it’s safe to develop the site in the knowledge that Google and other search engines will not index the staging version.
Disk quotas and resources
Staging sites are for development only. They always have caching switched off and have far lower resources than your normal sites, which means they will be slower. They are not designed to be accessed by lots of visitors and will not stand up to load testing software.
Staging sites don’t contribute to the number of sites in your container, however they do take up resources and disk space. Pushing and pulling files for very large sites might take up a lot of disk space.
Containers with 3 high trafficked sites and 3 staging sites will struggle and may have connectivity issues. In such cases we recommend either removing staging sites or increasing the resources within the container through an upgrade.