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.

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

6. WHAT’S THE PROBLEM?

7. We’ve all been here…

8. This is not the answer…

9. Neither is this…

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

15. SYSTEMS THAT CARE

16. Distributed Version Control Systems
Databases capable of (true) multi-master replication
SYSTEMS THAT CARE

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

18. Apache CouchDB
Cloudant
MySQL
PostgreSQL BDR
Oracle
Microsoft SQL
MULTI-MASTER DATABASES
...list from Wikipedia

19. Apache CouchDB
Cloudant
MySQL
PostgreSQL BDR
Oracle
Microsoft SQL
MULTI-MASTER DATABASES
...list from Wikipedia

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

21. SOME DRUPAL HISTORY

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

23. CRAP!

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

26. WHAT CAN WE DO?

27. Multiversion
(content revisions)
+
RELAXed Web Services
(API)
+
Deploy
(UI for content staging)
DRUPAL 8 CONTRIB
...iterate and mature the ideas

28. MULTIVERSION DEMO
A N D R E L A X E D W E B S E R V I C E S

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?

33. DRUPAL 9?

34. WHAT DID YOU THINK?
EVAULATE THIS SESSION - LOSANGELES2015.DRUPAL.ORG/SCHEDULE
THANK YOU!

35. Does this belong in core?
Drupal 8.x or 9.x?
Are there other use cases?
Performance and scaling issues?
Discuss!
QUESTIONS?
@dickolsson – dixon_