Wrong approach. Should save forms, not nodes - Proof of Concept

Create a cache table named 'cache_autosave'. hve your autosave functionality POST the form values to a custom handler, and cache the values in the cache_autosave table using the normal cache_set and cache_get functions. that *should* be enough to restore things for in-progress node edits.

This would be a great feature. Has anyone developed it? If not does anyone want to? Please email me.

Hey! I agree with this suggestion. And I agree with all the problems noted. This funcionality is a real must, as losing your form contents due to some timeout is an important usability problem, but having spurious nodes in your content list is another problem. Is the modle developed still there?

Hello people,

Sorry for neglecting this module for a long time; I've been caught up with other stuff and not paid enough attention to this module. I agree that autosave can be evolved to work with all other forms instead of just nodes.

I was thinking about it the other day, this is a draft idea I had:

1) User edits a form, let's say site information settings
2) Autosave interval passed; autosave function kicks in and serialize all form elements, including the form id, and relative path of the form and saves it to the database
3) If the user submits the form, the autosaved form data is removed
4) If not, let's say the browser crashes: the next time the user visits the site information settings page, autosave_form_alter will then check if the form_id exists in the autosaved table, and if the path matches, it will populate the form with the autosaved values. Or a message will pop up telling the user that the form was autosaved and asked if the user would like to view the autosaved form.

The relative path of the form was saved to ensure the correct autosaved form is identified lest the form is used in other pages as well e.g. CCK settings form for a text field.

If a form can have more than one autosaved form, then there should be a tab that would contain all these saved form for the user to revert to. Currently for nodes, it's done with revisions, where previous autosaved nodes can be reverted to.

I don't know; what do you all think?

Note: I can't do real coding until after Dec 14th, will have to deal with my final exams first. If anyone wants to submit a patch, go ahead :) Meanwhile, let's rattle off some ideas on how autosave should go about working with other forms.

Edmund

Edmund, I wish you a lot of success in your final exams.

Your plans for developing the autosave module sound very good to me.

Ditto on the good luck. & Thanks for working on this.

Would this approach based on form ID work with pathauto or the form ID has nothing to do with path?

And you suggest some idea of a form having more than one autosave. I think every user can hypothetically have one autosaved form of each form, but I don't see why one user should have more than one autosaved form. If someone stops editing a form, I don't see the point of storing this autosave.

What do you think?

Yeah, I think this approach really makes a lot more sense. I'd really like to use this module, but can not because of the validation issue. That and with the current method with a fast update interval the revisions just get out of control.

I really like the concept of having the option to use past auto-saved forms or not. And being able to keep multiple versions of past attempts. At first it seems a bit excessive (and maybe a feature that can wait) but our users may actually find that useful. They are submitting multiple copies of a very long form... having the ability to start one or two of them while then leaving to gather more info may actually come in handy.

More pressing tho for us is just the ability to have these saved in a manner that does not trigger validation (or taxonomy saves...). I think you are on the right track!

There's a few items more in my autosave features wishlist, if this new approach gets implemented.

1) If a user has some autosaved forms, the menu system would enable a page that lists all autosaved forms the user has.

2) Should anonymous users also have their forms autosaved with coockies?

3) An admin page would show

4) And a little usability gift: when the user loads an autosaved module, there will be a message warning him that an autosaved form has been loaded, the autosaved fields would be highlighted and there would be a button to discard the autosaved form and start the form again with the default values.

this sounds like great news and a great approach. let me know what I can do to help!

Very interesting, going to keep an eye on it.

Subscribing

Thanks for all your replies.

Good news people! I've managed to get out a proof of concept for saving forms and not just nodes. After patching Autosave HEAD, you will also need to install the jQuery Field Plug-in and stick it into the autosave folder as jquery.field.js. Unfortunately, the Field Plug-in does not work with the version of jQuery that comes with Drupal 5; thus, you will also need to install the jQuery Update module. Please make sure that the {autosaved_forms} table is created as well (if Drupal doesn't create it for you, obtain the necessary SQL queries from autosave.install).

As it's only a proof of concept, there are only minimal functions: there's no way yet to delete or view all previous autosaved forms. Autosave will trigger after x amount of seconds as configures in Administer -> Site configuration -> Autosave. Thereafter, on page that contains a previously autosaved form, the user will be notified and given the choice to view the autosaved forms or ignore it. Ignoring the previously autosaved forms would mean that subsequent autosaves will overwrite the previously autosaved forms. The autosaved forms will also not be deleted after the form is saved successfully.

