Closed (fixed)
Project:
Autosave
Version:
6.x-2.9
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
11 Jul 2010 at 14:22 UTC
Updated:
25 Jul 2012 at 18:41 UTC
Jump to comment: Most recent file
Hello,
I point this here as it seems to be the best place to warn people, even if the bug is more on the strongarm side...
If you have both modules (Autosave and Strongarm) enabled, Autosave will behave erroneously : it will save the node each time it wants to save your progression. Which can lead to a lot of consequences. For example, in my case : every 15 seconds, my node was saved as is (even the "post to twitter" checkbox), and posted on twitter.
This produced many many posts on Twitter (and also many, many nodes), linking to my preproduction site ( :-( ).
Well, I don't have any solution to this problem, other than disabling one module or the other.
For those who want to have a look at it, I suggest you start with Strongarm's hook_init (which calls drupal_init_path() ).
Regards,
David
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | autosave_strongarm_fix.patch | 2.79 KB | quicksketch |
| #8 | autosave_strongarm_fix.patch | 0 bytes | quicksketch |
| #5 | autosave-q.patch | 1.57 KB | aaronbauman |
Comments
Comment #1
aaronbaumanI confirmed this issue with the symptoms described in #855172: When adding a node, creates a new node on each autosave instead of caching the add form
Comment #2
aaronbaumanFollowing up on David's assessment:
strongarm_init overrides $_GET['q'], which is used by drupal core to determine which menu handler to invoke.
Since 'q' was set in the autosave's ajax POST, strongarm assigns $_GET['q'] to the node form's URL. Therefore, the menu system hands the request to node.module instead of autosave's menu handler.
There are two possible solutions:
1. change autosave's ajax POST to not use the special "q" variable
2. change strongarm_init to not override $_GET['q']
Comment #3
aaronbaumanNot sure where is the best place to document this, so I cross-posted this issue to Strongarm issue queue.
#855338: Overriding $_GET['q'] in strongarm_init causes problems when $_POST['q'] is set
Comment #4
aaronbaumanHere's where 'q' gets set in the post array
from line 73 of autosave.js:
the variable "serialized" gets passed to $.ajax as the POST data.
Comment #5
aaronbaumanI *think* this patch would resolve this issue (untested), however I tend to agree with liquidcms that the bug is actually in Strongarm.
Comment #6
galaxor commentedHere is the patch made against autosave 2.9. I actually didn't notice this bug, so I re-created this patch myself, from first principles (in #1362858: Does not work when strongarm is present). When I compared it with yours, I discovered that it was basically identical, except that I had called the variable autosave_q instead of autosave_path.
My point is, since I came to exactly the same conclusion as you, and it worked for me, I'm going to call this RTBC.
Comment #7
Crell commentedThere is no patch on #6.
I am also not giving the D6 version of autosave much attention, as I never worked on it and have no Drupal 6 sites that use it... or that I'm even maintaining at this point. :-) My life is all Drupal 7.
Comment #8
quicksketchThanks guys, the code changed slightly and required that a change be made to the autosave_save_access() function also, but after updating that last instance of $_POST['q'], everything worked great.
Comment #9
quicksketchHere's the correct patch.