Voting starts in March for the Drupal Association Board election.
The Site Preview System was developed as part of the Content Staging Initiative which was funded by the Large Scale Drupal group. The Content Staging Initiative's goal was to create a contextually accurate preview of content prior to publishing. The SPS module is the framework that accomplishes this goal.
SPS interacts with content on a revision level. A set of conditions are used to determine which version of a piece of content is displayed. The decision is handled on a very low level, therefor the integration occurs on most aspects of Drupal (including nodes, views and queries).
Please review to Site Preview System Checklist for a better understanding of what is needed to implement SPS.
System Architect Components
Conditions are use for selecting which entity should be overridden, That info is then passed on to override controllers which store the data in meaningful ways. Finally the Reaction Use that data to change things in Drupal so the user may preview how overrides apply.
A Site State object defines a target that can be previewed. The Site State is how the system will know when it's in preview mode and what conditions should be applied. All other parts of the system interact with the Site State object. The Site State Object will be the storage container interface for the preview system. The Site State Object is unique per session. A user can only have one active Site State at a time but different users can use different Site States at the same time.
The condition plugin is used to collect, store condition information, and then use that information to query what overrides should be in effect. Widgets are associated to Conditions to provide the UI for the data collection. Overrides are associated to Conditions to provide a override list of content that is compatible with the Condition.
A Widget provides the user interface and interfaction for Conditions. The Widget is in charge of data collection and validation. A Widget can be associated to several Conditions.
Overrides produce a list stating which version of a piece of content should be loaded. A override list is generated by an Override given the data from a Condition. The Override is in charge of storage and retrieval of the override lists. The Reactions uses the Overrides to display the correct version of content.
A Reaction knows how to interface with the override data that was provided by the Conditions. The two primary Reactions will be a query alter and a entity load overrider.
These modules use the SPS Plugins API (http://drupalcode.org/project/sps.git/blob/refs/heads/7.x-1.x:/sps.plugins.api.php).
Modules that extend SPS functionality
Modules that Integrate with SPS
- State Machine
- Workbench Moderation
- Entity Revision Scheduling
- Context Field (The "context_per_revision" branch in GIT)
- Fieldable panels panes
- Any other modules that implements a revisionable entity.
Site Build Scenarios
This section will contain how-to documentation and videos for adding SPS functionality to Drupal sites.
- Revisionable Layouts with Context and State Machine.
- Previewing Block Changes with Bean (TO DO)
- Workflow assistance using State Machine (TO DO)
- Previewing Scheduled Changes using ERS (TO DO)
- Preview Menu Changes with Bean and Menu Field