This would make sense if all configurations allowed all users to access to the revisions tab. They don't. Assume I'm a user without revision/edit access and I add something, preview it, and don't save it. How would I get to it? I'm following the other thread David started about requiring revisions as well as the legitimate concerns about giving everyone access to revisions... like the ability to review PHP ( http://lists.drupal.org/pipermail/development/2007-June/024474.html) and visual clutter of revision noise ( http://lists.drupal.org/pipermail/development/2007-June/024508.html). I think the "keep 0 revisions" option makes sense as long as it keep the interface simple. I don't want to have a revisions tab if for whatever reason, I'm not saving revisions. If I opt not to keep revisions in my db, it seems like saving preview as a revisions is going to create an interface issue. I like the simplicity of this for site editors to get back to work in progress, I'm just concerned that saving previewed content for users who can't access revisions would get really confusing. Right now, unsaved content that requires a preview isn't saved and can't be recovered. If users learn they can contact an admin to recover posts they never committed, they will. I don't like the idea of a user working on post, working on post, going to lunch, forgetting to save, calling me to recover their work. Another issue that comes to mind is Captcha. Right now I only require Captcha on save. I don't like the idea of spambots being able to commit inserts to my databases or requiring Captcha on every preview. Again, I think this is a great idea and just want to understand how it would work in these situations. - Kevin Reynen On 6/7/07, Angela Byron <drupal-devel@webchick.net> wrote:

On 7-Jun-07, at 3:47 PM, Karthik wrote:

...

On 08/06/07, David Strauss <david@fourkitchens.com> wrote:

...

With clever use of revisions, we could eliminate the preview system entirely from the codebase.

Here's how it would work. If a user clicks Preview, it creates a new revision but does not mark it as the current revision. The preview seen is the new revision rendered. If a user clicks Save, it creates a new revision *and* marks it as the live one. Optionally, we could then delete the interim preview revisions.

Another advantage to this is that a user can work on a node, preview it, and have their work saved. If a user comes back and edits the node with unsaved previews, they can choose to work from the latest preview or the latest public revision.

Excellent idea. IIRC, a similar approach was taken for a "save draft" (automatically) patch which was proposed a while back. While most of the emphasis was on "private drafts", the idea of "public drafts" is particularly ... juicy.

There might be code in revision_moderation module that could be re- used for this. Or it might be some gigantic hack. ;) Anyway, that lets you leave the existing node contents pubilshed while new revisions exist.

Previews as revisions sounds like a nice solution to the draft problem, imo. -Angie

The "view own revisions" option works for sites that have a revisions tab, but how does a user get to the "view own revisions" of a node that was previewed, but not saved? I think the captcha workflow can be modified to work with preview as revision, but it's just one of many modules that will likely have to be modified. Others modules I'm guessing the preview as an actual insert might impact include pathauto, automatic node titles, akismet, subscription, and notify. Again... I'm not saying this shouldn't happen, but it shouldn't get be given a great idea/+1 without thinking through the UI issues as well as the impact it is going to have on popular modules. - Kevin Reynen On 6/7/07, Frederik 'Freso' S. Olesen <freso.dk@gmail.com> wrote:

2007/6/7, Kevin Reynen <kreynen@gmail.com>:

...

Assume I'm a user without revision/edit access and I add something, preview it, and don't save it. How would I get to it?

In the thread you reference yourself, I believe it was suggested to have a "view own revisions" permission, partly to deal with the issue of entering private-data-in-PHP-code, but it would also 'fix' this issue.

...

Another issue that comes to mind is Captcha. Right now I only require Captcha on save. I don't like the idea of spambots being able to commit inserts to my databases or requiring Captcha on every preview.

Perhaps only requiring captcha once and then store it in the session information? Or require captcha the first time one edits a page and stays at the page[1]?

