How to Use Your Stage Site
What is a Stage Site?
All Drupal sites come with both a stage and a production (prod) version. Stage sites are a (mostly) discrete site that can be used for a variety of testing and staging purposes
You can visit the stage site by adding -stage to any Drupal site URL:
Remember - the Drupal team tests on stage too!
New features or updates are always rolled out to stage before they reach our production environments. Such updates or features are also tested before they reach stage environments, but by design, we occasionally catch issues that cause service degradation or outages on stage.
Stage Sites At A Glance
We'll provide detailed explanations and context in the accordions below, but here are the critical things you need to know about stage and production (prod) sites:
- Stage and prod are entirely separate sites, and content is never automatically copied between them.
- EXCEPT for the File Browser - anything file deleted there is gone from both sites!
- Generally speaking, most day-to-day updates should be done directly on prod using Draft mode.
- Stage is great for testing changes to content types that do not have a Draft mode like Menus and Widgets.
- Stage is also great for when you need to perform some kind of extensive overhaul or redesign on your site.
- Read below to learn how the Drupal team can help you with that!
Stage Sites Are Discrete (Mostly)
Stage and prod sites are almost entirely discrete sites, and there's no automatic syncing between the environments. This means if you add a new page or edit a page's content on stage, it does not automatically get pushed to production at any point.
The only exception to this rule is the File Browser. You can think of the File Browser like a network-attached storage drive (many campus users are familiar with the "V drive," for example) that is shared between both stage and prod. If you add or remove any images, documents, etc from your File Browser on stage or on prod, it will be added or removed from both sites!
Using Prod For Most Updates
Because there is no automatic syncing of content between stage and prod environments, any updates you want to transfer between the two must be transferred manually. This often means you'll simply be copying and pasting it. Generally, we recommend you copy the source code, as occasionally copying from the WYSIWYG view of the editor can cause problems.
For this reason, most day-to-day updates will happen directly on prod using draft mode. Draft mode - which is available for most of the primary content types - can be used to save your work in progress and to preview your updates before making them publicly visible by publishing them.
Good Uses For Stage
Stage is great for testing changes to parts of your site that do not have a Draft option, such as Blocks and Menus. If you want to try a few different ways of rearranging your site navigation, for example - stage is the perfect place to try that. It might also be used for developing new custom widgets.
Stage is also good for site overhauls or redesigns. If you're making major sweeping changes to your site, it can be a good idea to build the entire "new" site on stage! The Drupal team can even help you out with overhauls and redesigns by copying your database between environments.
Copying Site Database Between Environments
Usually, this means we'll copy your prod database back to stage to make sure your starting with up-to-date copies of your content (although we can skip this step if you're scrapping most of your current content anyway). This basically means that we'll make your stage site a copy of your prod site.
You can then rebuild your site on stage on your own timetable. Let us know when your done, and we'll copy the stage database back over to prod. This will make your prod site a copy of the new site you built on stage, effectively rolling out all your changes at once!
Please note it can take a few days to process a request to copy site databases between stage and prod. Additionally, you should not update your site until the process is complete (you won't break anything if you do, but if you make an update after we've made a copy of the database, your update won't make it to the target environment).