Voting starts in March for the Drupal Association Board election.
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.
The concrete end-user features that are prioritized by this initiative are:
- Revision history for all content entities in core (phase A targeting 8.2)
- Moderation API (with MVP UI) (phase C targeting 8.3)
- Trash bin functionality (phase E targeting 8.3)
- Workspace API (no UI) (phase F targeting 8.4)
- Full-site preview with Workspace UI (phase G targeting 8.5)
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 below will likely be broken out to its own meta issue once the overall plan is clear.
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 where we start adding some new small/medium size features to the Entity API in core, primarily adding 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.
Phase C: Content Moderation module (with MVP UI)
Depends on: phase A.
This phase will introduce an experimental module for moderating publishing state on individual content entities. An MVP UI will be provided.
Phase D: Enable archive/purge storage
Depends on: phase A.
Some historic background: http://drupal4hu.com/node/233
Phase D will deprecate the traditional delete method in our Entity Storage API and introduce two new methods; archive and purge. This is primarily important for replication and conflict management (see phase H) but also enables things like Trash module (see phase D).
Phase E: Introduce Trash module
Phase E will leverage the new archive and purge methods and introduce an experimental module in core; the Trash module.
Phase F: Workspace API and entity indexes (no behaviour changes)
These phases will introduce the underlying Workspace API along with entity revision indexes to keep track of what entity revisions exist in what workspace etc. These phases will lay the foundation for full-site preview which will be introduced in phase I.
Phase G: Full-site preview with Workspace UI
Depends on: phase F
Super big phase. Lots of discussion needed here. This phase will use all previous APIs and implement full-site preview with a fully developed UI.
Initial wireframes here: https://marvelapp.com/dhb53d#11624482
Phase X: Cross site content staging
This phase would implement support for cross site content staging. See phase H 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 end-user feature)
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
Communication and planning
This section still needs work. More approvals will be needed, to be figured out.
Below are the major architectural changes that this plan is introducing to Drupal core.
Signoffs needed from release and framework managers
- Amending the BC policy to define how entity type definition changes should be handled
Signoffs needed from framework manager and Entity API subsystem maintainers
- Changing core to be Create Read Archive Purge instead of Create Read Update Delete
- Making revisions nonlinear by introducing one or many revision parents
- Workspaces as an architecture to encapsulate site content for full-site preview and staging
Signoffs needed from UX topic maintainers
- Workspaces as a concept for full-site preview and staging (existing contrib and mockups available for conceptual review)
Signoffs needed from contrib maintainers
All contrib modules featuring this functionality are maintained by this team.
The product, framework, and release managers have all signed off on this being an active core initiative. Each phase will undergo maintainer review individually on the respective sub-issues (above).