Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Save draft comments (with configurable autosave)

edited May 2008 in Vanilla 1.0 Help
I'm sure that this has happened to all of us at least once, so...

I guess this really begs for a new "autosave" extension for Vanilla that saves the contents of the comment box to a cookie (?) every 30 (?) seconds. Then you could have a "load comment from autosave" button near the "big input" button currently?

When you post successfully the cookie could be cleared, otherwise it could just store the info and automatically load it up into the comment box when you go to a discussion.

If security is an issue with saving to cookies, what abut encrypting it before saving? Is there a better idea than cookies? Actually the next bit kinda begs for something different...

If there was a "save draft comment" button that you could manually press, this would be pretty cool as well — and then maybe an area for your "comment drafts"... feature creep anyone?

I'm sure this is a complete swine of an extension to make, but it would be pretty cool.


  • Maybe we could use WP's autosave function for posts.
  • There is a old clipboard extension that saves snippets of text, it would be better realized as managing drafts....

    boy, searching for it here found me recommending it three times for this function. Now, where did I put it?
  • edited August 2007
    It certainly has a lot of potential. I use a browser that has a lot of bugs, (I live on the edge - beta test browsers) so having comments save periodically would save me a lot of hassle.

    1. Have a simple naming structure for cookies like CommentSave-21 (where 21 is the discussion ID) and DiscussionSave-2 (where the number is incremental for each discussion draft).
    2. Some crude encryption
    3. Auto saves every 30 of seconds
    4. "Save draft" button
    5. Disable per user, per role, and globally
    6. If there is a draft available for a discussion it adds a button to the bottom of the input form, or something saying "Load draft" which fills in the input when clicked (similar with a new discussion, but it will offer a list, like "Load draft 1, Load draft 2" maybe (or just one draft, to keep things simple)
    7. Destroys draft if you make a post to a discussion
    8. The cookies for the drafts have an expiry (day, two days?)
    9. Ability to forceably remove all drafts
    Anything else do you think?

    Perhaps drafts of new discussions should be saved differently, to the database perhaps? (but auto save to a cookie? ugh, dunno).

  • StashStash
    edited August 2007
    I like that list Adam, that pretty much covers it. The reason I suggested autosave to cookie was to prevent server load.

    From point six above, if there is a saved comment, perhaps the comment box should just autoload the draft? That means only one draft, but it would be simple as hell ;) There could perhaps be a red warning box just above the comment box, something like...

    A draft was found for this discussion and has been automatically loaded into the comment box below.
    You can start editing or adding to the comment and post it as usual.
    Alternatively, you can:

    P.S. three and eight should be admin (user?) configurable and done with JS — again to prevent server load.
  • edited August 2007
    If you save the drafts on the client side, you will have to prevent DOM based XSS. You will have to clean up the user input on the client side.

    Also, if you use cookies, all drafts will be sent to the server and back to the client on each load; that will more bandwidth consumption and slower load. Flash can be used instead. Without special user permission, you can store 100k on the user computer I heard.
  • I didn't realise that about cookies - ok, scrap the cookies idea, sounds like it sucks! Would it be faster to pull stuff from the database on each load than cookies though?

    Not sure I like the idea of using Flash like that, but it's certainly worth a look I guess...
  • We are not vulnerable to such attacks should we filter content prior to output (using the inbuilt Vanilla functions which strip malicious tags), surely? We are not going to just take raw data and dump it to the screen.

    I still feel that cookies are the logical way to go, they are there for storing data unique to the client for a finite period in time. That is exactly what we intend to do, store data for the client, until they no longer need it.

    Other ways to reduce load on the server could be, only storing data when it becomes X amount bigger than it was the last time it were checked (this could be checked in javascript), only store data if there has been a new fullstop (or comma) character added since it were last checked (could probably also be checked in js), only store if a new line break is added (js again). Endless possibilities.

  • If "load draft" take some content from a cookie to inject it in the comment textarea, the content of the cookie will have to be filtered. The cookies can be filtered on the server side on each load, with an ajax call to filter a specific cookie or with JavaScript.

    The cookie is a good idea especially if it is only a temporary storage and that on each load the draft(s) is/are saved in the database (and the cookie unset). If you want to do everything on the client side, try to find a way to not send the drafts to the server (using Flash, using the path parameter of the cookie and an iframe, Dojo storage...). For a first version, you could just not bother and see if it is really a problem.
  • I had no intention of sending to the server on save, to be honest... just using an AJAX call, doing a crude encryption and dumping to a cookie. It then goes through the server if one is being loaded, and the appropriate calls get made to clean up the content incase malicious script is being injected. No flash/iFrames required.

    Anyways, this extension isn't going to be started by me for some time - I have too much on to do it at the moment, though I can see myself picking it up in the future if development hasn't begun.

  • yeah... comment drafts like GMAIL does it!
  • The formatter should take care of the XSS filtering (like Html Formatter, BBCodeParser, Markdown etc) no?
  • edited September 2007
    yep, the cookie would need to be filtered on each load of a page that could use them, or before injecting the content to the comment area with an ajax request.
  • edited September 2007
    I trust DokuWiki's code a lot, and there is an autosave function. Maybe there are some good ideas...
  • klipklip New
    edited December 2007
    yeah! this happened to me after a hour long struggle composing a nice comment in a language not native to me and then I accidentally changed focus from textarea to a whole page and pressed backspace! It went back in a history and destroyed my wonderful kind of you-will-never-write-this-again-in-such-a-brilliant-way comment

    I would like to use this extension for sure so I'm putting it into my todo list and if nobody is going to develope this until I reach that todo line, I'll do it myself.
  • In that case, we look forward to seeing something from you! :D
  • @Stash

    well, have you seen my todo list already? :p it's on my account page :) SaveDraft is #7 :) #1, #2 and #3 are not far from finish :)
  • Esperanto? Brila!

    I look forward to #8, I've been using pluginstalled with some success in WordPress, and would love to see something similar for Vanilla. It's got some "wonderful" quirks, hopefully yours won't!
  • ** bump ... this feature is needed!

    Also see here.
  • yeah it does seem pretty cool
  • This feature would be a really valuable addition to a Vanilla forum!

    A possibility for the dirty work would be to save it as a comment, but remove that such comment from all views. (I was looking at the code for PreModeration, and it looks like that's exactly what it does.) That would guarantee compatibility with addons like Attachments2.
This discussion has been closed.