Publish or Preview

Most of the larger organizations which use content management system for publishing the content have been accustomed to a preview server.

This setup when done correctly, helps them in reviewing the content before it gets published to the larger internal audience or in most cases the internet for public consumption.

Further analyzing this requirement, we can safely assume that the  real requirement is to enable the business ,  review the content either through a change management process or through a workflow before it is published.

This requirement is very common in regulated industries like health care and finance, and  can be implemented in multiple ways using Adobe Experience Manager.

Four common approaches used to implement are explained below.

Preview with WCM disabled

AEM has the feature to preview the content before it is published. This is achieved by toggling the cookie value javascript:document.cookie=“wcmmode=preview”. The same experience can be extended across the pages by persisting the cookie and allowing the author to toggle the values as a custom option.

This feature can be enabled only on the authoring side by embedding the logic in the client libraries executed only on the author.

 Pros

  • Previewing content is possible for all the pages in the content journey and not just for the page being curated.
  • Preview content leverages the latest content.

Cons

  • It still requires login to preview the content.

 

Apache Server Redirect

This approach leverages the apache to rewrite the URL by adding the request parameter wcmmode=disabled.

Pros

  • Does not require any authoring specific client libraries
  • Easy to manage since it requires minimal change at the webserver layer
  • Scalable and extensible solution

Cons

  • Additional webserver management

Preview Publish Server

publish-preview-server.png

 

This approach would add an additional publish instance which would get the content before it is approved and pushed to the actual publish instance.

 

In this approach, the replication agent needs to be setup with the preview publish instance. The replication agent needs to be setup with the user that has permission to the content that is being published.

AEM_Replication_preview_Agent

OOTB, when content is published, the page has a status indicator for the last replicated action, red/orange/green. This could potentially cause confusion for the author when the preview system is leveraged.

One way to avoid this confusion could be  by disabling the no status update and no versioning flag. So, the green/orange and red status would always indicate the actual publish and not the preview publish.

Pros

  • Single source of content resides only in PROD author.
  • This approach would allow the business user to preview the content just like the end user, since the content delivery channel is the same (author-publish-dispatcher)

 

Cons

  • Custom coding required to push content to the preview delivery system. (custom replication actions)
  • Deactivating content could cause the system to behave erratically since the author is shared for both the preview and the live publish instances.
  • Concurrent content authoring similar to launches is still not supported due to content sharing between preview and actual publish instances.
  • Acts as a single point of failure when issue is identified at the production content or at the preview content level.
  • If workflows are involved, then the content footprint increases due to datastore growth.

 

Dedicated Staging/Preview server

This approach involves the actual cloning of the production environment. In this approach, the content goes through multi level validation before it is actually published for public consumption.

The second level verification in the Production could be made optional as well.

Dedicated-preview-server

 Pros

  • Content validation and content verification can be done without interference from the “in-flux” production content
  • Content updates, which require content structure, can be validated and verified without affecting the production content.
  • Approved content (business stakeholder’s validation) from staging can be promoted to the PROD
  • Content can be down streamed from PROD using multiple techniques ( Packages, Replication, RECAP refer section RECAP (VLT-Sync) ).
  • Provides a seamless user experience validation and verification for the business stakeholders.
  • Ideal to fine-tune the optimization required before deploying/debugging in the final Production environment.
  • The preview URL can be shared with anyone in the organization, since it reflects the content delivery setup of production system.

 Cons

  • Additional maintenance of a Staging environment
  • Content redundancy since production content can be down streamed.

 

Depending on the requirment , one or a combination of the listed solutions can be implemented to achieve the desired result.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s