Multigroup module breaks with Multistep

It is the multistep module that is using CCK apis to do its job, therefore it needs to take into account that not all fieldgroup are of 'standard' type, so it should probably ignore multigroups or adjust its code to support multigroups. There may be more type of fieldgroups, as this is part of the fieldgroup module implementation, and not all may work with multistep.

Please, check descriptions of issue attributes before changing them. "Needs review" means there's a patch for review. "Assigned" means that person is going to work on the issue.

Postponing until there's a step by step procedure to reproduce the issue to proof there's something wrong in CCK, or multigroup, or there's a patch for review.

I see, but I think the problem is that the multigroup module task to deal with all possible kind of fields in node edit form is pretty complex, it uses different kinds of FAPI related callbacks to do its job. So if another module tries to alter this, it needs to know what it is doing very well. Otherwise, chances are that multigroup module breaks, which is what's happening here.

Someone needs to debug both modules to see where the problem is. Maybe it is just a matter of module weights, or maybe it is a FAPI cache issue, or maybe it is that multigroup module needs to assume the form is not altered after all the job it does with all those FAPI related callbacks, or maybe the multistep module is failing to build data the multigroup module needs. Who knows. Unfortunately, I do not have the time to look at Multistep module.

Not really sure what you mean. Remove the #ahah callback from where? Note that this is required for the 'Add more items' button to work with AHAH. Otherwise, the button will send the whole form, meaning page refresh, no AJAX.

Also, I should have asked this at first: what do you mean by "Multigroup module breaks with Multistep", "disables the working of CCK multigroup module"? I read #5, but this is still unclear. When you say "add a node of the same content-type (and test the multigroup. specifically press-'Add more values' on the multigroup)", what do you mean? What happens next? Do you see an error? What happens when the button is clicked?

I'm asking because as I said, I don't have the time to test both modules, but that doesn't mean we cannot think about it.

Safari reports the following message on the JS console:

XHR finished loading: "http://[my staging site]/content_multigroup/js_add_more/[Content type]/[fieldgroup name]".

This, combined with mesh's assertion (which I've tested and found true) that "Add More" works on the first and only first page of the multistep form makes me wonder if the problem could be as simple as the name of (or path to) the content type.

In a multistep form, node/xxx/edit/ is the same as node/xxx/edit/1. If one way or another you try find that fieldgroup inside node/xxx/edit/1 when it's really in node/xxx/edit/2, you'll get nothing. As I mentioned in the other thread, "Add More Values" successfully creates a new row, but it is empty.

Unfortunately, I'm stumped so far as to how to redress this issue, but maybe it will be helpful to someone else?

Is it legit for me to change status from "Postponed (maintainer needs more info)" if I'm providing more info? I'm going to try it and seek forgiveness if it is not.

No problem. In fact, the hardest part in issue like this is finding out what really happens.

Maybe it is related to form state and form caching issues? Note that the AHAH callback of the "Add more items" button needs to rebuild the form, but uses FAPI cache to keep its own state. Maybe this is broken when using Multistep and the form is not on first page.

The "Add more items" button provided by Multigroup module is mostly coded like the "Add more values" button of multiple value fields. Do the later work with Multistep? That may give as a hint.

Oops. How did I miss this?

I pushed "Add more items" and the entire field disappeared. That can't be good.

I have to do more testing of this. The install I just tested has other modules installed, but I'll go and try to reproduce this from a clean install.

BTW, from where I'm sitting, "Add another item" is what I see with the multiple value fields. "Add more values" is the button for the Multigroup. Not nitpicking, but I figure I should mention when what I'm seeing isn't consistent with what the person who is trying to help me describes.

OK here we go:

Stock 6.14 install.
Multistep 6.x-1.3 2009-Jul-24
CCK 6.x-3.x-dev 2007/07/04 23:46:29

Enabled: content, content_multigroup, fieldgroup, multistep, text + the defaults from core.

Theme is Garland.

I've created a content type Multi Test with two standard groups and two multigroups. I've enabled multistep and assigned a standard group and a multigroup to each of two steps in the form. Each one of these groups contains one text field. The anonymous user has permission to add content to this type.

This test setup is located at http://devel.splicer.com/

The result: on page one, both the multigroup and the field with the "regular" multi-value field work correctly.

On page two, the regular multi-value field disappears when "Add another item" is pushed.

In the multigroup on page two, the first field remains when "Add more values" is pushed and a new row is created with the "draggable" arrow and the "delete" button, but no field or header in the new row.

Anonymous user has permission to edit content of the type "Multi Test" so if you go look at it you can edit an existing node or create a new one. It's up to you.

Edit to add: please let me know if you would like me to remove any of the default optional core modules or make any other changes.

Ok, so this is not just related to multigroup, but something related to AHAH stuff used by multiple value fields in content module too. I'm changing the version and component attributes of this issue for this reason. Also, I'm removing the assigned attribute because this is used to flag who is going to work to resolve the issue (http://drupal.org/node/314328).

Also, I'm changing the issue status because it is not clear this is a bug in CCK. These buttons work in CCK, and it is the Multistep module that changes the normal flow CCK expects things to work.

I appreciate the efforts in trying to provide more information, really, but honestly, this is not enough. Now we can only see what's broken, but still we have no idea why, or what needs to be fixed in CCK. And I'm really sorry because Multistep looks a nice addition, but I do not have the time to debug Multistep module to find ut what's really happening.

Someone needs to debug what happens with the form status when Multistep is not in the first page, and that means looking into FAPI and also into AHAH callbacks in CCK.

In other words, if the fault was inside FAPI, you would have to open an issue to the Drupal queue, but Drupal maintainers would need to know exactly what needs to be fixed and why. So I see this issue like this. It is the job of the Multistep module maintainers analyze the problem and then request a fix wherever it needs to be filed, but that issue needs to carry what needs to be fixed and why.

So this is "postponed (maintainer needs more info)", and probably "won't fix" unless we know what needs to be fixed in CCK exactly.

In fact, forms can be cached and that information can be used to rebuild the form between several pages. But that's based on FAPI features. This is something that needs to be investigated by Multistep module maintainers, IMHO.

PS: Please, do a full page refresh to keep the issue status as-is. ;-)

Marking as duplicate of #579126: Multistep module breaks multi-valued fields.

The problem was, in fact, how Multistep handled getting the current step. It's now fixed in the latest development snapshot of Multistep.