Requiring node revisions
Currently, there are two revision-control options when saving a node: 1. Overwrite the latest revision. 2. Create a new revision. I think #1 has very little value. Argument for allowing #1: * Slightly smaller database size Arguments for only allowing #2: * 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?" * Less node-saving code. Currently, many modules have to redirect new revisions to the node creation code. We can dump hook_update if every node save is a new revision. A module can still check if it's really a new node if the module needs to do anything special. * Better-tested node-saving code. I sometimes find modules that don't work properly with revisions. * Site administrators will have more options to recover from mistakes without having to remember to check a box or configure every content type to create new revisions by default. * Using modules that automatically clean up old revisions can cap the increase in database size. * Files are shared across revisions, so there's little increase in disk space. * There's no performance impact to keeping old revisions around. A JOIN on {node_revisions} happens regardless of whether multiple revisions are in use. * Lots of users are accustomed to editing Wikipedia, so seeing a revisions tab shouldn't be scary to new users of Drupal. * Even if they don't know how to use the revisions tab, the site will function exactly as if they didn't use revisions. Even cheap shared hosts allow ridiculous amounts of space, so database size isn't that important anymore. Unless there's a really compelling argument for leaving #1 around, I'd like to create an issue to eliminate the ability to save a node without creating a new revision in Drupal 6.
I see no reason not to require node revisions. I feel that this is an under-utilized aspect of Drupal anyway, and there are a number of interesting contrib modules that have been created in the last year to make revisions more powerful. Promoting them as the de-facto way of doing Drupal is a good idea.
On 07/06/07, David Strauss <david@fourkitchens.com> wrote:
Currently, there are two revision-control options when saving a node:
1. Overwrite the latest revision. 2. Create a new revision.
I think #1 has very little value.
Even cheap shared hosts allow ridiculous amounts of space, so database size isn't that important anymore. Unless there's a really compelling argument for leaving #1 around, I'd like to create an issue to eliminate the ability to save a node without creating a new revision in Drupal 6.
One of many scenarios where this will prove to be a hindrance: 1. I create a page using the PHP filter containing sensitive information. 2. I forget to select the PHP input format. 3. I notice this and edit the page again and select the correct format. 4. I think all is well. Anybody who can view revisions will be able to see my sensitive information. -K
This speaks to a need for "access own node-type revisions" vs "access node-type revisions" permission, imo. Karthik wrote:
One of many scenarios where this will prove to be a hindrance:
1. I create a page using the PHP filter containing sensitive information. 2. I forget to select the PHP input format. 3. I notice this and edit the page again and select the correct format. 4. I think all is well.
Anybody who can view revisions will be able to see my sensitive information.
-K
2007/6/7, Robert Douglass <rob@robshouse.net>:
This speaks to a need for "access own node-type revisions" vs "access node-type revisions" permission, imo.
+1 It might also be desireable to have a "delete revision" option, but I suppose this could be included in a module if it doesn't go into core. (I also agree that Drupal should just require revisions straight off. I find it quite annoying to go through all content types and ask them to make new revisions by default...) -- Frederik 'Freso' S. Olesen <http://freso.dk/>
On Jun 7, 2007, at 6:00 AM, Frederik 'Freso' S. Olesen wrote:
2007/6/7, Robert Douglass <rob@robshouse.net>:
This speaks to a need for "access own node-type revisions" vs "access node-type revisions" permission, imo.
+1
It might also be desireable to have a "delete revision" option, but I suppose this could be included in a module if it doesn't go into core.
Doesn't this already exist? If I go to the revisions tab of a node (I'm running 5.1), I see options to "revert" to earlier revisions, or to "delete" the earlier revisions. Ricky The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Karthik wrote:
One of many scenarios where this will prove to be a hindrance:
1. I create a page using the PHP filter containing sensitive information. 2. I forget to select the PHP input format. 3. I notice this and edit the page again and select the correct format. 4. I think all is well.
Anybody who can view revisions will be able to see my sensitive information.
On any site, viewing old revisions should be restricted to only the most trusted users unless you're trying to operate like a wiki. As long as we default to denying anonymous and authenticated users the right to view old revisions, I think we'll be fine here.
On 07/06/07, David Strauss <david@fourkitchens.com> wrote:
Karthik wrote:
One of many scenarios where this will prove to be a hindrance:
1. I create a page using the PHP filter containing sensitive information. 2. I forget to select the PHP input format. 3. I notice this and edit the page again and select the correct format. 4. I think all is well.
Anybody who can view revisions will be able to see my sensitive information.
On any site, viewing old revisions should be restricted to only the most trusted users unless you're trying to operate like a wiki. As long as we default to denying anonymous and authenticated users the right to view old revisions, I think we'll be fine here.
Right now, I don't have to do or worry about any of this. I can see that it's a PHP page and just choose not to create a revision or disable it altogether for all page nodes by default. Choice, Choice, Choice ... -K
Karthik wrote:
Right now, I don't have to do or worry about any of this. I can see that it's a PHP page and just choose not to create a revision or disable it altogether for all page nodes by default.
Choice, Choice, Choice ...
Choice is a bad thing when it's unnecessary.
Quoting Karthik <narakasura@gmail.com>:
One of many scenarios where this will prove to be a hindrance:
1. I create a page using the PHP filter containing sensitive information. 2. I forget to select the PHP input format. 3. I notice this and edit the page again and select the correct format. 4. I think all is well.
Anybody who can view revisions will be able to see my sensitive information.
* Create a content type ``sensitive data''. * Create a role ``sensitive user''. ** Set the Create and Edit ``sensitive data'' for this role. * Assign a user the ``sensitive user'' role. Now only the ``sensitive user'' user can see the page to see the revision. Did I miss something? Earnie
-----Original Message----- From: development-bounces@drupal.org [mailto:development- bounces@drupal.org] On Behalf Of Earnie Boyd Sent: Thursday, June 07, 2007 5:45 AM To: development@drupal.org Subject: Re: [development] Requiring node revisions
Quoting Karthik <narakasura@gmail.com>:
One of many scenarios where this will prove to be a hindrance:
1. I create a page using the PHP filter containing sensitive
information.
2. I forget to select the PHP input format. 3. I notice this and edit the page again and select the correct format. 4. I think all is well.
Anybody who can view revisions will be able to see my sensitive information.
* Create a content type ``sensitive data''. * Create a role ``sensitive user''. ** Set the Create and Edit ``sensitive data'' for this role. * Assign a user the ``sensitive user'' role.
Now only the ``sensitive user'' user can see the page to see the revision. Did I miss something?
Earnie
6 years of released Drupal installations that have existing content not in this new role.
yes, i think the time has come for automatically tracking revisions. +1
On Jun 7, 2007, at 6:30 AM, Moshe Weitzman wrote:
yes, i think the time has come for automatically tracking revisions. +1
+1 to always requiring revisions (did anyone honestly expect Mr. Revision Control to think otherwise?). ;) so, next step: diff.module in core? if we're going to force revisions all the time, shouldn't core have a better UI for displaying them? -derek
+1 Agree to Derek that a polished-up diff.module need to be consider in core as well. On 6/7/07, Derek Wright <drupal@dwwright.net> wrote:
On Jun 7, 2007, at 6:30 AM, Moshe Weitzman wrote:
yes, i think the time has come for automatically tracking revisions. +1
+1 to always requiring revisions (did anyone honestly expect Mr. Revision Control to think otherwise?). ;)
so, next step: diff.module in core? if we're going to force revisions all the time, shouldn't core have a better UI for displaying them?
-derek
On Thu, 7 Jun 2007 10:58:03 -0700, Derek Wright <drupal@dwwright.net> wrote:
On Jun 7, 2007, at 6:30 AM, Moshe Weitzman wrote:
yes, i think the time has come for automatically tracking revisions. +1
+1 to always requiring revisions (did anyone honestly expect Mr. Revision Control to think otherwise?). ;)
so, next step: diff.module in core? if we're going to force revisions all the time, shouldn't core have a better UI for displaying them?
-derek
There are cases where I don't want revisions at all. Maybe I don't want a paper-trail. :-) If the code is considerably simpler if revisions are required, then I would say we should also consider it a requirement that we have auto-trimming of revisions in core, per node type, (only keep the last X revisions of node type Y), and document that setting it to 0 will have "no revisions saved". That becomes the new alternative way of saying "revisions off", but has cleaner code. --Larry Garfield
http://drupal.org/project/revision_deletion is probably a long way from ideally suited for this, as it trims by age of revision, not the number of revisions, but it may be a decent starting point. -Greg -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield Sent: Thursday, June 07, 2007 11:17 AM To: development@drupal.org Subject: Re: [development] Requiring node revisions There are cases where I don't want revisions at all. Maybe I don't want a paper-trail. :-) If the code is considerably simpler if revisions are required, then I would say we should also consider it a requirement that we have auto-trimming of revisions in core, per node type, (only keep the last X revisions of node type Y), and document that setting it to 0 will have "no revisions saved". That becomes the new alternative way of saying "revisions off", but has cleaner code. --Larry Garfield
I don't think a fixed number of revisions is as useful as a date cutoff. If someone uses revisions so community members can edit nodes, it's very easy to abuse a fixed number per node cutoff. Greg Holsclaw wrote:
http://drupal.org/project/revision_deletion is probably a long way from ideally suited for this, as it trims by age of revision, not the number of revisions, but it may be a decent starting point.
-Greg
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield Sent: Thursday, June 07, 2007 11:17 AM To: development@drupal.org Subject: Re: [development] Requiring node revisions
There are cases where I don't want revisions at all. Maybe I don't want a paper-trail. :-)
If the code is considerably simpler if revisions are required, then I would say we should also consider it a requirement that we have auto-trimming of revisions in core, per node type, (only keep the last X revisions of node type Y), and document that setting it to 0 will have "no revisions saved". That becomes the new alternative way of saying "revisions off", but has cleaner code.
--Larry Garfield
David Strauss wrote:
I don't think a fixed number of revisions is as useful as a date cutoff. If someone uses revisions so community members can edit nodes, it's very easy to abuse a fixed number per node cutoff.
David what do you think about letting the user decide this and placing the two options under the content type editing interface in admin/content/types. A "Revision History" field group with: Maximum number of previous revisions to keep: (Select Box with the following options: None, 1, 5, 10, 25, 100, Unlimited) Delete revisions older than: (Select Box with the following options: Never/None, Today, 1 Week, 1 Month, 1 Year) Obviously those are just suggested values, but i think it is a start. It provides good control and addresses your and others issues in a decently coherent manner while allowing you to set different settings depending on the content type so that you can keep "wiki content type revisions while discarding more static types like articles as desired. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On 6/7/07, Larry Garfield <larry@garfieldtech.com> wrote:
There are cases where I don't want revisions at all. Maybe I don't want a paper-trail. :-)
Maybe I just don't want the overhead? That would be a neat thing to have. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On Jun 7, 2007, at 11:26 AM, Khalid Baheyeldin wrote:
Maybe I just don't want the overhead?
That would be a neat thing to have.
i hope you don't take this the wrong way, but i don't think you grasp how {node_revisions} currently works. you get the overhead of the JOIN on {node_revisions} no matter what (though as David points out, this is mostly free, since we rarely/never try to WHERE or ORDER BY on things from {node_revisions}). the only overhead of this change is the extra rows in the {node_revisions} table, and the thread is already discussing interesting ways to limit/reduce *that* overhead for sites that care about such things. -derek
On 08/06/07, Derek Wright <drupal@dwwright.net> wrote:
i hope you don't take this the wrong way, but i don't think you grasp how {node_revisions} currently works. you get the overhead of the JOIN on {node_revisions} no matter what (though as David points out, this is mostly free, since we rarely/never try to WHERE or ORDER BY on things from {node_revisions}). the only overhead of this change is the extra rows in the {node_revisions} table, and the thread is already discussing interesting ways to limit/reduce *that* overhead for sites that care about such things.
Why bother limiting when you can choose not to have it at all? The extra rows can make a substantial difference depending on what your query is doing. I'm all for switching revisions on by default. Most of David's listed advantages will be realised simply by doing this. -1 for not giving me the choice to configure how my site works. -K
If that's true, then the overhead of a JOIN on an empty table would be significantly different than the join on a table that has a million rows in it, regardless of the filter criteria, yes? I really like being able to enable/disable this by content type, particularly in light of the discussions regarding making more things nodes. (user profiles, commments, etc). Are we suggesting that the option goes a way or that revisions.module becomes required or dissapears, or are we talking about making revisions always on or always off? On Jun 7, 2007, at 11:31 AM, Derek Wright wrote:
On Jun 7, 2007, at 11:26 AM, Khalid Baheyeldin wrote:
Maybe I just don't want the overhead?
That would be a neat thing to have.
i hope you don't take this the wrong way, but i don't think you grasp how {node_revisions} currently works. you get the overhead of the JOIN on {node_revisions} no matter what (though as David points out, this is mostly free, since we rarely/never try to WHERE or ORDER BY on things from {node_revisions}). the only overhead of this change is the extra rows in the {node_revisions} table, and the thread is already discussing interesting ways to limit/reduce *that* overhead for sites that care about such things.
-derek
On Jun 7, 2007, at 12:38 PM, David Metzler wrote:
If that's true, then the overhead of a JOIN on an empty table would be significantly different than the join on a table that has a million rows in it, regardless of the filter criteria, yes?
no: 1) {node_revisions} *ALWAYS* has at least 1 record for any given node. that's where title, body, etc are stored. please read the schema if you have further questions. therefore, the only site with an empty {node_revisions} table is the site with no nodes at all. 2) {node_revisions} has an index on nid, and we always JOIN on nid. by and large, the cost of this JOIN is constant, regardless of the # of rows in the table, since the JOINs basically always use the index. cheers, -derek (dww)
Derek Wright wrote:
1) {node_revisions} *ALWAYS* has at least 1 record for any given node. that's where title, body, etc are stored. please read the schema if you have further questions. therefore, the only site with an empty {node_revisions} table is the site with no nodes at all.
2) {node_revisions} has an index on nid, and we always JOIN on nid. by and large, the cost of this JOIN is constant, regardless of the # of rows in the table, since the JOINs basically always use the index.
Actually, we join on vid, but that also has an index. You're correct about the rest, though. Extra revisions have little effect on the JOIN performance.
On 08/06/07, Derek Wright <drupal@dwwright.net> wrote:
1) {node_revisions} *ALWAYS* has at least 1 record for any given node. that's where title, body, etc are stored. please read the schema if you have further questions. therefore, the only site with an empty {node_revisions} table is the site with no nodes at all.
2) {node_revisions} has an index on nid, and we always JOIN on nid. by and large, the cost of this JOIN is constant, regardless of the # of rows in the table, since the JOINs basically always use the index.
Eh? So what is by and large? Does that mean some queries will be less efficient? For example, how about if my module in contrib perform an ORDER BY on node_revisions fields such as timestamp and uid? This would require a filesort on the entire table ... Will these be unaffected? This is essentially: a) Taking away choice. b) Increasing table size. c) Introducing inefficiency. d) Loading the table with potentially unnecessary junk whether I like it or not. e) Asking me to sort any resulting issues out with another contrib module. f) Telling me what's good for my site. ... all for the sake of a couple of checkboxes. No thanks. -1. -K
Karthik wrote:
On 08/06/07, Derek Wright <drupal@dwwright.net> wrote:
1) {node_revisions} *ALWAYS* has at least 1 record for any given node. that's where title, body, etc are stored. please read the schema if you have further questions. therefore, the only site with an empty {node_revisions} table is the site with no nodes at all.
2) {node_revisions} has an index on nid, and we always JOIN on nid. by and large, the cost of this JOIN is constant, regardless of the # of rows in the table, since the JOINs basically always use the index.
Eh? So what is by and large? Does that mean some queries will be less efficient?
For example, how about if my module in contrib perform an ORDER BY on node_revisions fields such as timestamp and uid? This would require a filesort on the entire table ... Will these be unaffected?
That's a ridiculous, contrived scenario. If your site's small enough, the performance won't change much. If your site's large, you should add a new index on {node_revisions}. You're not going to convince anyone here that the DB should be structured to maximize performance of your hypothetical, ill-conceived queries.
This is essentially:
a) Taking away choice.
Taking away frivolous choices is a good thing.
b) Increasing table size. c) Introducing inefficiency. d) Loading the table with potentially unnecessary junk whether I like it or not.
All three of those are overstatements of the same thing: the DB gets a little better. The increase in size is pretty minor.
e) Asking me to sort any resulting issues out with another contrib module.
It's official policy to completely disregard compatibility issues with contrib.
f) Telling me what's good for my site.
If you're so desperate to not have revisions, you can write a contrib module that deletes all old revisions every time you save a node.
... all for the sake of a couple of checkboxes.
And all the other reasons mentioned in my post. Nice strawman.
No thanks. -1.
-K
On 08/06/07, David Strauss <david@fourkitchens.com> wrote:
Eh? So what is by and large? Does that mean some queries will be less efficient?
For example, how about if my module in contrib perform an ORDER BY on node_revisions fields such as timestamp and uid? This would require a filesort on the entire table ... Will these be unaffected?
That's a ridiculous, contrived scenario. If your site's small enough, the performance won't change much. If your site's large, you should add a new index on {node_revisions}. You're not going to convince anyone here that the DB should be structured to maximize performance of your hypothetical, ill-conceived queries.
I'm just refuting claims that there is no difference in performance. Even with core queries, there will be a difference in performance, albeit minor. But a difference nonetheless.
a) Taking away choice.
Taking away frivolous choices is a good thing.
What is frivolous to you is not frivolous to other people. That's why Drupal gives them a choice. Drupal is inherently malleable.
b) Increasing table size. c) Introducing inefficiency. d) Loading the table with potentially unnecessary junk whether I like it or not.
All three of those are overstatements of the same thing: the DB gets a little better. The increase in size is pretty minor.
Perhaps I'm taking a leaf out of all the redundancies in your first post? The advantages gained are just not noteworthy enough, or can already be realised by just defaulting to "create new revision".
e) Asking me to sort any resulting issues out with another contrib module.
It's official policy to completely disregard compatibility issues with contrib.
I was talking about your recommendation to use a contrib module to clean up old revisions.
f) Telling me what's good for my site.
If you're so desperate to not have revisions, you can write a contrib module that deletes all old revisions every time you save a node.
Why? I'm happy as it is now.
... all for the sake of a couple of checkboxes.
And all the other reasons mentioned in my post. Nice strawman.
Please read and reply to Dries' response. -K
Maybe we can have a Global setting Revisions : Always Enabled Always Disabled Let the user decide ( this is how the current behaiour is ) The saving of node depends on this behavior including the form. While reading nodes there is no difference either way because node will always have at least one revision. The tab to manage revisions is not displayed if the option "Always Disabled" is in effect. ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
... all for the sake of a couple of checkboxes.
Of course, it would be an easy form_alter in contrib to turn the "create new revision" checkbox into a #value type form element and enforce revisions. Alternately, in core, we could create a "node_force_revision" variable. If set to 0, behaviour is as at present. If set to 1, the 'revision' form element is passed as a #value.
Nedjo Rogers wrote:
... all for the sake of a couple of checkboxes.
Of course, it would be an easy form_alter in contrib to turn the "create new revision" checkbox into a #value type form element and enforce revisions.
Alternately, in core, we could create a "node_force_revision" variable. If set to 0, behaviour is as at present. If set to 1, the 'revision' form element is passed as a #value.
The real reason I'm pushing for mandatory revisions is so content types don't have to implement two saving mechanisms, one UPDATE, one INSERT. So, we should just pick one. The revisions system is the clearly superior choice.
David, A new/updated node still has to INSERT or UPDATE the {node} table, so (maybe this is what you mean) the gain is only the code handing the revisions, right? -Peter On 6/7/07, David Strauss <david@fourkitchens.com> wrote:
The real reason I'm pushing for mandatory revisions is so content types don't have to implement two saving mechanisms, one UPDATE, one INSERT.
So, we should just pick one. The revisions system is the clearly superior choice.
Yes. Everywhere but {node} there currently has to two save handlers, one for updates and one for new revisions. Peter Wolanin wrote:
David,
A new/updated node still has to INSERT or UPDATE the {node} table, so (maybe this is what you mean) the gain is only the code handing the revisions, right?
-Peter
On 6/7/07, David Strauss <david@fourkitchens.com> wrote:
The real reason I'm pushing for mandatory revisions is so content types don't have to implement two saving mechanisms, one UPDATE, one INSERT.
So, we should just pick one. The revisions system is the clearly superior choice.
On 08/06/07, Nedjo Rogers <nedjo@islandnet.com> wrote:
... all for the sake of a couple of checkboxes.
Of course, it would be an easy form_alter in contrib to turn the "create new revision" checkbox into a #value type form element and enforce revisions.
And what would I do with it? David is proposing hard coding and creating revisions. No choice. His recommendation is that if, for e.g., I have a node type that always stores sensitive information and don't prefer to have revisions lying around, I should use a contrib module to delete them. Everything is perfectly configurable now. I just have to check / uncheck a box. -K
I have to agree with Larry. Of all my sites, only very rarely do I ever use revisions at all. I don't use them, need them, or want any of the overhead required for storing and maintaining them. -1 for requiring them always. +1 if we default to using revisions but provide some means of saying "revisions off" as Larry describes. On 7 Jun, 2007, at 13:16, Larry Garfield wrote:
On Thu, 7 Jun 2007 10:58:03 -0700, Derek Wright <drupal@dwwright.net> wrote:
On Jun 7, 2007, at 6:30 AM, Moshe Weitzman wrote:
yes, i think the time has come for automatically tracking revisions. +1
+1 to always requiring revisions (did anyone honestly expect Mr. Revision Control to think otherwise?). ;)
so, next step: diff.module in core? if we're going to force revisions all the time, shouldn't core have a better UI for displaying them?
-derek
There are cases where I don't want revisions at all. Maybe I don't want a paper-trail. :-)
If the code is considerably simpler if revisions are required, then I would say we should also consider it a requirement that we have auto-trimming of revisions in core, per node type, (only keep the last X revisions of node type Y), and document that setting it to 0 will have "no revisions saved". That becomes the new alternative way of saying "revisions off", but has cleaner code.
--Larry Garfield
Jim Riggs wrote:
I have to agree with Larry. Of all my sites, only very rarely do I ever use revisions at all. I don't use them, need them, or want any of the overhead required for storing and maintaining them.
-1 for requiring them always.
+1 if we default to using revisions but provide some means of saying "revisions off" as Larry describes. How about a setting for managing revision deletion criteria in the content type administration? A simple text input or select box would suffice for most needs and allow you to specify 0 as well. If someone wanted to be really tricky they could work in the date logic as an alternative or as an additional cutoff point so that we can for example: keep at most 5 revisions and delete all revisions older than 4 weeks, etc. Thoughts?
-- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On 7 Jun, 2007, at 13:38, Michael Favia wrote:
Jim Riggs wrote:
I have to agree with Larry. Of all my sites, only very rarely do I ever use revisions at all. I don't use them, need them, or want any of the overhead required for storing and maintaining them.
-1 for requiring them always.
+1 if we default to using revisions but provide some means of saying "revisions off" as Larry describes. How about a setting for managing revision deletion criteria in the content type administration? A simple text input or select box would suffice for most needs and allow you to specify 0 as well. If someone wanted to be really tricky they could work in the date logic as an alternative or as an additional cutoff point so that we can for example: keep at most 5 revisions and delete all revisions older than 4 weeks, etc. Thoughts?
Ideas like that are fine by my as long as there is /some/ way to limit revisions or have none at all (i.e. set keep to 0).
I'm responding to this before reading the entire rest of the thread, but... YES. Diff module is what makes revisions *work*. It is brilliant. It is perfect for core. Derek Wright wrote:
+1 to always requiring revisions (did anyone honestly expect Mr. Revision Control to think otherwise?). ;)
so, next step: diff.module in core? if we're going to force revisions all the time, shouldn't core have a better UI for displaying them?
-derek
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. ;-) 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 ...
* 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). 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. 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. ;-)
* 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. -- Dries Buytaert :: http://www.buytaert.net/
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. ;-)
heh. i thought the same thing. ;)
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 ...
This has the opportunity to simplify the interface further by placing the revision criteria under the content type settings. Then we can CONDITIONALLY place the "Log Message" textarea/fieldset in the appropriate content type with a simple message explaining that "Historical copies of this content are being stored for archival sake. Please summarize any changes you've made to this content." Those users who don't want it don't have to worry about it. This should remove the confusion by centralizing the decision to keep revisions and put it in the hands of the administrator. Please see my other post in this thread about how i think we could best organize the options under admin/content/types. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
maybe I'm saying something stupid, but wouldn't it make more sense to move the revision enable/disable option to the 'admin/content/types/ $type' in the first place? if people disable it for a node type, it doesn't need to be displayed any more on "node/add/$type". When it is enabled for the node-type, perhaps a checkbox to "Do not create a new revision" (with a access check for 'bypass revisions') makes sense? It are just some thoughts, and perhaps not the right. But to me it makes more sense.. Stefan
Codex (Wikipedia) does something similar. It has a "this is a minor edit" checkbox that, I presume, skips the versioning process. Some well-labeled option like that could be useful if we go the all-revisions route. --Larry Garfield On Thu, 7 Jun 2007 21:35:22 +0200, Stefan Nagtegaal <development@robuustdesign.nl> wrote:
maybe I'm saying something stupid, but wouldn't it make more sense to move the revision enable/disable option to the 'admin/content/types/ $type' in the first place? if people disable it for a node type, it doesn't need to be displayed any more on "node/add/$type".
When it is enabled for the node-type, perhaps a checkbox to "Do not create a new revision" (with a access check for 'bypass revisions') makes sense?
It are just some thoughts, and perhaps not the right. But to me it makes more sense..
Stefan
Minor edits are only marked as such for human interpretation. There is no difference in the software handling. Take it from someone with commit access to MediaWiki. :-) Larry Garfield wrote:
Codex (Wikipedia) does something similar. It has a "this is a minor edit" checkbox that, I presume, skips the versioning process. Some well-labeled option like that could be useful if we go the all-revisions route.
--Larry Garfield
On Thu, 7 Jun 2007 21:35:22 +0200, Stefan Nagtegaal <development@robuustdesign.nl> wrote:
maybe I'm saying something stupid, but wouldn't it make more sense to move the revision enable/disable option to the 'admin/content/types/ $type' in the first place? if people disable it for a node type, it doesn't need to be displayed any more on "node/add/$type".
When it is enabled for the node-type, perhaps a checkbox to "Do not create a new revision" (with a access check for 'bypass revisions') makes sense?
It are just some thoughts, and perhaps not the right. But to me it makes more sense..
Stefan
2007/6/7, David Strauss <david@fourkitchens.com>:
Minor edits are only marked as such for human interpretation. There is no difference in the software handling.
Actually, differentiating between "major" and "minor" (or minor and regular) edits enable people to only watch major/regular edits and skip the minor ones if they want (this applies both to MediaWiki, MoinMoin, and probably a fair share of other wiki systems).[1] Whether or not reviosioning goes in to be default, I'd actually like a check box to mark edits as minor or not - even if only to tell whether it is a simple comma correction edit or a major refactoring of a page. [1] A little ps.: My point was that if humans mark an edit as minor, software can handle it differently depending on ones settings - e.g. send a notification or not, show it in a list of recent changes or not, ... -- Frederik 'Freso' S. Olesen <http://freso.dk/>
Frederik 'Freso' S. Olesen wrote:
2007/6/7, David Strauss <david@fourkitchens.com>:
Minor edits are only marked as such for human interpretation. There is no difference in the software handling.
Actually, differentiating between "major" and "minor" (or minor and regular) edits enable people to only watch major/regular edits and skip the minor ones if they want (this applies both to MediaWiki, MoinMoin, and probably a fair share of other wiki systems).[1] Whether or not reviosioning goes in to be default, I'd actually like a check box to mark edits as minor or not - even if only to tell whether it is a simple comma correction edit or a major refactoring of a page.
[1] A little ps.: My point was that if humans mark an edit as minor, software can handle it differently depending on ones settings - e.g. send a notification or not, show it in a list of recent changes or not, ...
True, the software does provide some tools to help people sort through major and minor edits. What I meant was that the real guts of the software don't care. There's merely a flag marking the edit as minor.
OK, I sit corrected then. :-) However, some sort of "not a real revision" function would be useful for Drupal anyway if we go the "all revisions" route. --Larry Garfield On Thu, 07 Jun 2007 16:35:16 -0500, David Strauss <david@fourkitchens.com> wrote:
Minor edits are only marked as such for human interpretation. There is no difference in the software handling.
Take it from someone with commit access to MediaWiki. :-)
Larry Garfield wrote:
Codex (Wikipedia) does something similar. It has a "this is a minor edit" checkbox that, I presume, skips the versioning process. Some well-labeled option like that could be useful if we go the all-revisions route.
--Larry Garfield
On Thu, 7 Jun 2007 21:35:22 +0200, Stefan Nagtegaal <development@robuustdesign.nl> wrote:
maybe I'm saying something stupid, but wouldn't it make more sense to move the revision enable/disable option to the 'admin/content/types/ $type' in the first place? if people disable it for a node type, it doesn't need to be displayed any more on "node/add/$type".
When it is enabled for the node-type, perhaps a checkbox to "Do not create a new revision" (with a access check for 'bypass revisions') makes sense?
It are just some thoughts, and perhaps not the right. But to me it makes more sense..
Stefan
I agree that the 'Log Message' should have an option to be removed from the form. More often than not, a client asks me to remove it from the form via hook_form_alter. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Michael Favia Sent: Thursday, June 07, 2007 12:26 PM To: development@drupal.org Subject: Re: [development] Requiring node revisions CONDITIONALLY place the "Log Message" textarea/fieldset in the appropriate content type with a simple message explaining that "Historical copies of this content are being stored for archival sake. Please summarize any changes you've made to this content." .... -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
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.
On Thursday 07 June 2007, David Strauss wrote:
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.
I believe I said that ~20 messages ago. :-) If we're going to have an "always on" revision system, then it really does need to include a self-cleaning mechanism by default as well. Otherwise you have a system that takes more effort to maintain, or else never lets you delete anything. Let's not be Google. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield wrote:
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.
I believe I said that ~20 messages ago. :-)
If we're going to have an "always on" revision system, then it really does need to include a self-cleaning mechanism by default as well. Otherwise you have a system that takes more effort to maintain, or else never lets you delete anything. Let's not be Google.
Or maybe even my original post:
Using modules that automatically clean up old revisions can cap the increase in database size.
On Friday 08 June 2007, David Strauss wrote:
Larry Garfield wrote:
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.
I believe I said that ~20 messages ago. :-)
If we're going to have an "always on" revision system, then it really does need to include a self-cleaning mechanism by default as well. Otherwise you have a system that takes more effort to maintain, or else never lets you delete anything. Let's not be Google.
Or maybe even my original post:
Using modules that automatically clean up old revisions can cap the increase in database size.
Sounds like we're in complete agreement then. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Jun 7, 2007, at 10:46 PM, Larry Garfield wrote:
Sounds like we're in complete agreement then. :-)
I disagree with both of you! ;) I think we should always keep all revisions by default (even if we hide most of the UI to see/use them), and make site admins who think they want them off go out of their way to prune/disable them. The performance cost is negligible except for sites that care enough about performance to know their way around a few admin UI screens. The potential usability benefits of being able to say "oh yeah, just enable core's diff.module and grant some revision permissions to your editor role, and you'll be able to see all the changes anyone ever made to any of the nodes on your site". -Derek
I'm generally in agreement with Dries' "devils advocate" remarks. if we don't make the user experience better and simpler, this is wasted effort. Most users of web publishing are not the sophisticates that we are -- not even close, not even those comfortable with Microsoft Office (and if you've ever seen a sample of behaviors of people who even well versed in MS Office but not otherwise computer sophisticates, you'll be appalled at how they do things). I've never used revisions on any of numerous Drupal sites (or even other CMS sites) that I've been associated with -- and I even have the background of having worked for a real document management company (revisions burned to optical disk forever for legal reasons) and having used DEC's VMS with its auto-file versioning filesystem. Still, if there is no performance hit, turning revisions on all the time is ok with me, as long as the admin can easily trim the database. ..chrisxj
So far, David has convinced me that we should make revisions automatically and all the time, and that we should work towards simplifying the UPDATE/INSERT workflow for nodes. Doing this, and simultaneously working on the interface and workflow for revision management, will allow us to become a next generation publishing tool. We gain: - a very straightforward of saving drafts - the equivalent of Angie's revision moderation - in core - easier programming API - less cluttered UI - improved preview workflow I spend a lot of time worrying about performance, yet this change doesn't concern me. People who are worried about performance would be better of finding a better schema for the block tables so that the block loading queries aren't an order of magnitude slower than all the other queries that run on any page.
Robert has convinced me. ;-) P.S. I only wish I had time to work on optimizing blocks or any other bottleneck. I enjoy that kind of work, but it's time consuming and I have a hard time keeping up with the "must do" list. :-p On 6/8/07, Robert Douglass <rob@robshouse.net> wrote:
So far, David has convinced me that we should make revisions automatically and all the time, and that we should work towards simplifying the UPDATE/INSERT workflow for nodes. Doing this, and simultaneously working on the interface and workflow for revision management, will allow us to become a next generation publishing tool.
We gain: - a very straightforward of saving drafts - the equivalent of Angie's revision moderation - in core - easier programming API - less cluttered UI - improved preview workflow
I spend a lot of time worrying about performance, yet this change doesn't concern me. People who are worried about performance would be better of finding a better schema for the block tables so that the block loading queries aren't an order of magnitude slower than all the other queries that run on any page.
On 08/06/07, Robert Douglass <rob@robshouse.net> wrote:
So far, David has convinced me that we should make revisions automatically and all the time, and that we should work towards simplifying the UPDATE/INSERT workflow for nodes. Doing this, and simultaneously working on the interface and workflow for revision management, will allow us to become a next generation publishing tool.
We gain: - a very straightforward of saving drafts (1) - the equivalent of Angie's revision moderation - in core (2) - easier programming API - less cluttered UI - improved preview workflow (3)
1, 2 and 3 can be implemented just as well without making revisions mandatory. Easier programming API essentially involves removing an UPDATE query - no more. Less cluttered UI implies removing a couple of checkboxes. Derek's excellent ideas for improving the usability of the 'Publishing options' fieldset will mitigate most of them. -K
Karthik wrote:
On 08/06/07, Robert Douglass <rob@robshouse.net> wrote:
So far, David has convinced me that we should make revisions automatically and all the time, and that we should work towards simplifying the UPDATE/INSERT workflow for nodes. Doing this, and simultaneously working on the interface and workflow for revision management, will allow us to become a next generation publishing tool.
We gain: - a very straightforward of saving drafts (1) - the equivalent of Angie's revision moderation - in core (2) - easier programming API - less cluttered UI - improved preview workflow (3)
1, 2 and 3 can be implemented just as well without making revisions mandatory. Easier programming API essentially involves removing an UPDATE query - no more.
What distinguishes your INSERT-only system from mandatory revisions?
Less cluttered UI implies removing a couple of checkboxes. Derek's excellent ideas for improving the usability of the 'Publishing options' fieldset will mitigate most of them.
-K
We gain: - a very straightforward of saving drafts - the equivalent of Angie's revision moderation - in core - easier programming API - less cluttered UI - improved preview workflow
Better performance and we would gain better concurrent edits behaviour. At least the state of the data will be consistent. INSERT only is far simpler, and allows you to actually reason about what is in your db. cron driven garbage collection, regardless whether it is time based, or some cut-off number or both is simple and fast. It will simplify a lot not only core, but the logic of various 'relations' modules. Introducing a node garbage collector, might require some kind of labelling, so that essential revisions are kept. If this is done out of your face, when I actually require it, it will be a beneficial feature. Overall ++ for this. Dries has a point that we need to be able to keep the basic user happy. It could simply mean - automatic log messages, automatic revisions, automatic garbage collection, with reasonable default presets. For advanced usage, you will need to configure your site anyway, so it is better you go through the settings. I spend a lot of time worrying about performance, yet this change
doesn't concern me.
It might actually improve performance. On lightweight sites, there won't be any real difference. On heavy sites, There will be small peaks, on garbage collector runs, but the overall load should reduce. In theory. In the worst case, the performance will be the same. If you want to analyse the performance, you can go through the garbage collection vs reference counting arguments. This is the same, but for db.
On Friday 08 June 2007, Derek Wright wrote:
On Jun 7, 2007, at 10:46 PM, Larry Garfield wrote:
Sounds like we're in complete agreement then. :-)
I disagree with both of you! ;)
I think we should always keep all revisions by default (even if we hide most of the UI to see/use them), and make site admins who think they want them off go out of their way to prune/disable them. The performance cost is negligible except for sites that care enough about performance to know their way around a few admin UI screens. The potential usability benefits of being able to say "oh yeah, just enable core's diff.module and grant some revision permissions to your editor role, and you'll be able to see all the changes anyone ever made to any of the nodes on your site".
-Derek
That may be fine for a default setup, but if I for whatever reason *don't* want revisions saved (does it matter why?) for a given node type, I should be able to make that happen without scheduling a block of time every Friday afternoon to go through and manually delete them, and I should be able to do it without dipping into contrib. That is a complete and total waste of my time. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield wrote:
That may be fine for a default setup, but if I for whatever reason *don't* want revisions saved (does it matter why?) for a given node type, I should be able to make that happen without scheduling a block of time every Friday afternoon to go through and manually delete them, and I should be able to do it without dipping into contrib. That is a complete and total waste of my time.
nobody responded to my spattering of messages regarding the administrative interface that would allow you to designate this per each content type and set 2 optional criteria including the total number of criteria and the oldest date to keep to using 2 select boxes. The selections would of course also allow you to not keep revisions by saying "None". A "Revision History" field group in admin/content/types/$type with: Maximum number of previous revisions to keep: (Select Box with the following options: None, 1, 5, 10, 25, 100, Unlimited) Delete revisions older than: (Select Box with the following options: Never/None, Today, 1 Week, 1 Month, 1 Year) The valid concerns of both sides are resolved no? All without unnecessarily complicating the node creation form. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
Larry Garfield schrieb:
On Friday 08 June 2007, Derek Wright wrote:
I think we should always keep all revisions by default (even if we hide most of the UI to see/use them), and make site admins who think they want them off go out of their way to prune/disable them. The performance cost is negligible except for sites that care enough about performance to know their way around a few admin UI screens. The potential usability benefits of being able to say "oh yeah, just enable core's diff.module and grant some revision permissions to your editor role, and you'll be able to see all the changes anyone ever made to any of the nodes on your site".
-Derek
That may be fine for a default setup, but if I for whatever reason *don't* want revisions saved (does it matter why?) for a given node type, I should be able to make that happen without scheduling a block of time every Friday afternoon to go through and manually delete them
Cron does it for you. We'd just had to add a content-type specific setting "don't keep old revisions", and then cron could just delete all revisions that aren't active for these content types. No need to do anything manually.
and I should be able to do it without dipping into contrib. That is a complete and total waste of my time. See above. It could be one setting, as is now.
So, big +1 from me for requiring node revisions, as long as the UI stays simple (or becomes even simpler) for sites that don't want to care about revisions, and as long as there is an optional hook_cron implentation to discard old revisions, again for sites that don't want to care about revisions. -- frando
On Jun 7, 2007, at 7:42 AM, 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. ;-)
Not quite true... they're all about the UI, but different parts of it. "Fewer site administration options" is about the admin UI at admin/ content/types. However, the later suggestions for a UI to control automatic pruning of revisions cancels this improvement. "Cleaner node-editing pages for node administrators" is about the fact that everyone with administer nodes permissions always sees the revision-related UI. This, too, is nullified by the question of the "Log" text area, though that could potentially be solved by yet more options at admin/content/types. ;) "Less confusion over what checking the box does..." is a variation of the node-edit form simplification. However, there are different ways to make the UI cleaner, and I believe this motivation is a good one for just removing the choice from the UI entirely, instead of finding a more clear way to present it.
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.
Perhaps. However, I maintain that the Drupal taxonomy UI and functionality is vastly more complicated, confusing, and overkill for some sites than node revisions are. Yet, even though lots of people complain and shout, a huge percentage of sites end up using them eventually in some way. The taxonomy functionality remains a default part of core because we realize that it's so fundamentally handy, once people get over the learning curve and start using it, they wonder how they ever lived without it. I believe many "simple" sites, once they gain a little experience with node revision functionality, will embrace it.
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 ...
Agreed. That's why I believe the text area should be controlled by a set of 3 radios: 1) expanded, 2) collapsed, 3) hidden. It should default to hidden except for content types (and potentially a role- based and/or per-user setting) that are explicitly configured to have the fieldset present or expanded. Then, by removing the checkbox (we always make a new revision), we solve the problem of the 2 UI elements being separated, and then we can just focus on the single remaining UI element and make it as slick as we want.
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.
Exactly. Explicit version control is one thing, but just about everyone grasps the notion of "undo", especially when editing text. The more we can simplify the revisions UI while making it an integral part of the system, the better Drupal will be.
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.
These seem like different variations of the same. ;) We'll have a slightly more complicated content admin UI, in exchange for more simplicity conceptually, in the node add/edit UI, and in the code (since we remove all the update code paths on node save and everything is always an insert).
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).
I think all kinds of Drupal sites would benefit from always having revisions enabled by default. Site admins would have to go out of their way to either a) prune old revisions or b) harness more advanced aspects like log messages and roll-backs. Sites that *really* care about the performance impact of the extra rows in {node_revisions} either have a) tons of nodes, b) tons of users, and/ or c) tons of edits of existing content. Unless it's *only* c) and a small handful of users are so active on a tiny site that they create hundreds of thousands of rows in that table (highly unlikely), they're going to have to understand enough about tweaking the performance of their site and DB to be able to navigate a relatively simple admin UI for pruning old revisions.
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.
IMHO, those are the wrong questions. These are more appropriate: - How often have you wondered who and when was the last person to modify something? - How often do you wish you could have seen exactly what they changed? - How often do you wonder how frequently something is being changed? ... For myself, and probably a large majority of drupal.org users, the answer to these is "all the time".
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.
I agree. I think there are a bunch of revision-related UI improvements we could make. I'd be thrilled to help (and David seems to be off to a great start) cramming a bunch of them into D6.
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 ...
Again, it's not just about rollbacks. Otherwise, I agree.
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. ;-)
True. Perhaps a checkbox next to the log text area to indicate a minor edit is worth having. Maybe if it's checked, we always delete the existing revision and replace it with the new one being inserted. If it's already part of the advanced UI, maybe we want another checkbox like "Preserve existing log message" that auto- magically appears if you check the "Replace existing revision" checkbox or something.
* 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.
In addition to the problem of the update vs. insert hooks, developers are taught that the fundamental thing in Drupal is the node and the nid. Most Drupal tables have a nid column to JOIN on. For revisions to work, you need a vid column, too. For your module to work properly with revisions, you also have to consider core's {node_revisions} and vid, too, yet many developers apparently don't even know that body and title live there, not {node}. -Derek (dww) p.s. Yes, with proper caps, for all of you who always complain. ;)
On Jun 7, 2007, at 7:42 AM, Dries Buytaert wrote:
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. ;-)
This same thought led me to write http://drupal.org/node/50682 way back then (my, how quickly d.o generated another 100,000 nodes) about using a real revision control system for node revisions. ;) At the time, I was concerned with the inefficiency of storing entire copies of the nodes instead of just storing diffs like any sane revision system would (it was even worse in 4.6.x, since there was no separate table, just a giant serialized array of revisions directly in {node}). But, if we're going to go through the trouble to implement a powerful revision system that stores and operates on diffs, why reinvent the wheel? Wouldn't it be slick to have a php API for SVN that knew how to store things in any DB you wanted, not just Berkeley DB and flat files? (I don't know the state of the art with SVN's storage backends these days, though the front page of http:// subversion.tigris.org still only lists those 2 options). Then, you could just have all of SVN's power and functionality directly within the node revision system. Branching your handbook? Merging changes? Editing content off line? No problem. Talk about the uber publishing site solution... ;) -Derek
Requires an external tool, in this case SVN. It would be easy to implement if the current revision system would be an optional module (making part of core) but not required to be always "running". Anyway, revisions should be an option, not a requirement. Regards, Fernando On 6/8/07, Derek Wright <drupal@dwwright.net> wrote:
On Jun 7, 2007, at 7:42 AM, Dries Buytaert wrote:
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. ;-)
This same thought led me to write http://drupal.org/node/50682 way back then (my, how quickly d.o generated another 100,000 nodes) about using a real revision control system for node revisions. ;) At the time, I was concerned with the inefficiency of storing entire copies of the nodes instead of just storing diffs like any sane revision system would (it was even worse in 4.6.x, since there was no separate table, just a giant serialized array of revisions directly in {node}). But, if we're going to go through the trouble to implement a powerful revision system that stores and operates on diffs, why reinvent the wheel? Wouldn't it be slick to have a php API for SVN that knew how to store things in any DB you wanted, not just Berkeley DB and flat files? (I don't know the state of the art with SVN's storage backends these days, though the front page of http:// subversion.tigris.org still only lists those 2 options). Then, you could just have all of SVN's power and functionality directly within the node revision system. Branching your handbook? Merging changes? Editing content off line? No problem. Talk about the uber publishing site solution... ;)
-Derek
participants (25)
-
Chris Johnson -
David Metzler -
David Strauss -
Derek Wright -
Dries Buytaert -
Earnie Boyd -
Fernando Silva -
Frando (Franz Heinzmann) -
Frederik 'Freso' S. Olesen -
Greg Holsclaw -
Jim Li -
Jim Riggs -
Karthik -
Khalid Baheyeldin -
Larry Garfield -
Michael Favia -
Moshe Weitzman -
Nedjo Rogers -
Peter Wolanin -
Richard Morse -
Robert Douglass -
Stefan Nagtegaal -
Steven Peck -
Vivek Puri -
Vladimir Zlatanov