[1] Ie., if I go and edit page #1 I have to pass a captcha for the first preview, but the second preview and the final submission doesn't require anything. I then go to page #2 where I have to pass a captcha again entering the 1st preview, but then I go to page #1 to check something, and upon returning to page #2, I have to re-pass the captcha for the next preview/submit. -- Frederik 'Freso' S. Olesen <http://freso.dk/>

On Friday 08 June 2007 10:04, Peter Wolanin wrote:

AFAIK, node insertion is a pretty expensive operation - it seems to me that executing this on every node preview would be a performance drag.

Not only that, but I have visions of a database full of trivial or even identical node revisions. For example, what if the user changes only the taxonomy selections and then previews the node? All those DB queries and extra data in the table, for nothing. Or they change a bit of HTML formatting and preview, trying several times to get it just right. The user may have only worked for a couple of minutes, so what's the value in preserving all those revisions? Backups have value only if the archived data takes less time to restore than to recreate from scratch. I'm not violently against this idea, but neither am I convinced of its real value. Count me as a "- 1/2" based on what I've read so far on this thread. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/

On Jun 8, 2007, at 16:34 , Morbus Iff wrote:

...

Not only that, but I have visions of a database full of trivial or even identical node revisions. For example, what if the user changes only the taxonomy selections and then previews the node? All those DB queries and extra data in the table, for nothing. Or they change a bit of HTML formatting and preview, trying several times to get it just right. The user may have only worked for a couple of minutes, so what's the value in preserving all those

This is pretty much the way I work - I could easily spend 30 previews before I finish what I consider my first draft of a node. I would hate to waste 30 revisions (and the overhead) for stuff like that.

That's why it was suggested to automatically delete revisions that were used for previews. Not that it would become elegant code, but that would at least get rid of the overhead. Wim

That's why it was suggested to automatically delete revisions that were used for previews. Not that it would become elegant code, but that would at least get rid of the overhead.

It doesn't get rid of the overhead... just the makes the database look cleaner. A JOIN happens between node and node_revisions any time the body of the node is displayed regardless of how many revisions you save. The suggested solution is to allow for "keep x revisions" setting. Setting x to 0 would give users a "clean" database, but it doesn't change the fact that inserts are happening where they haven't happened before. Inserting previews is more overhead than not inserting them, but any single insert or update is not enough to be concerned about. There are few people as concerned about Drupal's performance as David Strauss, so I don't think he's ever going to recommend a change that slows Drupal down. David makes the case (pretty compelling IMHO) that most big systems, modern applications, and operating systems are including revisions by default and that this change would simplify the Drupal code base. The discussions about using revisions by default and changing preview to be a saved revision are really separate discussions. There is still a difference between preview and save. You can preview 30 times and decide not to save any of those changes. All of the changes wouldn't have to be saved. In the case of previews, I'm assuming that the default would be to update the active "preview" revision and not keep every change. One of my concern has been orphaned previews. Not because they would clutter the db, but because if the exist and only an admin could get to them it would create an additional support responsibility I don't want. For me to +1 preview as a revision, the UI has to be self serve and developers maintaining popular modules that would be impacted have to be on board. - Kevin Reynen

...

This is pretty much the way I work - I could easily spend 30 previews before I finish what I consider my first draft of a node. I would hate to waste 30 revisions (and the overhead) for stuff

That's why it was suggested to automatically delete revisions that were used for previews. Not that it would become elegant code, but that would at least get rid of the overhead.

