[development] Use revisions to replace previews

[Kevin Reynen]

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 at webchick.net> wrote:
>
>
> On 7-Jun-07, at 3:47 PM, Karthik wrote:
>
> > On 08/06/07, David Strauss <david at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070607/98c3b447/attachment-0001.htm