Take it out for a spin first, but please, not on production sites (but I think it shouldn't mess up anything; it might just be irritating as autosave will popup for every single form in Drupal!). I'll work on the rest of the features (eg page to view all autosaved forms, multiple autosave forms, removal of autosave forms after submission, etc). It should work with nodes forms, cck field settings, views, and all other forms.

Edmund

(P/S I borrowed some css from l10n_client module for the autosave status messages bar.)

I hope someone knows how to patch to test it. I have no idea, so I will have to wait until some release is made.

You can give this page a read: Applying patches

OR

Unzip the attached zip file to your modules folder :)

I tried but there are too many undefined dependencies. I will wait until someone with more knowledge tests. Good luck. I keep following this thread.

hey there Edmund and Happy New Year :)

i was so excited to see some progress on this that I gave it a try today by downloading the zip archive you provided as well as the jquery field plugin. I also had to manually add the DB table as the install hook did not work when i installed/enabled the module.

However, after enabling AutoSave and setting the timer config, when I go to create / edit a node I get the following javascript error:

Drupal.settings.form_id.replace is not a function
autosave.js (line 27)

which is the line:
form_id = Drupal.settings['form_id'].replace(/_/g, '-');

We are running the latest version of Jquery Update.

Any ideas? thanks!

Hey Brian, Happy New Year to you too :)

Thanks for taking time to test the new feature. I think the bug has something to do with having more than one form in the page. I'm guessing you have the search form as well in the create/edit node page? A quick fix would be as follows:

In autosave.module around line 59

Replace:

With:

Hope this works :) We'll think about how to implement autosave with more than one form in a page once more people agrees that this new approach is fine..

Edmund

Hey again -

Thanks for your suggestion. Unfortunately it seems i have 4 different forms on my node create page, one for the node type, search_theme_form (unused), search_block_form, and devel_switch_user. So what I did was at the beginning of autosave_form_alter was specify my node type form and place the remaining code within that if {} block.

Once I got the error to go away I saw the oh-so-awesome proof of concept you've put together -- it looks great! I LOVE the way the autosave div fades in at the bottom of the window and fades out after a few seconds. Very well done and nicely unobtrusive. I'd love to hear more about your thoughts on how the View/Ignore will be implemented and how a user will be able to revert to a previous autosave that hasn't been officially submitted (i.e., if their browser crashes or connection goes down).

Based on the above form_id issue, what might be nice is something like the following to be able to specify which node form and type to apply AutoSave:

Just a suggestion of course! I realize this limits Autosave to node types' add/edit forms but I'm not sure this is a bad thing.

thanks again!
brian

Good that it's working for you :) Btw, the View/Ignore that you see on a previously autosaved page is already implemented. Did you manage to get that working?

Hmm, regarding the option to specify which form can be autosaved, that will definitely be one of the functions but will not be limited to node forms only. I am also thinking about allowing autosave to happen for certain pages only; just like how blocks display settings are configured.

I think it's safe to say that search_theme_form, search_block_form, and devel_switch_user does not need to be autosaved. But are there other pages that requires more than one form to save?

the view/ignore links see to just move the focus to the top of the page. I don't see any content getting replaced. what's supposed to happen?

well there are couple of more devel forms and any other form a user puts in the left block, so i wonder if we can do it theough a wilcard.

Well, just as a quick note. User login form shouldn't be autosaved :)

I know this is a Proof of Concept and its a very good one, I really think this will be a great module once it gets out of the Proof of Concept stage.

As I was testing the module just to see if there was anything I could see that seemed like it needed and I found that currently only the default values and on CCK created forms is not saving the form id. Unfortunately at this time I don't know enough about Ajax to quick fix it on my system and keep testing.

All in all though this is a great module and so far even the Proof of Concept is awesome.

Glad to see forward movement here!

It's looking good, but I also wasn't able to get it to work. Seems like everything I don't want saved saves and everything I do doesn't :). For instance, I cant get it to save any data for any new nodes. The message at the bottom of the screen (which is cool :) ) says "Form autosaved", but it didn't actually save it. I do see an entry for the page in the DB, but I do not see any serialized data or Form ID.

If you would like to witness it not working go here:
http://cakwak.com/autosavetest/?q=node/add/page (admin/admin)
That's a completely 100% fresh 5.3 install; with only the modules from comment #12 installed.

Here is a dump of autosaved_forms:

Notice that there is no form_id or serialized data for entry #2. So clearly it won't reload. However, even the others that appeared to serialize and save my changes don't work. I get the message saying there is saved data, but can't reload it. Try out ?q=admin/build/modules to see that.

