Save and Preview buttons are set wrong when saved form is loaded
| Project: | Autosave |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Recreate:
1. Start creating new content for a node type with autosave turned on.
2. Wait for the autosave handler to save the form.
3. Reload the page.
4. In the status message which reads "This form was autosaved...", click View.
The Save and Preview buttons will now read: "Save,Preview" and "Save,Preview".
This is because Drupal's #node-form has two submit buttons named "op", and .formHash() returns { ..., op: "Save,Preview", ...}. When this is reloaded the buttons are both set to "Save,Preview".
My question is where is the correct place to correct this? Should it be in the form markup? Or should autosave simply ignore the values in the submit buttons?
I propose something like this:
autosaved_form = $('#node-form').formHash();
delete autosaved_form.serialized.op;This will leave alone the values for the form elements which are named 'op'.
#1
I noticed this issue also.
#2
Yes looking into this issue, since i noticed it also. Also certain pieces need to be removed from the hash also like the form token.
#3
Added the capability to decide what you wish to not serialize in the autosave form. This is an administration function for the module and the administrator can provide a list seperated by "|" in order to determine the form fields that they do not wish to save.
The attached patches are against the d6-x-dev version.
#4
The patch above should fix this issue.
#5
This needs review and committing before it goes to the 'fixed' state :)
#6
thx
#7
I've applied this patch manually, but it's still not working or I missed something.
Can somebody upload the full patched gzip's, then I can test it.
#8
See also #372254: Only working on Title and Body fields? .
#9
Here is the 1.1 version of the module, with the patches in #3 applied (by hand, since they don't apply out of the box to this version); otherwise it is untouched, but tested and proven to be working fine for now.
Anyway, I'm interested in a release with the above fixes.
#10
this patch doesn't work for me. See description of my problem here http://drupal.org/node/372254#comment-1629136