patch to fix bugs using ahah_helper in a CCK widget

From a brief test, the "save" button works fine, but the user is not redirected to the confirm delete page when clicking the delete button.

Do you use a particular CCK / AHAH Helper widget that you can post to standardize testing / reviewing?

Does this work in cck fields using form_after_build?

This patch changes the way form submits are processed with the #submit property.
#after_build shouldn't have anything to do with it.

I have used cck fields with ahah_helper, and it submits well without adding this patch..

I made a little module that allowed me to attach ahah behavior to CCK Widgets (like textfield and select), but I had to use #after_build in order to do that, because in the hook_form_alter those widgets aren't created yet.

That's what I meant.

@Cristhian,

I am about two work on a cck widget that I need it to have AHAH. I am about to start, read the docs, look at the demo and was about to start playing with it. If you can explain to me what you've done with your CCK widget and the #after_build, as well as, if possible, to share that module, that will help me a lot. If not just some hints of pointers would be great.

a.=

Cristhian:
Are you saying you do not have the issue reported here:
#513322: Not being redirected after node creation or edit
?

You must have built your own redirection functionality or otherwise manipulated the form_state in order to work around that bug...

This patch worked just fine for me. Thank you dsnopek.

@dsnopek Thanks very much for the patch.

@dsnopek Please if you have time can you explain to me why (in the patch #3):

function ahah_helper_real_submit($form, &$form_state) {

// i dont understand whyi need to unset $form_state['storage']

unset($form_state['storage']);

}

Im triying to understand it.

Thanks for your time .

@marthinal
He's most likely unsetting the form_state['storage'] to ensure the form will do the redirects. Deep in the form API there is a if statement when checks to see if form_state["storage"] is populated and if it is it will not do the form_state["redirect"] because it might mean it's a multi-step form.

This is just my best guess as I've had to manually clear the form_state["storage"] on my submit functions using AHAH helper

@gbernier :

Ok thanks for your explanation.It helped to me understand why .

Thanks for your time ;)

Thank you very much. This patch worked just fine ^^

This patch works for me on 6.x-2.1 as well. Thanks @dsnopek!

I tried modifying my module to use ahah_helper after applying this patch, but perhaps I'm doing something wrong. I'm working on a custom CCK module with multiple sub-fields, similar to my cck_fullname module. The difference this time is that one select field needs to control another.

Has anyone managed to create a multi-field CCK field module using AHAH_helper? Please share how you did it if so. I would imagine that some of the implications of CCK fields being on a node form apply, right? I have read most or all of the posts in this issue queue regarding that, trying several things with no luck.

What is happening now is that when I change the select, the target element disappears and is replaced with some dsm calls I am making for debug purposes.

The demo module creates a hidden submit field, which, since the 'first' submit button is called when a select is changed, gets fired off. In my case, I'm adding this button via form_alter. Is that not the right place? Do I need to give things some '#weight'?

Help!

I worked it all out. The only remaining issue I have is that when BOTH jQuery update AND core upload attachments are active for a given content type, the AHAH behavior doesn't work. Very strange. And that was very hard to figure out. But I have duplicated it on a clean site and had it confirmed by a third party. I'm not sure which module is to blame.

Since my needs actually don't include using both jQuery update and attachments AND changing the country all on one content type, I can live with this, but I'm sure if I release the module, people will have issues with that. But maybe with more eyes looking at it, someone will figure out what is wrong - although the issue may not be with my code at all, but with one of these other modules.

Committed thanks.