Additionally... the above was all tested in FireFox. It doesn't appear to do anything in IE (tested in 6.0). In IE it just says "Error on Page" in the JS console.

Also, I know you mentioned it so it's probably already on the plate, but let me just emphasize that it would be *really* helpful if I could set the pages or content types that autosave. It'd be awully annoying if it saves every form on every page.

Lastly, I really like the message at the bottom telling me that its autosaving, because it's nice and discrete. However, I feel it's a bit too discrete to use it as the prompt to ask the user if they would like to use or discard a previously saved form. I think that should jump out at the user-- maybe even a pop up in the middle of the page. Anyone agree/disagree?

Great Work!!!

Thanks for all the testing people!

I've created a new 5.x-2.x branch and committed the early changes as well as some new ones. These includes:

- Node forms will also be autosaved now. There were problems before this because Drupal internal form_id was different from the rendered form id (all node forms are internal form_id as 'node_form'; the rendered ones are eg story_node_form, page_node_form). This should fix the problem that was observed by bbenone and jdevoid.
- Correctly sets elements with square brackets in their name. CCK uses this alot, for example, field_name[key]. I had to tweak the jQuery Field plugin to achieve this; so please use the jquery.field.js file that should be in the dev snapshot. This should fix the problem that was observed by bbenone and jdevoid.
- Pages with more than two forms will be saved correctly. Still haven't fully figured out the interface; for now, inspired by gmail's rss ticker :) This requires the autosaved_forms table to be recreated as there are changes in the primary key and field max length.
- Added a proof of concept autosave configuration settings interface. Not finalized though, need feedback :) To see it in action, browse to any page with form(s) and append /configure-autosave to the url. For example, admin/content/taxonomy/add/vocabulary/configure-autosave

Next in my list is to get a less fancy but working autosave configuration form. I'm thinking it could be like how blocks does it for 'Page specific visibility settings'.

@bbenone
Good point that notifying users about an autosaved version of the form exists should be more obvious. But didn't want it to be too obtrusive as well? Let's get more opinions on this.

Please wait for the snapshot to be generated or view the CVS repository if you can't wait ;). Also, please file subsequent bug reports in a separate thread; makes it easier to track stuff :). We'll keep this thread for concepts and discussion about the new method. Meanwhile, I need some sleep.

Edmund

Just coming back after going through this thread last night and i confirm that formid and serialized were not getting saved. Very glad to hear you have sorted out the issues with this. I'll d/l from cvs and start testing now.

Did you possibly include brian's per node type selection code in your form alter? (btw - Brian and i work together).

Great work Edmund. :)

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

First crack at CVS code and i all i get is tons of JS errors of the following:

ret[ret.length - 1] has no properties

will hopefully debug later this evening.

Was focused on getting autosave work on pages with more than one form and I neglected to test it for pages with only one form. The attached patch should do the trick :)

Pulled your latest JS from cvs (i.e. includes the patch above) but still only get:

- JS errors occurring at around 1 / sec.
- no entry written to table
- no popup, etc

Earlier today (prior to new JS) i did get a time when i could see entries being added to the table - but it was sporadic.

I'll start going through this in more detail tomorrow to see if can see what the issue is.

You still getting the 'ret[ret.length - 1] has no properties' error? I encountered the same error once or twice; can't seem to replicate it consistently though. After upgrading jQuery 1.2.1, the error disappeared though. But, can't say for certain if that's the fix.

What version of jQuery are you using and which browser? Alright, debug it fully tomorrow then :)

yes, same error..

we are using 1.1.2 for jquery - i would like to upgrade to 1.2 but it isn't compatible with core yet (it mostly works but breaks a few things, plus there is a jquib module but makes jq over 200k, plus a new patch to make it work.. will likely try that at some point).

I'll try the quick 1.2 test (i.e. just slap it in for now even though it breaks some core JS functions) just to see if this helps. If that does it i'll look more into a proper solution for 1.2 (which i want to get to anyway).

Haven't gotten too far on this yet - still trying to sort out what version of jqeury to be using - pretty sure their is no jquery 1.2 solution for Drupal 5 at the moment so not sure what you are using - possibly just dropping jquery 1.2 in /misc over core jqeury.js? This may help this module out but will break other js functions in drupal core.

Working on this today though so hopefully will get somewhere.

