The Workspace Preview System (WPS) gives site builders, editors, authors, and reviewers the ability to send collections of content through an editorial workflow and preview that content within the context of the current live site. WPS is a collection of contributed Drupal modules with additional configuration and UX improvements that all just works out of the box.
First and foremost, WPS has been marked as experimental. If you don't fully understand what that means, please head over to our Lightning Experimental Module notes before using the module.
We'll have lots more information in the coming weeks and months. For now, here is the high-level overview:
Workspaces are isolated copies of your Live site. By default, workspaces are empty, but the “Update” button (visible to privileged users in the Toolbar) automatically pulls all content from your Live site into new workspaces. The same button synchronizes changes from Live as content changes in both workspaces.
Privileged users can easily switch between workspaces from the same area of the Toolbar. Changes in one workspace never affect affect other workspaces until a privileged user either Pulls changes from or pushes changes to the upstream (usually Live) workspace.
Workspaces can be sent through editorial workflows. That means entire workspaces can be marked as “Needs Review”, “Needs Work, or “Ready to Publish - or any other custom state that business needs dictate.
States can additionally be flagged as Locked so that once a workspace has been moved into, for example, the Ready to Publish state, users can be confident that nothing on that workspace will change or has been changed since it was moved into that state.
Ultimately, workspaces can be published. Publishing a workspace pushes changes to Live.
In certain situation, users might not want all their Live site’s content replicated into a workspace. Perhaps they don’t want comments; or only Article nodes are needed. WPS provides a filter system that allows users to fine tune what gets pulled from Live into a workspace. Filters can also be used to limit what gets pushed back into Live upon publish.
Filters are also pluggable, so site builders can create new filters as dictated by specific business needs.
Chained Workspaces and Upstreams
Out of the box, Lightning ships with two workspaces: Live and Stage. Live is “special” in that is doesn’t have an upstream set (and Lightning prevents users from modifying this). And Stage ships with Live as it’s upstream. That means that when Stage is Updated (Pulls) it pulls from Live, and when Stage is published, it pushed to Live.
However, WPS does allow users to set a workspace’s upstream to something other than Live. For example, a user could create a Dev workspace and set that workspace’s upstream to Stage. In that case, when the Dev workspace is published, its changes would be pushed to Stage - not Live.
A more realistic scenario might be a workspace named “Fall Promotion” that includes landing pages and related articles. If a single change was needed right before Fall Promotion was set to be published, a user might create “Last Minute Change” and set that workspace’s upstream to Fall Promotion.
Out of the box, WPS does not support remote workspaces. But the underlying modules plus some other contributed projects do. And Lightning has taken steps to ensure that it doesn’t get in the way of extending functionality with other contrib modules.
By adding the Deploy module, advanced users can set workspace upstreams to remote instances of Drupal (and the opposite - local workspaces can be pushed to from downstream remotes).
Currently, conflict resolution is limited to the system identifying which entities are conflict and giving the user the option of cancelling the push if any are found. The user needs to manually resolve the conflict by purging the conflicting entity from one of the two workspaces.
Ultimately, there will be a UI and a pluggable system conflict resolution. This will all be handled by the Conflict module and will include several merge plugins out of the box.