Giới thiệu the Content Preview System (CPS) trong Drupal

The Problem

Drupal traditionally excels in the area of content organization – not only as a content management system, but also in allowing you to create structured data, thanks to the entity and field systems.

>> Giới thiệu Nginx Load Balancer Visualization trên Raspberry Pi Cluster

However, while flexibility in Drupal 7 has grown – compared to Drupal 6 – the preview and revisioning systems have been very limited (and still are in Drupal 8, as of now). The only possibility in Drupal 7 was to click “preview” and see a very rough outline of how the content might look styled with the admin theme.

Trying to use the same CSS and/or JS in the admin and default themes is a difficult endeavor. Solutions include AJAX callbacks and iframes, but those solutions are neither optimal nor in widespread use.

The Drupal 7 core revisioning system is also limited and mainly allows auditing and reverting back to another revision; any saved revision is immediately live and overwrites the state of the old revision. Therefore, it is impossible to have different stages of the same piece of content once it has been published.

CPS

The workflow needed by most larger content teams is that each article can be a “draft” stage, then revised by an editor and, finally, approved by a content publisher.

While the workflow provided by the Workbench module is already quite good at this, it still lacks something that even bigger teams need: The possibility to publish content together as a “pack.”

One example of this is a large marketing campaign that has several articles which, taken together, form the new front page and show several subpages. In order to properly review these changes, editors and content publishers need to be able to see the set of changes on the site as a whole. CPS fills this gap, because it allows you to view the whole site as if the content was already published – but your live site remains unchanged!

How Does it Work?

CPS divides your site into changesets, called ‘site versions’ in the UI.

Every editor has their own ‘site version’ (though collaboration and moving of drafts between changesets is possible) and can see the site overlayed with all the changes they have made.

A ‘site version’ tracks all the entities that have changed over time, together with the ‘draft’ revision that was last saved within the ‘site version’.

[ IMAGE: "CPS diagram for entities and revisions.pdf" Caption: "In the "Sandbox" site version, Revision 2 is shown for Entity 1, while Revision 1 is shown for the live version. Entity 2 and Rev 4 do not yet exist on the live site.". ]

Whenever Drupal is asked to load an entity or create a list via Entity Field Query or Views, CPS checks which site version is active and replaces the entities retrieved with the correct revision that applies to this site version.

Under the hood, CPS uses the Entity Status and Drafty modules to allow creation of non-published revisions by creating the new revision – via the core mechanism – then immediately reverting to the old “live” revision.

Example Workflow

CPS includes the cps_workflow_simple submodule, which allows you to set up a simple editorial workflow, and create personalities who will receive e-mails at each stage of the workflow. Due to a rich hook system, CPS can easily be extended for more complex workflows.

CPS starts with an initial site version which contains all the content first published when CPS was installed.

To integrate CPS with your site, download the CPS module, enable cps, cps_node and cps_workflow_simple, and all associated modules asked for by CPS, like entity_status, drafty, iib, and diff. You will now see a Site version bar at the top of your site. Click on the plus sign (“+”) to create a new site version – your very own “playground.”

Please note that once CPS is active, entities under CPS control can no longer be added or edited when not within a site version.

Revision Chart

Step 1: Create a New Site Version

Create and edit some entities. Notice how when you use the ‘site version’ switcher widget at the top, you can view your site with and without your changes.

Step 2: Review Changes

Next, click on the gear to the right of the site version switcher widget.

On this screen you will see a diff of all changes that have been made in this site version. You can review all the changes and then send the ‘site version’ with a message to the editor, or approve and publish it directly.

Congratulations! You have made changes, but they are not visible on the live site, only on the internally visible site version.

Step 3: Publish the Site Version

When you are ready, click the Publish button, confirm, and after a few seconds, your site version will be published.

All your changes are now visible to everyone and you have completed the editorial workflow.

Known Limitations

There are some caveats: Only entities that are revisionable can be used together with CPS.

For example, to use Menus with CPS, you need to create a menu_link content type and use Views to populate the menus. Similarly, you would need to use a simple custom entity type to replace taxonomies, enable file_entity_revisions for media module, and so on.

Contribute

CPS is already being used in production, although it’s still under heavy development. But testing it can give you an idea of what a powerful editorial workflow it provides for Drupal, even now.

Care should be taken to combine this module with the Field Collection module. While CPS is now based on Drafty – which takes care of all the low-level revisioning parts – this is still an area where both Workbench and CPS had major bugs in the past: proceed with caution.

Other open areas for contribution and testing are the Title and Entity Translation modules.

Please file any bugs you find in the issue queue and help us move on down the road to a stable release.