How does that reduce the overhead, or keep the revision counter from ballooning ridiculously? I'm still "wasting" the revisions, whether they're active or not. -- Morbus Iff ( i still fail to see what this has to do with morocco ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

Is preview int per user? You start a preview, but don't commit it and I want to modify that node... Am I informed that the node is being edited? Can I see the edit? If I can edit it regardless of another user's unsaved preview, is that preview deleted? "If so, find the latest revision where preview = 1 and replace its contents with the current post's contents." Is that per user or will my edit overwrite your preview? "user comes back after browser crashes:" How does a non admin user get "back" to node that has been previewed (and thus saved to the db) but never published if they don't know the nid? This is my "self serve" UI issue. Anyone how has dealt with a user who wants to recover autosaved versions of a Word doc that they never saved knows that this is possible, but a pain. Users have to be able to get back to their work in progress on there own. I see a solution alerting users to a unsaved preview when editing existing nodes, but how do you get to a node that has been previewed but never saved? I'm thinking about forums where a new users will occasionally preview their posts, but never realize there is another step to submit them. Now they are just gone. This change will leave them in the db, but I'm not sure that's an improvement if I'm the only person who can recover that post. - Kevin On 6/8/07, Angela Byron <drupal-devel@webchick.net> wrote:

On 8-Jun-07, at 12:21 PM, Morbus Iff wrote:

...

...

...

This is pretty much the way I work - I could easily spend 30 previews before I finish what I consider my first draft of a node. I would hate to waste 30 revisions (and the overhead) for stuff That's why it was suggested to automatically delete revisions that were used for previews. Not that it would become elegant code, but that would at least get rid of the overhead.

How does that reduce the overhead, or keep the revision counter from ballooning ridiculously? I'm still "wasting" the revisions, whether they're active or not.

Proposal: new field in node_revisions: preview int 1 all nodes default to status = 0.

When preview is clicked... - Does a node id exist for this post yet? - If so, find the latest revision where preview = 1 and replace its contents with the current post's contents. Also store the node ID in a cookie value, so if the browser crashes, we can get back here. - If not, create a new revision and mark it preview = 1;

When submit is clicked... - Create a new "normal" revision (preview = 0). - Publish the node (workflow settings permitting) - Delete preview revision if it exists. - Delete node ID cookie value.

hook_cron - Delete all preview = 1 revisions where updated >= variable_get ('preview_threshold', 86400);

user comes back after browser crashes: - Drupal checks for existence of node ID cookie value, does a drupal_goto() to the node "would you like to finish editing this?" Since users can see unpublished nodes as long as they've authored them, they'd be able to further edit the content.

-Angie

Morbus Iff wrote:

...

Not only that, but I have visions of a database full of trivial or even identical node revisions. For example, what if the user changes only the taxonomy selections and then previews the node? All those DB queries and extra data in the table, for nothing. Or they change a bit of HTML formatting and preview, trying several times to get it just right. The user may have only worked for a couple of minutes, so what's the value in preserving all those

This is pretty much the way I work - I could easily spend 30 previews before I finish what I consider my first draft of a node. I would hate to waste 30 revisions (and the overhead) for stuff like that.

Likewise, I tend to think this is a semantic breakdown - when I "preview" something, I am doing so because I want to see what WILL happen IF I saved/the data. The revised change breaks this meaning, making it more a "save and re-edit" button, not "preview".

The problem is that the current system is *almost* but not quite giving you what you will see when you save the node. It's difficult to give accurate previews. By running previews on the same system as revisions, previews will be 100% accurate and require no additional work to provide. Another way we could structure previews accurately without the DB overhead of using revisions is to separate the node edit form submission from what changes in $node. Basically, submitting the form (for preview or saving) would call the function to apply the form submission to $node. How it would work: 1. User submits node edit form. 2. The content type provider receives the submitted form values and applies them to $node. 3. The normal rendering happens on $node. Right now (and I may be mistaken for Drupal 6), elements on the node edit form get directly added to $node. When a preview is happening, the preview is built off this edit-form-modified $node, which often has a different data representation than $node really uses. So, the preview is put in the awkward position of interpreting the form and displaying the data.

This is, in fact, how Drupal 6 works. :) Modules that need to shuffle their form data around before it can be considered a valid node object add a #submit handler to the node edit form. That code is called by both the preview and submit buttons when clicked, and results in a 'fully formed' node object when preview is clicked. Basically, exactly what you outlined in your step-by-step process. The only thing that wouldn't work is modules that add extra database information *after* the node is completely inserted into the DB, based on the nid, and then display it later. Frankly, I'm not too worried about that; creating loads of one-off dummy nodes just because someone typed a few lines and hit 'preview' strikes me as a very heavy solution for a problem that I'm not yet sure is a problem. I think the idea of drafts has some merit but I'm unhappy with the idea of using the revision system for them. Drafts, if anything, should be an explicit workflow state; revisions are an optional construct that exists separately from workflow. --Jeff On Jun 8, 2007, at 12:11 PM, David Strauss wrote:

