Editor’s note: The following article is curated from the GoDaddy community. We’ve made some light edits for formatting and clarity. Looking for help with GoDaddy products or getting your business online? Join the community to get answers from other GoDaddy customers.
The Managed WordPress staging feature is used to develop and configure changes to an existing Managed WordPress website without modifying the production site. In particular staging environments are useful to evaluate new functionality without risking any negative effects to the production website.
Note that staging environments are available on the Deluxe, Ultimate, and Developer Managed WordPress plans. If you have a Starter plan, you will need to upgrade your account.
At NewPath Consulting we have a standard operating procedure (SOP) for deploying changes on Managed WordPress websites that are already in production.
Here are some tips learned from actual day to day use that may prove helpful when using staging to deploy changes to an already running production environment.
1. Pull your production site to the staging environment.
This creates an up-to-date snapshot staging site before any new changes is commenced. If you don’t have a staging site this will create the first instance with an exact copy of your production website under a temporary domain name. (Note: "overwrite content" checkbox will destroy any content or settings on your staging site.)
If you pull your production site into a staging site before each development cycle you can also get a copy of the current production website. That’s how we initially start making configuration/development changes, but after the initial pull into staging, you may want to do another pull ONLY if you don’t want to save anything on your staging site. You can make changes in the staging environment and push staging to production when finished, provided no production changes have been made!
2. Configure, develop and test your staging site.
You may wish to distribute only the staging temporary domain link (with the numbers in the domain) to ensure the latest staging version is being reviewed by your staff or your customers. All content, plugins and themes and user accounts will be synchronized with the production website. Even the passwords will be the same!
3. Import new content into the staging site.
In many production systems, at minimum, there are blog posts published during the development cycle, so the manual export/import to staging is required to sync new production content with new configuration/development changes performed on staging.
You must ensure that any new content published on the production site is exported and then imported into staging manually.
You can use the standard WordPress export feature of WordPress to migrate the media library, posts, pages and any other custom post types or content.
At NewPath Consulting we tend to use export each content type as the files generated using “All content” may be too large to import in one fell swoop on our staging system.
4. Push your staging site to production.
Once a set of improvements or features are ready on staging you will push your staging environment to production.
Note: The "overwrite content" checkbox will destroy any content or settings on your production site. This includes widget settings, menu options and configuration options well beyond posts and pages.
Production changes are inevitable, and the staging push to production process with "overwrite content" checked destroys the production system with a copy of the staging site, content and all. Any changes you made in production after the last pull to staging will be erased only recoverable with a backup restore.
5. Test the production site.
Once you have pushed staging to production, test the production system with the changes introduced from staging. If there are any settings that were set in production that have not been carried over to staging they will need to be reset on staging and pushed to production.
For example we check our wp_config.php file using an sftp client to make sure these 2 directives are set and uncommented into the production wp_config.php file:
You may wish to set these settings to ensure that all users on production cannot edit theme or plugin files. This is a security precaution as well. The file editor in WordPress can be a very dangerous thing in the wrong hands!
We also turn off DEBUG messages to ensure PHP/WordPress-generated errors are not shown to end users. On staging, both of these settings are enable to encourage proper debugging.
When should you push from staging to production?
The timing of a staging->production deployment should be done after the daily built in Managed WordPress backup has completed, usually around 4am Eastern. Our deployment window is 5-7am Sunday morning to ensure a full backup is available before a staging deployment occurs.
What if something is broken in production?
If production is damaged in anyway or partially completes, you must restore using the Files & Database option to switch back to the last site backup (from 4am of the current day). This will roll back the production site to the last known previous stable version, enabling another attempt at a deployment.
WordPress Hosting from GoDaddy is optimized for WordPress websites. Find out more about GoDaddy’s WordPress Hosting plans.
Already a WordPress Hosting customer? Sign in to work on your site.
