Session: https://events.drupal.org/losangeles2015/sessions/we-need-revisions-and-crap-everywhere-core
Demo video: http://youtu.be/Wijjsh6_Aq8
Let's face it, content staging will never make it into core, there isn't one way to do it for everyone. But the lowest common denominators for any content staging, replication or syndication solution are revisions and CRAP - Create Read Archive Purge!
Drupal 8 have already brought us a really solid Entity API with good revision support. The Multiversion module takes this even further in contrib.
In this session some compelling arguments will be laid out for why we need revisions and a Create Read Archive Purge storage for all content entities in core! We weren't wrong when we identified this back in 2011 as the future of Drupal, we just need to do it!
A concrete and actionable plan for how we can implement this will also be introduced.
We need revisions and CRAP everywhere in Drupal core
1.
2. C O R E C O N V E R S A T I O N S
REVISIONS EVERYWHERE
@ D I C K O L S S O N – D I X O N _
3. ★ What’s the problem?
★ How other systems solve the problem
★ A bit of Drupal history
★ What can we do?
★ Demo
★ Discussion
AGENDA
4. ★ Discuss improvements to Entity API
★ Discuss inclusion in core
★ Feedback, thoughts and questions
during this session
GOALS
5. Long time contributor to core
and contrib.
Working for a pharma
company, making Drupal work
for hundreds of sites (and
thousands of environments).
ABOUT ME
Me smiling
Dick Olsson – @dickolsson
10. …and yet, we don’t care about our users’ data
DRUPAL IS A CMS
Not possible to undo a delete
Content is blindly overwritten when updated
Concurrent editing is not supported
Entity Revision API in D8 is good,
but not enabled by default anywhere
11. Local development
Editorial content staging
Editing in production
User generated content
Integrated systems
API clients
…and yet, we haven’t realized our content is too
DRUPAL IS DISTRIBUTED
12. Be careful about our users’ data
Concurrent editing
Content workflow
Content staging
Conflict handling
…which are difficult/impossible at the moment
USE CASES
13. Manage content and workflow
Move and share content
Compliance and audit
Letting our users trust Drupal,
knowing that the system care about your content
RELAX! :-)
…for our end-users
WHAT REALLY MATTERS
17. Assumes its content is distributed
Every change is a new revision (even delete)
Every revision has a universally unique hash
Every revision has a universally identifiable parent
GIT
...a great distributed version control system
20. Assumes its content is distributed
Every change is a new revision (even delete)
Every revision has a universally unique hash
Every revision has a universally identifiable parent
Defines a reusable HTTP replication protocol
APACHE COUCHDB
...a true multi-master database
22. ★ Notes from early Drupal 8 BoF:
https://groups.drupal.org/node/133579
★ Feature in Watchdog:
https://drupalwatchdog.com/node/502
★ “I just want to edit a node”:
http://denver2012.drupal.org/content/i-just-
want-edit-node
★ “Content Staging in Core”:
http://denver2012.drupal.org/content/content
-staging-core
PAST DISCUSSIONS
24. “IN DRUPAL 8 […] THERE ARE TWO COMPETING APPROACHES:
CRUD AND CRAP (CREATE, READ, ARCHIVE, PRUNE). […] THE
LATTER WOULD SOLVE OUR ISSUES WITH REVISIONS AND THUS
IS MY PREFERENCE.”
– CHX
25. We want to manage content and workflow well
Complex topic with too many use cases
to consider for core
Need for revisions are the lowest common denominator
across all use cases
Other systems have solved parts of the problem already
CRAP vs CRUD
(Create, Read, Archive, Prune)
TO SUMMARIZE
29. Done a lot of coding on
Multiversion and Relaxed WS
modules.
Multiple core patches within
the last couple of months.
CREDIT
Awesome guy
Andrei Jechiu – @jeqq
30. Enable revisions for node types by default
BABY STEPS
...things we can do in core today
31. Assume content is distributed
Enforce revisions
Every change is a new revision (even delete)
Give revisions a universally unique hash
Revisions should have a universally identifiable parent
Expose revisions over a RESTful API (RELAXed WS)
LONG TERM
32. We just need to use existing APIs differently
Additional “rev” field
Additional “deleted” field
Change logic in save and delete methods
for base storage handler
DRUPAL 8.X?
...can we backport from Multiversion module?