The problem is that the current system is *almost* but not quite giving you what you will see when you save the node. It's difficult to give accurate previews. By running previews on the same system as revisions, previews will be 100% accurate and require no additional work to provide.

Another way we could structure previews accurately without the DB overhead of using revisions is to separate the node edit form submission from what changes in $node. Basically, submitting the form (for preview or saving) would call the function to apply the form submission to $node.

How it would work: 1. User submits node edit form. 2. The content type provider receives the submitted form values and applies them to $node. 3. The normal rendering happens on $node.

Right now (and I may be mistaken for Drupal 6), elements on the node edit form get directly added to $node. When a preview is happening, the preview is built off this edit-form-modified $node, which often has a different data representation than $node really uses. So, the preview is put in the awkward position of interpreting the form and displaying the data.

On Jun 9, 2007, at 2:05 PM, David Strauss wrote:

Jeff Eaton wrote:

...

This is, in fact, how Drupal 6 works. :) Modules that need to shuffle their form data around before it can be considered a valid node object add a #submit handler to the node edit form. That code is called by both the preview and submit buttons when clicked, and results in a 'fully formed' node object when preview is clicked.

What happens if multiple modules need to shuffle the form date into $node? Is there a way to chain #submit events?

form #submit can have 0-n handlers, so any number of modules can modify the data; enforcing particular call order would involve the same weighting issues that any view, safe, etc hook requires.

The problem with treating drafts as purely a workflow state is that drafts, ideally, should be able to co-exist with the published node. Having two coexistent versions of a node requires using revisions.

That seems like it makes sense, but I would say that having drafts in addition to a published nodes doesn't *require* revisioning, it *is* revisioning. Each version can have a workflow state -- draft being one of them. I just disagree with treating them as the same problem -- versioning won't solve our workflow needs, nor will workflow solve our versioning needs. They're complimentary but different. I might have come in at the wrong time on a discussion I don't fully understand -- it's possible I'm just repeating what everyone else is saying. ;) -Jeff

Both issues could be addresses by a cron-generated purge on saved previews older than a given time limit, like 1 hour. That way, neither abandoned previews nor spam would create "permanent" junk. ----- Original Message ----- From: "Dries Buytaert" <dries.buytaert@gmail.com> To: <development@drupal.org> Sent: Saturday, June 09, 2007 11:48 PM Subject: Re: [development] Use revisions to replace previews

[...] I don't finish everything that I start writing so every once in a while, I abandon the post in which case the previews and the node ID would still be in the database? That said, I'm not opposed to an auto-save feature or a 'Save as draft' feature. Except that it should somehow align better with my mental model.

Something else to consider -- spammers will often try to submit spam to your site. Even if they don't make it through, they might insert permanent junk in your database.

-- Dries Buytaert :: http://www.buytaert.net/

Actually, I don't think that changes anything: every new preview would just update the timestamp while it saves the latest edit. And the time limit could just as well be 1 full day. ----- Original Message ----- From: "Larry Garfield" <larry@garfieldtech.com> To: <development@drupal.org> Sent: Sunday, June 10, 2007 6:09 PM Subject: Re: [development] Use revisions to replace previews

I can easily take several hours on some posts or comments. Yes, I should be writing those in another program and copying them in. No, I don't usually do that. :-) I don't think I'm alone in doing so.

On Sunday 10 June 2007, FGM wrote:

...

Both issues could be addresses by a cron-generated purge on saved previews older than a given time limit, like 1 hour. That way, neither abandoned previews nor spam would create "permanent" junk.

[...]