LCC eLearning
Archived / Completed

icon picker
Staging Sites


A site backup and retreival plan is an excellent tool to ensure site uptime, but it is only one part of a site stability plan. It is also important to have a testing site on the opposite side, where major changes and revisions can be implemented and tested before being launched to production. This ensure that any major changes such as new plugins, significant site revisions, or design changes do not break the primary structure or content of the site and everything remains usable on the customer-facing pages.


This project will develop and implement testing sites for both the and sites. These sites will be used to test:
New Plugin Installations
Site Content Reorganizations
Wordpress Theme Changes
Other significant site changes as necessary.
They may also potentially be used as a staging area to test updates to site pages and content, to improve ID workflow. This would allows Instructional Designers and other members of the elearning team to develop documentation and pages ahead of time in Wordpress, and then push the content out to production sites once the new feature has launched.

Research Questions

The majority of these answers came from a F2F meeting w/ Ariel on 11.9.21
How do we schedule content/changes from staging to production, and is that even best practice—or should they be kept separate and manually updated?
It is best practice to keep the databases completely separate. While there are technically plugins that allow scheduling from staging to production, staging is not typically used for testing/deployment of content, just large new site features like reorganizations, plugins, theme/layout, etc.
How do we get a copy of the current site/database on staging?
Ariel can help with this when we get to that point.
Benefits/downsides of having different cPanel accounts for staging/production?
Maintaining both sites as one cPanel account simplifies account management and the backup procedure. While it is technically possible to split them off, there isn’t a significant advantage to doing so.
Is there any value in backing up the staging environment separately from production?
Generally no. And because of how our sites are configured on the host and via cPanel, this wouldn’t be an option anyway.
What types of edits/changes should be made first in staging, vs. which are safe to just make in production immediately?
Content changes can largely be made in production unless they are to a specific area like a widget, or a page with more complex layout. Reorgs, theming, layout, plugins, etc., should be tested on stating first
Will staging/production require separate accounts for user access?
Yes. Each staging site functions exactly like another Wordpress instance
Is it best practice to do a local test environment first for -big- changes (like a theoretical site reorganization), then test those changes in staging, then move eventually to production?
It’s not essential, but it’s not a bad idea either. Typical workflows involve building/testing on a local instance, pushing to Staging, testing, then pushing to production. Dave’s Note: After checking with other developers/development teams, the proper setup is local dev, staging on server, push to production for significant changes.
Staging Site Tasks
Est. Effort
Completed On
Determine Current Site Structure
Determine Staging Process / Requirements
Setup Local Test Environment
Deploy Staging Sites
Logins / Credentials for ID Team
Document / Train eLearning on Staging Process
There are no rows in this table


Wordpress Local Testing Environment Software:
cPanel Configuration:
eLearning Sites Configuration as of 11/12/21
Public URL
SQL Database
Server Directory
Instructor - Production
Student - Production
Instructor Staging — Current
Student Staging — Current
Instructor - Staging (Out of Date)
Student - Staging (Out of Date)
There are no rows in this table


Instructor Test Site:
Student Test Site:

Test Site Locations / Credentials

The sites are protected by the plugin to prevent outside users from accidentally accessing the testing sites. This will allow us to test new features, layouts and themes without making them public, and still protecting the integrity of our production sites. The password to view the test sites is: NU_smod!hoof0jald. To access the WordPress Dashboard for the test sites, append /wp-admin/ to the end of the test site URL (i.e. You can use the same credentials to login to the dashboard as the production WordPress sites.

Content Update Process

In order to isolate and protect the production environment, there is no direct way to import created WordPress content from the test to production sites, or vice versa. This means we will continue to add and edit content, including: pages, posts, sliders, and eLearning Live events in the production environment. An initial exploration of this project was to determine if there was a way we could schedule updates from test to production—this ended up not being possible.

Theme / Organization Update Process

Continued WordPress development will first be done in a local development environment set up using . This is available for both Mac and PC if other members of the eLearning team would like to setup their own local environments, or if a future person comes into the role.
Initial development of new features will be done on this local test environment to work out as many bugs as possible in an environment that is completely removed from the Once the development has been tested, it will be moved to the test sites. Once it is live on the test sites, it can be tested in an environment that is closer to production and available for multiple people to test.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.