Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Any AHAH form (noticed while making new one), but double checked with previous ones, will fail when following these steps:
1. View form.
2. Use the ahah element that replaces part of form.
3. Submit form. (and receive validation errors)
4. Submit form again. (as if fixing errors)
5. Stare at the AHAH callback page with some nice JSON.
For some reason after step 3 the form action is set to the AHAH callback, and this was never done before 6.13 and below.
Comment | File | Size | Author |
---|---|---|---|
#58 | form_inc_ahah_validate_problem-591696-58.patch | 3.09 KB | iva2k |
#56 | form.inc_.ahah591696-1.patch | 956 bytes | iva2k |
#55 | form.inc_.ahah591696-1.patch | 956 bytes | iva2k |
#54 | form.inc_.ahah591696.patch | 956 bytes | iva2k |
#52 | form.inc_.ahah591696.patch | 856 bytes | iva2k |
Comments
Comment #1
boombatower CreditAttribution: boombatower commentedFor an example of this you can use any AHAH form that allows those steps (or even ahah_helper_demo).
Comment #2
boombatower CreditAttribution: boombatower commentedThe following reverts the changes to form.inc which fixes the issue.
Assuming it has something to do with rebuilding the form when menu item is AHAH callback and thus sets form action to that URL.
Thus I assume it is:
Comment #3
boombatower CreditAttribution: boombatower commentedI have confirmed my hunch. The patch fixes the issue.
Someone who is familiar with the change may want to double check the logic.
Comment #4
boombatower CreditAttribution: boombatower commentedIssue that made the change: #302240: button broken due to fix various problems when using form storage
Comment #5
grendzy CreditAttribution: grendzy commentedThat button issue caused some other problems, #587254: D 6.14 breaks multipage forms & #584536: Multipage forms are not working. Should this be marked as a duplicate?
Comment #6
RoelandG CreditAttribution: RoelandG commentedI tested this patch with a clean install of drupal 6.14, enabled the poll module and applied the patch.
Unfortunately the patch isn't working:
1. Fire an ajax request ("add another choise") while creating a new poll node with empty fields.
2. Receive form errors because no fields are filled with data.
3. Submit the main form
Now the action is changed to 'poll/js'. After the page is submitted again the page is logically redirect to this js callback path 'poll/js'.
Will try to figure out what is going wrong. Hope I find something and can submit a new solution.
Comment #7
stu1984 CreditAttribution: stu1984 commentedAm having this very problem with a form I am trying to create. Was not working in Drupal 6.14 so decided to move the form module I had made into a previous version of Drupal (6.12) and see if it would. Amazingly it worked fine with none of the issues I was previously having. As an experiment to see if I could recreate the error, I moved a copy of the form.inc file from my 6.14 includes into the 6.12 directory to see if boombatower's theory was correct. I found that the error reappeared straight away so there definitely was a problem with this file. Doing some file comparisons between the two versions of form.inc, I managed to track the problem down to the same lines of code as mentioned in post 2 above. The solution I found involved removing the NOT operator from form_get_errors(), so the line now reads:
if ((!empty($form_state['storage']) || !empty($form_state['rebuild'])) && !empty($form_state['submitted']) && form_get_errors()) {
However when I made these changes to the form.inc in my Drupal 6.14 directory, the problem remained. This makes me think that there is possibly another file in 6.14 that is also causing the same error. Does anyone else know which includes would be used when working with a form as I have not been using Drupal for that long so am not completely sure which includes would be used where? Hope this info helps someone diagnose this problem and find a solution.
Comment #8
sunMarking as duplicate of #302240: button broken due to fix various problems when using form storage
Comment #9
dsnopekReverting the patch from #302240: button broken due to fix various problems when using form storage in comment #13 or using the patch from this issue comment #3, doesn't fix the problem for me. I suspect this problem is unrelated to those changes.
Comment #10
dsnopekI just did the following procedure using Drupal 6.12, 6.13, 6.14, and 6.15:
Since this problem has existed in so many versions and since it is exhibited by a core module (ie. "Poll"), my feeling is that this is a problem that has always existed with AHAH in Drupal, and not something recently introduced.
It appears that it is the responsibility of the module author to handle $form['#action'] correctly. There is a patch to ahah_helper to do this automatically (#578252: $form["#action"] gets set to /ahah_helper/path (with patch to fix!) comment #3) to assist with this -- although, I haven't tried it yet. Even if the current patch doesn't work, it seems like trying to get some reusable helper code to handle the $form['#action'] problem is the right way to go.
Comment #11
tbazadaykin CreditAttribution: tbazadaykin commentedComment #12
micke_b CreditAttribution: micke_b commentedI had the same problem but found a fix that has been used for the ahah_helper module(same as above):
http://drupal.org/node/578252
The fix in Post #10 (http://drupal.org/files/issues/ahah_helper-form-action_0.patch) on that page solved this problem for me.
I just used the fix in my _form hook AFTER I turn on the cache:
....._form()
...code...
$form = array(
'#cache' => TRUE,
);
// FIX goes HERE
...code...
hope it helps
/Micke
Comment #13
pembeci CreditAttribution: pembeci commented#12 : Micke, which version of Drupal are you using? I tried what you suggested at 6.15 and it didn't work.
I don't think this is a duplicate of #302240: button broken due to fix various problems when using form storage . As dsnopek said, applying the last patch there or #3 here didn't help. Considering the latest comments, it seems we still don't have a general solution yet. So I am updating the status.
Comment #14
pembeci CreditAttribution: pembeci commentedForm workflow across page requests book page can help to track this problem. It explains what happens after an ahah call is made.
Comment #15
blackdog CreditAttribution: blackdog commentedThis still seems to be an issue with Drupal 6.16.
It doesn't appear every time, but when it first appears the form is broken, and you have to start over to submit it.
Scenario:
We've build a multistep form with some AHAH fields, and when abusing the form, to get errors, and then submitting again, JSON data is shown.
Comment #16
blackdog CreditAttribution: blackdog commentedThis still exists.
Flow:
Loads form, enters some values.
Loads more fields with AHAH.
Tries to submit, but validation throws errors (with form_set_error)
Fixes the error(s), hits Submit again, raw JSON data is outputted.
Small update:
It only seem to hit when the form errors is with the AHAH fields, not when other fields throws errors.
Comment #17
aaron CreditAttribution: aaron commentedsubscribe
Comment #18
sbefort CreditAttribution: sbefort commentedsubscribe
Comment #19
sbefort CreditAttribution: sbefort commentedAHAH is obviously not grown up. Cheers to writing the raw jQuery.
Comment #20
fizk CreditAttribution: fizk commentedPlease fix!
I don't understand how this goes unfixed for so long....so few people must be using AHAH.
Comment #21
GuyPaddock CreditAttribution: GuyPaddock commentedAlso having this issue...
Comment #22
jbourke CreditAttribution: jbourke commentedSubscribe - Having same exact issue.
Comment #23
codeglyph CreditAttribution: codeglyph commentedYes, i'm having this issue too... yet another bug in the freaking a-hah! implementation :(
One simple yet dirty workaround seems to be inserting the following code in your hook_form_alter() function
This resets the form action to current page. Would reflect on the page in a
<form action =" " >
form attribute. Wonder what inept browsers will do with that...Anyway this is not a long-term solution.
If you need more serious processing you can use some uri generation based on the form's #nid information. Like on this page:
http://www.netaustin.net/2009/01/26/dynamic-form-altering-using-ahah-rig...
Comment #24
Damien Tournoud CreditAttribution: Damien Tournoud commentedCannot reproduce in 7.x, so this only affects 6.x for some reason.
Comment #25
sunThis issue was definitely fixed in #302240: button broken due to fix various problems when using form storage for D7. The patch for D6 over there should have fixed this bug for D6, too. Not sure whether recent test reports here were actually against that latest D6 code, past March 2, 2010.
The last detailed test report seems to be #10, dates back to January 2010.
Comment #26
joep.hendrix CreditAttribution: joep.hendrix commentedThe problem still exists in D6.17
Comment #27
joep.hendrix CreditAttribution: joep.hendrix commented#23
That workes for me! Thanks!
Comment #28
noobee CreditAttribution: noobee commentedThank you so much for posting your patch.
I ran into EXACTLY this same issue, and it's been driving me bonkers. I figured it must be something like this, but don't know enough about the internal flow of forms to do anything about it.
Silly question: one applies a patch using "ed", or something else? It's been ages (maybe 15 years?) since I did one. (Started using Drupal recently, obviously.)
Thanks!
Comment #29
alpritt CreditAttribution: alpritt commentedHave confirmed this is still an issue with a fresh Drupal 6 HEAD, using the same test case as in #10.
Here's what is happening:
1. The AHAH enabled button is pressed, which requests the menu path 'poll/js'. The callback for that path is poll_choice_js().
2. poll_choice_js() contains this line:
$form = drupal_rebuild_form($form_id, $form_state, $args, $form_build_id);
When the form is rebuilt, the $form['#action'] is set to the current URI in system_elements() (an implementation of hook_elements()). Since the current path is now 'poll/js' that's what $form['#action'] gets set to.
3. The rebuilt form is saved to the cache.
4. The main form is submitted and the form is retrieved from the newly built cache complete with the now incorrect $form['#action'] value.
5. Since there is a validation error the form gets rendered and printed with the validation error message and the now incorrect form action.
5. The user submits the form. Since 'poll/js' is the form action poll_choice_js() is called which processes the POST data and returns JSON to the browser.
Comment #30
larowlanFor what it's worth this behaviour still occurs in Drupal 6.17 but can be avoided if you explicitly set an action on your forms.
Eg
If you leave it up to Drupal to set the action, you get the validation error/issue as described above.
Comment #31
mauritsl CreditAttribution: mauritsl commentedI can confirm that this is still an issue, even in 6.19.
The workaround in the last comment works fine, thanks for sharing.
Comment #32
DrupalCuckoo CreditAttribution: DrupalCuckoo commentedHi,
I'm using the core poll module to create poll nodes.
Where do I have to put this code?
Is a custom module with a hook_form_alter function needed?
What should be entered as path?
thanks for any help.
best regards.
Comment #33
DrupalCuckoo CreditAttribution: DrupalCuckoo commentedhi,
I've an answer to my own questions ;) This is what I did:
Since I already have a "helper module" where I collect all kind of different functions to manipulate drupal, I've added a hook_form_alter function:
I chose this way because ohterwise I'd have to alter the original module code and that's never a clean solution.
Would this be considered as a good solution?
Comment #34
chris.jichen CreditAttribution: chris.jichen commentedAlthough it is a hack, but I tried this, it actually works.
Thanks.
Comment #35
lizac CreditAttribution: lizac commentedHi! My problem is somewhat related to this but I can't just add more options to Drupal Poll. and I'm getting this error
http://drupal.org/node/630000#comment-3483566
Help, please! =(
Comment #36
larowlanHi
FYI it's not really a hack, the ahah js looks for the form action before doing the ahah request, after the request it restores the original action. If there's no action there, it can't do anything so this bug occurs.
Lee
Comment #37
jpstrikesback CreditAttribution: jpstrikesback commentedI found that after multiple AHAH "moments" & validates even after setting #action it could get lost a second time.
If anyone else experiences this the following patch for ahah helper get's around this issue:
see: http://drupal.org/node/578252#comment-2536114
like so:
Comment #38
gpeng CreditAttribution: gpeng commentedthis is still not working for me....
Comment #39
mmilano CreditAttribution: mmilano commentedcomment #30 fixed it for me. Thanks.
Comment #40
tom.pauwaert CreditAttribution: tom.pauwaert commentedsubscribed :)
Comment #41
asghar CreditAttribution: asghar commentedHi
Guys , I think it is more helpful link
Thanks
Comment #42
webchickSubscribing. This is still an issue in 6.x, with steps to reproduce in #29, and workaround in #30. But it would be nice if core didn't require special-casing here, as lots of people are repeatedly smacking into this wall.
http://jbenner.net/blog/prevent-ahah-the-right-way-from-breaking-with-va... (as mentioned before) contains a detailed analysis.
Thanks to deviantintegral for a pointer to both this issue and that blog post.
Comment #43
deviantintegral CreditAttribution: deviantintegral commentedSubscribing. poll.module is still broken in 6.x-dev.
Comment #44
davepoon CreditAttribution: davepoon commentedSubscribing.
Comment #45
anil_89 CreditAttribution: anil_89 commentedfunction get_zone() {
global $user;
$form_state = array('storage' => NULL, 'submitted' => FALSE);
$form_build_id = $_POST['form_build_id'];
// Get the form from the cache.
$form = form_get_cache($form_build_id, $form_state);
//$form['#parameters'][0]['action']= $form['#action'];
$args = $form['#parameters'];
$form_id = array_shift($args);
// We will run some of the submit handlers so we need to disable redirecting.
$form_state['post'] = $form['#post'] = $_POST;
$form['#programmed'] = $form['#redirect'] = FALSE;
// We need to process the form, prepare for that by setting a few internals
// variables.
$form['#post'] = $_POST;
$form['#programmed'] = FALSE;
$form['#submit'] = FALSE;
$form_state['post'] = $_POST;
$form_state['action'] = $form['#action']=FALSE;
$form = drupal_rebuild_form($form_id, $form_state, $args, $form_build_id);
// Render the new output.
if($user->uid){
$choice_form = $form['Contact']['profile_state'];
}else{
$choice_form = $form['account']['location']['profile_state'];
}
unset($choice_form['#prefix'], $choice_form['#suffix']); // Prevent duplicate wrappers.
$output = drupal_render($choice_form);
drupal_json(array('status' => false, 'data' => $output));
}
and ahah menu is
$items['zone/js'] = array(
'title' => 'Zone',
'page callback' => 'get_zone',
'access arguments' => array('access content'),
'type' => MENU_CALLBACK
);
please give idea how to i solve
Comment #46
jpstrikesback CreditAttribution: jpstrikesback commentedComment #47
dwigglesworth CreditAttribution: dwigglesworth commentedcomment #30 fixed it for me - thanks.
Comment #48
StefTM CreditAttribution: StefTM commentedWarning: Parameter 2 to webform_client_form() expected to be a reference .../includes/form.inc on line 366
It happened after migrating the website to a new webserver with PHP 5.3.
I had the same problem and after reading lots of comments and possible solutions, I just updated *everything* at the latest version (both manually and with the automated updates).
I also had to disable some old modules that were not compatible with my Drupal version.
Now all seems fine!
Comment #49
larowlanStefTM, your error is unrelated to this issue.
If your error persists, please create a new issue for webform tagged as PHP 5.3 Compatibility.
Comment #50
neels CreditAttribution: neels commentedhttp://api.drupal.org/api/drupal/modules--upload--upload.module/function...
I have a question: Is this possibly related to the upload module in that particular function? What #action would I put in to fix it?
Comment #51
yang_yi_cn CreditAttribution: yang_yi_cn commentedexperiencing this too! subscribing
Comment #52
iva2k CreditAttribution: iva2k commentedWow, I'm amazed how long it has been an issue (2 years!).
@Drupal core team, can you spend few minutes fixing it for good? You will close so many painful and lengthy bugs across so many modules.
I propose a 2-line fix that does the following:
1. stash form['#action'] into form_state[], best place seems to be drupal_process_form() as it is supposed to store what's worthy of preserving in form_state, and it is part of AHAH flow.
2. restore form['#action'] from form_state[] (if it has been stored but has not been set in the form) in drupal_rebuild_form() right before the call to drupal_prepare_form()
This will avoid auto-generated value of form['#action'] coming from system_elements()/request_uri() if the form had a cached version. It eliminates a need for any workarounds with fixed paths and workarounds in hook_form and ahah callbacks, however any such workarounds will continue to work.
Here's a patch that I tested on Drupal 6.22.
Please review and commit!
Comment #54
iva2k CreditAttribution: iva2k commentedI haven't done core patches yet. Don't have git checkout of Drupal tree, any hints of how to do it with diff? Retrying from drupal root directory.
Comment #55
iva2k CreditAttribution: iva2k commentedComment #56
iva2k CreditAttribution: iva2k commentedComment #58
iva2k CreditAttribution: iva2k commentedOk, got git and made git diff.
Comment #59
lifer CreditAttribution: lifer commentedAll hunks fail when I try to apply the #58 patch.
I have tried from root and from AHAH-folder.
Maybe I am using another Drupal (6.24) or AHAH (6.x-2.2) version?
I have tried applying the patch by careful manual editing the form.inc.
No errors (so I lean against the assumption that I did it correctly), but it didn't do the trick, although it might do it for some.
I then tried to follow the link/guide provided by #42 and it looks like that solves the problem:
Thanks!! :)
I wonder why there has been no AHAH module update with this (major) bug fixed - looking at the dates not even a dev-version!
Comment #60
czigor CreditAttribution: czigor commentedI can confirm #59 except that the patch applied cleanly to Drupal 6.26.
The patch in itself does not solve the problem, you need the
line in your ahah callback as stated in the link above.
Thanks iva2k and lifer!
Comment #61
iva2k CreditAttribution: iva2k commentedInteresting that the patch works for me without changing ahah callbacks. That is the whole idea of the patch - I've read the referenced post which gave me enough hints to understand what's going on and then I dug in and fixed it in core.
@czigor and @lifer
Your observation:
>The patch in itself does not solve the problem, you need the ... line in your ahah callback
perhaps applies to very different ahah sequence than the one I used as a test case. Can you post a step-by-step how you checked if patch solves the problem (including which ahah-enabled module to use)?
Comment #62
czigor CreditAttribution: czigor commentedI was testing a custom ahah form which is based on the examples module's autocheckboxes ahah form example. Your patch made it live one submission longer compared to the sequence in the issue summary. That is:
1. View form.
2. Use the ahah element that replaces part of form.
3. Submit form. (and receive validation errors)
4. Submit form again. (as if fixing errors)
5. Submit form again. <- without patch this step is skipped
6. Stare at the AHAH callback page with some nice JSON.
Comment #63
Fergie CreditAttribution: Fergie commentedThank you, codeglyph. That solved the problem.
Comment #64
anil_89 CreditAttribution: anil_89 commentedComment #65
fizk CreditAttribution: fizk commentedNot sure if any code has been committed to fix this issue.
Comment #66
rsharkey CreditAttribution: rsharkey commentedI am using Drupal 6.19 and #30 fixed my issue.
I placed this code at the top of my form function in my module:
Bear in mind that if you have already declared your "$form" array object in your form function, then this will be overwritten, since you are re-declaring the $form object. Even after placing this snippet at the top of the function, it did not work, since I had another declaration (further down the function) where I was declaring the $form object:
I just deleted this second piece and all worked as desired.
I hope this helps someone else out.
Thanks to #30 for pointing me in the correct direction.
Comment #67
petew CreditAttribution: petew commentedI couldn't find a general fix to this issue and it doesn't appear to have yet been fixed in core as yet, and I assume is unlikely to now. So in case it helps others...
I've only found fixes to solve the issue in specific situations, typically where you're creating your own form and are happy to hardcode the exact URL, but not a general fix to solve the problem. Apologies if someone has actually posted something that does this already and I somehow missed it. Plus i'm sure there's a few different ways to solve this issue.
In case it helps anyone, a simple general fix seems to be to create hook_form_alter in your own module, with the following code:
This approach simply stores the initial value, keeps that same value, and restores it in the form #action each time. (the #action value is initialised by the system module in its hook_elements for the form. We then just grab that on initial load and ensure the form keeps using it.)
Theoretically this should solve the problem for all forms, but no doubt there may be specific situations where this won't work, so YMMV.
Comment #69
apaderno