finally a little headway with this - once i removed all the [0] indexes on the values which are actually strings from autosave.js (e.g. Drupal.settings['form_id'][i], Drupal.settings['q'][0], etc and took out the loop for each form in Drupal.autosave the autosave is now working.

NOTE - i have only one form on my page that i am interested in saving (which i would guess is the typical case but not generic case). I guess with multiple forms these would be arrays and this might have worked - i'll go back and investigate the more generic 1 or more forms case after the 1 form case is working better.

So, now that i have something working for 1 form case i see these issues:

- title isn't being saved
- i havent tried complex cck forms just yet; only testing with simple Page type so will test this is a bit
- the popup that you are presented with when you come back to a form that has autosaved content has VIEW and IGNORE - i think IGNORE does the right thing; and VIEW does show the saved copy - but from their you get RESET and IGNORE:

RESET - goes back to previous popup (VIEW/IGNORE)
IGNORE - goes back to saved node (i.e. not autosaved form) and then restarts the autosaving process

BUT - there is no button to ACCEPT the autosaved version and start from that location.

ok, well i guess this is a bit better problem to have - the title is actually being saved but:

- if when coming back to a node edit you select VIEW (view saved form) and then IGNORE (go back to saved node) the autosave function popups begin working again - but nothing is actually being saved - this was confusing me to thinking that the title changes weren't being saved when actually nothing is.

more info on #33 - the failure to start working again after VIEW -> IGNORE is only on FF. It works fine in IE7

Based on our communication via email, ptalindstrom has got this working. I have committed a few fixes; from the CVS log:

* autosave.js - Autosave status div should be added regardless whether there are previous autosaved forms or not.
* autosave.module - Serialized form_id as well; if not, form_id will be blank after previous autosaved forms are viewed and ignored.

Thanks Peter for testing and debugging this!

Autosave should also work with jQuery 1.1.2. Still need more people to test the new version though..

Edmund

Hmm... I'm not having much luck here.

I downloaded autosave.js, autosave.module and jquery.field.js from CVS and applied to my old code.

Checkout:
http://cakwak.com/autosavetest/?q=node/add/page (admin/admin)

In Firefox, the autosave info bar just keeps rapidly coming and coming. I have the delay set to 12 secs, but it is clearly not waiting that long. Additionally, it doesn't appear to be actually saving anything.

In IE (both 6 and 7) I get the following JS error:
Line: 15
Char: 5
Error: 'Drupal.settings.form_id[...]' is null or not an object

Also, fyi, it appears to be trying to autosave the login block.... that probably shouldn't happen...

Double check if the {autosaved_forms} table is also updated; the primary keys are now form_id, path, and uid.

If that's done, please also try applying ptalindstrom's changes in #32 in removing the [0] indexes from the code. If that works for you, I'll add a check to make sure the Drupal.settings variables is an array before using indexes, as suggested by ptalindstrom.

I also have not managed to test it out on IE. ie4osx is abit sluggish on my MacBook. Will get hold of a Windows machine to test it.

Thanks,
Edmund

Ok, looks good.

The keys were wrong on that table as you thought, so I dropped and re-added it with the create stmt from the install file.

I also had to edit the JS file to remove all the [0]'s in the first couple of functions, and to drop the loop in .saveFrom and the [i] inside of it. For anyone else following, you can grab my JS file here:
http://cakwak.com/autosavetest/modules/autosave/autosave.js

This still only works in FireFox. The error in IE is now even less helpful:
Line: 137
Char: 9
Error: Unknown runtime error
Code: 0

Now that I have seen it working w/ something simple I'll get it applied on our dev server with many much more complicated forms. *fingers crossed*...

I don't want to derail Edmund's work here and i strongly believe that we need to head towards a "complete" version of this module. That being said i thought i should post my current solution since a few people are having issues here.

I think these are differences between CVS latest with any patches that may be here and the version in attached ZIP file:

- can select which node types have their forms autosaved
- only works with single form (i think cvs rev only works with multilpe forms and i think will fail with only a single form - someone needs to combine these 2 approaches to make JS generic - but i don't have the time right now to do this).
- i have added a KEEP "button" that allows you to keep the autosaved and continue working form there.

Pretty sure this works with:

- IE7/FF
- jquery 1.1.2 or greater
- complex cck forms (my test form is pretty complex)

But at the moment DOESN'T work with TinyMCE - I am working on this today.

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

Nice approach!

I think that the ui needs some work. While the bottom "slide up" is great for notifying the user that the node has been autosaved, when the user returns to the node/add page it would be clearer to show a pop up right in the middle of the screen or something more obvious to ensure that the user sees and understands what is happening. A nice option would be to have a text area on the settings page that will let the admin provide some text for the pop up.

Hey guys... I have been swamped with "real" work lately, so had to backburner playing with this. I should have time over the weekend though. Any progress from anyone in the last week or so? I notice that the 2.x branch hasn't received any recent updates. What's the word on integrating some of Peter's features/fixes from post 39 into CVS?

We have some very complex forms on our end too, with lots of add-on widgets, ajax stuff, etc. So I'll try it out with them and report back. I'm gonna use the CVS version (w/ patches from comment 32) first. I'll probably try Peter's version from comment 39 as well.

Let me know if anyone has anything new you want me to try out while I'm at it...

make sure to check this post out for my latest changes to autosave: http://drupal.org/node/207902

subscribe

i should add that if all you need is alist of forms that should be 'autosave_enabled', you could consider depending on the form store module. it was written by the head of security team - is solid.

subscribe

Any progress on this module lately? Its looking good, but still needs a lot of work.

For anyone following the thread, I posted the bugs I found from the 2.x-dev branch here:
http://drupal.org/node/218557

I have also looked into ptalindstrom's latest version but was unable to get it to save. I suspect I am missing something simple. Waiting for feedback here:
http://drupal.org/node/207902#comment-719459

I replied on the other issue you posted. As far as i know "my" version of this module works great. We use it on a large documentation system everyday.

It is difficult to properly do updates however since this module is a significant branch from Edmunds original branch. Not sure how to properly support this (not that i really have the time) without CVS version being brought closer to this.

That being said, the version in my ZIP file on other post (my rev 0.3) works pretty well; but i have done a couple improvements in the past day or so:

- properly clean up asave table for the node/add case (node/edit case already works)
- now remove on submit ALL edit cases for a node (not just the user's) - this prevents issues with:

- user1 asaves but doesnt commit
- user2 edits and does submit (used to just delete user2's asave entry but now do user1's as well)
- user1 comes back to edit - but user2's version is now in place and doing submit would give "content has been modified error"

i'd like to post patch for these new edits.. but, again.. not sure i should be patching on my zip.. and i wont patch on existing cvs since too far out of date.

i'll post new zip later this evening.

Any progress in this thread?

as far as i know the only progress required is if Edmund decides to merge my "branch" in to the official version of this module. The version i have posted (zip file) works well and i dont know of any outstanding issues with it. We us it actively on a documentation system owned by the NY Times and have not seen any issues since my latest release.

Any new developments on this?

what "developments" were you hoping for? The module works great (my ZIP file version of it).

I think Edmund may no longer be supporting this module so not sure how to get my version as the CVS version and then people can start raising tickets against that version (as i think it is much more complete solution that Edmund's last checkins).

I think i was hoping that since a lot of people use this module that perhaps someone else would pitch in and sort out gettting my changes added to CVS. Since that doesnt seem to be happening - i'll email Edmund and see what he wants to do.

Thanks. I hope you will be able to get your code into CVS. If I understand this thread correctly then your code worked only on pages with only one form. Is that limitation still there?

yes, mine only works on a single form.

I have the code commented out that Edmund had in place to do multiple forms but not sure it was working for him either - which is likely why i commented it out. Possibly not too much work to get it going - but i don't have the time or the need.

I guess is someone (you??) can confirm that the latest CVS version does work to some degree with multiple forms then i would likely NOT replace it with my version in CVS. Although there are many other features/fixes which are in my version which are not in the CVS version.

would seem to be a dilemma.. but i doubt CVS version properly supports multi-forms which makes my version a better starting point - and without it being in CVS it is difficult for someone else to fix the m-form issue.

You could simply put your code into a different branch in CVS (perhaps DRUPAL-5--3) and make a separate release for it (5.x-2.x-dev). When people file bug reports they can then specify which version it applies to. Hopefully someone else with some knowledge of javascript (I unfortunately lack that) can have a look at providing multiple-form support for your code.

Tes, please, create a new version, due to the big changes in internals.

Edmund has given me cvs access to this project - so i will try to get to adding my version of this module as a new 5.3 release sometime this week... but, i am crazy busy and not a huge fan of cvs (SVN Rocks!!)

if someone wanted to step up and help out a bit it would be greatly appreciated. We would get edmund to add them as a cvs user (or maybe i can do that) and then i could just email my latest and they could commit to cvs :)

just a thought, failing that.. i'll try to get to it this week.. no promises

The same problem:

If you have a NEW issue, please post it as a new issue. I am closing this issue as the autosave module has saved forms rather than nodes for almost a year now.

Also, you'll need more info than what you have posted here for anyone to be able to help you out.