Move content revisions into a module so that it can be disabled easily

[jenlampton]

It's always bothered me that sites that don't need node revisions have no way of turning them off. Can we move this functionality into a separate module, so that it can be disabled by default? (It's not a 80% use-case)

[klonos]

So long as we don't remove the revisions feature altogether, I'm perfectly fine with moving this to a separate module and even having it disabled by default. It'll simply be another tedious thing for people like me having to enable the module and configure things each time we set up a new site. Kinda reminds me the situation with the Overlay that was on by default and the Toolbar vs admin_menu.

It's just because I use revisions as a best practice and have them enabled for most if not all my customers. It's something that they don't have to worry about but surely appreciate when something goes wrong ..."Oh I accidentally deleted all this text but didn't mean to and I have no copies of it!" :( ..."Ah! My site keeps automatic backups!! How awesome is that!!!" :D

I'm also a big fun of the "Unpublish - Don't delete" practice for the same reasons I use revisions. I think that some sort of "recycle bin"/"trash" feature would be great. Here are some related d.o projects:

Content Unpublish
Hidden Comment
Soft Delete
Entity Soft Delete (my personal favorite)
Trashbin
Trash
Junk
Recycle Bin
Recycle Node
Recover

...and various related articles around the web:

Proposal: unpublish rather than delete content
Can I recover a missing content page?
request for a "recycle bin" module
Node recycle-bin
how to unpublish a comment rather than deleting it
Is it possible to restore a deleted node?
Unpublish, don't delete
Node deletion is forever
Revert deleted node (or replace “Delete” with “Hide”) in Drupal 6
Prevent Drupal from Delete a node and add you own action

[klonos]

...which reminded me of some issues from d.o and lead me to file #285.

Is this issue still needed? Not sure if this was an option when this issue was submitted, but there's an setting to 'Show option to create new revisions' in BD now, so does that solve the issue of disabling revisions, or do we still want to discuss moving them to their own module?

If yes, I'm in favour of it, as I never use them.

[jenlampton]

I'm in favor of it as well, as I also never use them. For me, the work of disabling revisions on every content type is still too much work. I'd prefer to have single off switch for my whole site.

[docwilmot]

Would it be simpler to just have a switch at admin/config/content that turns revisions off? Dont know how much work it would be to disentangle the concept of revisions from nodes/entities.

[jenlampton]

I don't think we need to disentangle the concept of revisions from nodes/entities, we just need the module to be the "switch". Then we can move all the revision specific code into the module, and the core module can be a model for how contrib can deal with revisions on other entities, for example.

edit: The entity API still needs to deal with revisions (arguably, and do it better than it does right now) or contrib wouldn't have the ability to use them the way it needs to.

[olafgrabienski]

For me, the work of disabling revisions on every content type is still too much work.

What about disabling the Show option to create new revisions checkbox by default?

[jenlampton]

I think that would be too much work for those that do want revisions to turn it on for every content type. It should be a module, to be consistent with everything else.

…

On Fri, Apr 20, 2018, 1:18 AM Olaf Grabienski ***@***.***> wrote: For me, the work of disabling revisions on every content type is still too much work. What about disabling the Show option to create new revisions checkbox by default? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#284 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYSRzvkjk83v5N8EHobn5mKfCbZWdYsks5tqZm6gaJpZM4CR0GW> .

[olafgrabienski]

@jenlampton I see! Personally, I don't find it much work to enable or disable revisions via the content type settings. But if it makes also sense from an architecture point of view to put revisions in a module, that may be a good decision.

I'm however still a bit skeptical about the proposal because the option to use revisions is better visible when they stay in the settings, especially for users new to Backdrop. (I don't think that many users scan the Modules page to find such things.) What do you (and others) think about it?

Since revisions are enabled by default on new content types currently, making Revisions into a module would mean having that module also enabled by default. People like Jen and I could then easily disabled/uninstall revisions, and everyone else still sees and uses them as normal.

[jenlampton]

I think we should start by leaving them enabled in core, but in a module to easily turn off site-wide.

…

On Fri, Apr 20, 2018, 9:41 AM Olaf Grabienski ***@***.***> wrote: @jenlampton <https://github.com/jenlampton> I see! Personally, I don't find it much work to enable or disable revisions via the content type settings. But if it makes also sense from an architecture point of view to put revisions in a module, that may be a good decision. I'm however still a bit skeptical about the proposal because the option to use revisions is better visible when revisions stay in the settings, especially for users new to Backdrop. (I don't think that many users scan the *Modules* page to find such things.) What do you (and others) think about it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#284 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYSR5VqwEroILJXv08-vWZie0swT2zTks5tqg_EgaJpZM4CR0GW> .