Content staging is the practice of publishing content to an intermediate instance (staging site) for review and test. Once the content is approved, it is published forward to production instances. Staging is useful when you need to publish large amounts of content such as a campaign that consists of many pages and assets. You can also use staging as workflow step when content needs to be user acceptance tested or reviewed for compliance.
Create a new staging instance between the author and public instance. Publish content first to this staging instance, then to production.
To create a staging instance:
Copy an existing public instance to create a new instance. See best practice below.
Rename the copied instance folder so that you can identify it as staging, for example
magnolia-activation-keypair.propertiesfile from the author instance to the staging instance and all other public instances. The keypair file contains the private and public activation keys. This ensures that the staging instance can publish content forward. The file is in
Configure your content staging instance as a public instance so that users cannot edit pages on it. The Pages app does not display the green edit bars on public instances. You typically don’t want reviewers to change content on the staging instance. While reviewers may need permission to log into the AdminCentral to review functionality such as new apps, they should not edit pages. The staging instance is intended for testing and approving only. If something is not correct, fix it on the author instance and publish again to staging for another test.
Log into the author instance
Configure the staging instance as a subscriber to the author.
Log into the staging instance. It’s a public instance but you can find AdminCentral at
Configure production instances as subscribers to the staging.
Normally public instances don’t have any subscribers but the staging instance is a special case. This instance will display the publishing status of content but the status is only synched with the public subscribers in front of it, not with the author behind it.
Handle unpublishing and deleting of content carefully. Make sure that you unpublish content from the public instances before unpublishing it from staging. Unpublishing does not ripple backwards in the chain automatically.
Content staging is not the same as code staging. In a code staging environment, developers test application code and verify deployment procedures. A code staging environment should mirror the production environment as closely as possible. This ensures that when the code is production ready it can be deployed to production without issues. This page is about creating a content staging instance for reviewing content.