Enable revisions by default / CRAP and entity revisions everywhere in core.

[klonos]

1st step is basically https://www.drupal.org/node/2490136, which is has been implemented in D8.2:

Enable revisions by default when creating a new content type, and also for the article and page content types added by the standard install profile.

It is something that bothers me quite a bit when doing the initial setup of every site since I have to go through the tedious procedure of enabling revisions for existing content types. Then I need to remember to enable it for new custom ones too. It resembles the procedure I was repeating in order to get admin_menu installed and to disable the Overlay and Toolbar modules.

I think that the limitations of the past such as disk space is not a concern any longer, even on the cheapest hosting plans. Performance might be one, but I have not seen any actual benchmarks - only theories that say that keeping many revisions of nodes would slow the site down.

There was a session in DrupalCon Barcelona on September 2015 about it. Here's the screencast: https://www.youtube.com/watch?v=LKQczUM7Qrw

[klonos]

...I think what I love the most about this is that we could that way skip the deletion confirmation step entirely (less clicks, less screen loads = UX+) and replace it with a "restore" or "undo" link added to the "node x was successfully deleted" message.

[klonos]

Part of #1388 since WordPress offers this out of the box and is the default setting (create a page, then edit and publish changes):

[klonos]

I love the "timeline" implementation of the revision browser in WP!

[sutibun]

Like revisions for content. Though undecided if this should be turned on by default.

Notice WP also shows differences in revisions (there's a Drupal module called diff if remember name correctly) Having revisions isn't useful without comparison. So, I think we should include the diff feature. (Been meaning to create a ticket for this)

In WP, people actually disable the auto revision feature. Creates so much clutter because every tiny change is recorded. I think if this will be turned on by default, Bd needs to have a way to manage the revisions automatically as well. Hint hint: issue #1313

[sutibun]

Ah, the timeline UI must be fairly new… don't remember that in WP. Lots of UI peeps over there. Tempting monkey to switch to the dark team :p

[klonos]

...Tempting monkey to switch to the dark team :p

Ha. I've been giving the "dark side" a spin for some time now (trying to put a list together for #1388) and I have to admit that quite a few times this thought has crossed my mind too. There's so many things that "simply work" out of the box in WP. It does lack one single but really powerful thing that is now in both Drupal and Backdrop core: Views.

[klonos]

...there's a Drupal module called diff if remember name correctly ...

yep, it's Diff

[jenlampton]

I find it very interesting that WP includes revisions enabled out of the box!

Revisions have always been something I thought were a better candidate for contrib than for core (and it makes me grumpy that there's no good way to disable them for a whole site!) but perhaps I am about to stand corrected about keeping them in core.

I'd love to get some usage statistics on how many Backdrop sites use revisions. In my experience less than 10% of Drupal sites I've built have wanted or requested revisions (which is why I've always wanted an easy way to disable them) but if WP users like and use this feature, perhaps it's something we should consider improving in Backdrop for our audience.

I have added revisions to the list of features we should track usage on, here: https://github.com/backdrop-ops/backdropcms.org/issues/99

[docwilmot]

Is this a dupe of https://github.com/backdrop/backdrop-issues/issues/1475? In either case posting here since we've had more recent comments.

I had a look at porting Create an interface for revisionable entities and Support revisions in different states. I got the interface bit working after a quick try, but tests fail miserably. The reason is because the entity tests use a custom entity with its own class which doesnt have the Default Revision capability. The option was either to add that or revise the test entity; Drupal went with the latter, which spawned a bunch of other work including

• Remove entity_extract_ids() now that we have proper classed entity objects
• Fix the field_test entity type
• Remove stub entities, replace entity_create_stub_entity()

It would be great to consider how much of this we needed done in order to get proper revisions and workflow into Backdrop, because it seems to me that these issues would be needed to get them done right.

The fact is also, that workflow is immensely important to some sites but unlike most situations where we could say "let this develop in contrib", from reading the issues on D.org it seems that the contrib attempts are all hackish, because core simply does not allow sane workflow management without those changes.

So we should decide.

[jenlampton]

The Drupal 6 workflow module was by far my favorite. I wonder why that approach was never ported / followed in Drupal 7. It never felt hackish and did a really good job for that 10% of sites that needed it. I wonder if something like that could work for Backdrop?

[olafgrabienski]

Don't know if still of interest: Workflow was actually ported to D7, see https://www.drupal.org/project/workflow. I had used the module in a D6 site which I rebuilt in D7, and the module worked fine even in D7.

[jenlampton]

Huh, look at that! :) I think we should revisit this approach for Backdrop.

[ghost]

Similar, but opposite, issue: #284 These need to be discussed together I think.

For example, the way revisions work now, I'd rather have them easily disablable as per the linked issue. If we were to totally rework them however (e.g. make them default, remove deletion ability, etc.), then I can see myself wanting to use them as per this issue...