[development] Requiring node revisions

[David Strauss]

Dries Buytaert wrote:
> 
> On 07 Jun 2007, at 11:04, David Strauss wrote:
>> * Fewer site administration options
>> * Cleaner node-editing pages for node administrators
>> * Less confusion over what checking the box does: "Aren't I creating a
>> new revision of the node even if I don't check it?"
> 
> The above arguments seem to be different variations of the same. ;-)

They are all about UI simplification, yes.

> Node revisions is one of these things that people are not expecting when
> they first start using Drupal as a simple blog, a forum, or whatnot.  It
> is the kind of feature that makes them shout: "Drupal is overkill for a
> simple $site!", for different flavors of $site.
> 
> Furthermore, the most important "visual artifact" of node revisions is
> not the "create new revision" checkbox, but the fieldset/textarea for
> the log message that is always expanded (fixed in D6).  I argue that it
> is mainly the textarea that is confusing and that feels like
> clutter/overkill -- especially because the checkbox and the log message
> are not logically grouped. The proposed change sounds somewhat
> counter-productive because the log message textarea would become more
> prominent (while the checkbox goes away).  Not sure if we win or loose ...

Then maybe we should move toward having a revisions cleanup system that,
by default, deletes all old revisions. It would still be a big code
simplification. If the system is set to keep no old revisions,
node.module can simply delete old revisions after saving the new one.

Another option is to hide the revisions tab unless enabled in the admin
interface. The option to write log messages, too, could be off by
default. It's very nice when helping someone to be able to say to
someone when they delete something important, "Hey, you know Drupal has
saved all the old revisions of that node. You just have to turn on
access to the revisions."

Yes, all of these solutions complicate the interface, but it's at least
in the admin area and not on the node forms.

>> * Lots of users are accustomed to editing Wikipedia, so seeing a
>> revisions tab shouldn't be scary to new users of Drupal.
> 
> One could argue that users are more accustomed with simple blogs,
> forums, and straight-forward publishing tools than with Wikipedia, or
> wikis in general.  For these users, a revisions tab and a log message
> might be both scary and overkill.  Versioning takes a special kind of
> mindset that not everyone ships with.  Making it less visible for the
> user, while maintaining its functionality, seems like a good idea.  It's
> like the auto-save feature in Word, Google docs, Mail app, etc.
> 
> Of course, we could introduce a new setting to nuke the log message and
> to make it 100% transparent, but it might render the "fewer site
> administration options" argument moot.  Furthermore, if we need more
> complex mechanisms to expire or tome revisions, that might also conflict
> with the argument that this would simplify administration.  I think we
> need to investigate more -- and look at this from the different use case
> (i.e. forum, blog, wiki, brochure site, collaborative site, etc).

All of Google's document and page tools have revision tracking now.
Every major wiki system has revision tracking. Forums tend not to track
revisions, but they do note if/when a person modified a post. I haven't
used blogging software in a long time, so I can't speak there. Several
versions of Windows Vista have a feature called volume shadow copy that
keeps old document revisions. Apple will be releasing Time Machine with
the next version of OS X so supporting applications will be able to
easily support revisions. Facebook, by default, shows a one-sided diff
of a user's page changes when you click on them from the home page.

We certainly wouldn't be alone in tracking revisions by default. The key
is to keep the revision tracking out of the user's face unless they need
to browse old revisions. Always keeping old revisions is a step toward that.

> How often do we do a rollback on drupal.org?  How often have you done a
> rollback of one of your blog posts? How often have you rolled back a
> change on your company website?  If the answer is "never" or "once a
> year" this should be reflected in the UIs. The current system allows for
> that, but it looks like the proposed changes might not.  Let's think and
> brainstorm about this more, because we might be able to improve the
> revision system *and* make it easier for the user.

The interface for managing revisions is a separate issue from whether we
always create revisions. Even if someone rarely reverts nodes, in the
handful of times they need it, it's a godsend. But for reverts to be
possible those handful of times, revisions need to be saved every time.

> Clearly, node revisions is also the feature that lets people shout:
> "Drupal can do more than a simple $site", again for different flavors of
> $site.  I'm *not* proposing to remove Drupal's versioning.  Quite the
> contrary.  I just wanted to point out that we should take this as an
> opportunity to optimize the user experience for people that want to do
> simple things, and that can't be bothered with rollbacks.  Let's keep
> these users in mind ...
> 
> As a Drupal user myself, I don't necessarily want to create a new
> revision when I add missing commas to my posts.  It would just create
> "revision noise".  Then again, if all of this happened without me even
> knowing, I wouldn't make a point out of it.  Still, the purist in me
> knows that such revisions will be 100% useless and redundant even before
> they are created. Adding commas might become a big deal. ;-)

In that case, I'd rather go with the system MediaWiki has: minor
revisions. You can easily hide these in the revision logs.

>> * Better-tested node-saving code. I sometimes find modules that don't
>> work properly with revisions.
> 
> I wonder why this is.  Are these modules using the proper APIs?  Maybe
> the solution is not to enforce revisions, but to improve our APIs?  Or
> both?  I'm just playing the devil's advocate here.

The problem is that there are two hooks for saving nodes. One is
expected to UPDATE. The other is expected to INSERT. Of course, when you
receive a node in the update hook that's actually a new revision, you
generally have to redirect it to the insert hook. This is such basic
behavior right now that it's even in the node module example on the API
site.

These UPDATE and INSERT queries require constant maintenance to keep up
with form and database changes. It's very easy to neglect UPDATE if you
have node revisions on or neglect sending new revisions to INSERT if you
have node revisions off. I've done it many times myself.

But if we always create revisions, modules can simply implement the
insert hook and run one INSERT query.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20070607/ed8a80d3/attachment-0001.pgp