<br>This would make sense if all configurations allowed all users to access to the revisions tab. They don't. <br><br>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?
<br><br>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 (<a href="http://lists.drupal.org/pipermail/development/2007-June/024474.html">
http://lists.drupal.org/pipermail/development/2007-June/024474.html</a>) and visual clutter of revision noise (<a href="http://lists.drupal.org/pipermail/development/2007-June/024508.html">http://lists.drupal.org/pipermail/development/2007-June/024508.html
</a>). I think the "keep 0 revisions" option makes sense as long as it keep the interface simple. <br><br>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.
<br><br>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.
<br><br>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.<br>
<br>Again, I think this is a great idea and just want to understand how it would work in these situations.<br><br>- Kevin Reynen<br><br><br><div><span class="gmail_quote">On 6/7/07, <b class="gmail_sendername">Angela Byron
</b> <<a href="mailto:drupal-devel@webchick.net">drupal-devel@webchick.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On 7-Jun-07, at 3:47 PM, Karthik wrote:<br><br>> On 08/06/07, David Strauss <<a href="mailto:david@fourkitchens.com">david@fourkitchens.com</a>> wrote:<br>>> With clever use of revisions, we could eliminate the preview system
<br>>> entirely from the codebase.<br>>><br>>> Here's how it would work. If a user clicks Preview, it creates a new<br>>> revision but does not mark it as the current revision. The preview<br>>> seen
<br>>> is the new revision rendered. If a user clicks Save, it creates a new<br>>> revision *and* marks it as the live one. Optionally, we could then<br>>> delete the interim preview revisions.<br>>>
<br>>> Another advantage to this is that a user can work on a node,<br>>> preview it,<br>>> and have their work saved. If a user comes back and edits the node<br>>> with<br>>> unsaved previews, they can choose to work from the latest preview
<br>>> or the<br>>> latest public revision.<br>><br>> Excellent idea. IIRC, a similar approach was taken for a "save draft"<br>> (automatically) patch which was proposed a while back. While most of
<br>> the emphasis was on "private drafts", the idea of "public drafts" is<br>> particularly ... juicy.<br><br>There might be code in revision_moderation module that could be re-<br>used for this. Or it might be some gigantic hack. ;) Anyway, that
<br>lets you leave the existing node contents pubilshed while new<br>revisions exist.<br><br>Previews as revisions sounds like a nice solution to the draft<br>problem, imo.<br>-Angie<br><br></blockquote></div><br>