Drupal 8 has so far seen many major improvements to our code (OOP, Symfony, etc) and our configuration (Config Management Initiative etc). But what about the third pillar — content? The Entity API team have done some amazing work on making our content APIs a lot more solid. But this work has not yet brought any new features for actually managing content, such as workflows, preview and staging. We propose an initiative with goals to improve in this area by including functionality in core based on what contrib modules have done for many years.
A big focus for this initiative will be to get the necessary sign-offs ahead of time in order to make it possible (and sustainable) to work toward the big end goals of this initiative. You can read about the specific sign-offs in each separate phase issue.
For some additional background, see Dries’ blog post: http://buytaert.net/improving-drupal-content-workflow
Bring major improvements to Drupal’s content workflow, preview and staging capabilities. It will be done by primarily extending and improving aspects of the Entity API in core.
Much of the functionality that will be implemented will take heavy inspiration from modules that already are being battle tested in contrib, such as Entity, Multiversion, Workspace, Deploy and Workbench Moderation.
Process and where to find it
Each phase in the roadmap is designed to be as simple and contained as possible to allow it to be committed/merged into core without dependency on the next phase. All issues should be tagged with Workflow Initiative.
- Kanban board: https://contribkanban.com/sprint/WorkflowInitiative
- Core conversation in New Orleans: https://www.youtube.com/watch?v=_rAB8DJnc8Y
Each phase are broken out to its own planning issue. Phases aren't necessarily fully sequential. Some things can and will be done in parallell.
Phase A: Use the revision API in more places
The idea of phase A is it to implement and use our great revision API for all content entities in core, except users. This will provide a necessary foundation for any moderation, workflow and staging capability. No new features or functionality is being added to the Entity API in this phase.
Phase B: Extend the revision API with support for parents
Phase B is adding support for tracking parent revisions (for nonlinear revisions). Tracking where revisions come from is important in order to be able to solve conflicts between revisions made in different environments. This phase only required in order to make progress with Phase H.
Phase C: Content Moderation module
This phase will introduce an experimental module for moderating publishing state on individual content entities. Plan issues:
Phase D: Enable archive/purge storage
This phase is no longer needed because of the implementation decision made for Phase E.
Phase E: Introduce Trash module
Phase E will leverage the new workflow module and implement Trash as a new status. Some historic background: http://drupal4hu.com/node/233
Phase F: Workspace API and entity indexes
Due to the way it's been decided to handle experimental modules in core, everything for Workspaces will be implemented as one experimental module in the next phase G.
Phase G: Introduce Workspace module
This phase is split into two sub-phases. The primary purpuse here is to introduce the ability to preview and stage changes, within multiple "workspaces" on a single site.
- Experimental workspace module with MVP UI:
- Full UI implementation:
Phase H: Workspace conflict management
This phase will extend the Workspace module to provide conflict management for content changes in separate workspaces.
Phase X: Cross site content staging
This phase would implement support for cross site content staging. See phase G where single site content staging is implemented.
Implement CouchDB compatible REST endpoints to support cross site content replication. See Relaxed Web Services module for the current contrib implementation.
Phase XI: Autosave
Big phase. This will be a separate module. Lots of details still to be figured out, below are some ideas:
- This would be the first feature that starts utilizing concepts of storing content offline in the browser’s
localStorage. Some background:
- Revisions could be auto-saved to
localStorageand continuously replicated to backend. Changes would then be auto-saved even if the Internet connection is down. Rely on PouchDB and HTTP APIs from phase X
- Auto-saved revisions could be marked as such and later be purged. Rely on APIs from phase C (deleted flag, revision purging).
- Auto-save might be implemented together with concurrent editing. Rely on APIs from phase G (conflict management).
Related contrib projects:
Not in scope
Although content migrations (between Drupal versions) will not be in scope, having the replication API available from phase G, step 2 could still help this effort significantly.
Much of the above functionality currently sits in a number of contributed modules outlined at: http://www.drupaldeploy.org
Team and resources
As with any major work in core, the work will be carried out by the community openly in the issue queue and anyone is welcome and encouraged to take part of the process. In addition, there will be a few people that are going to be working on this as part of their day-to-day job as well, funded by a few independent sources:
UX and frontend
Each individual plan issue will list the required sign-offs.