Multigroup fields no longer saving; error in content_multigroup.node_form.inc on line 369.

This seems to happen to me and I have preview disabled via the preview module.

However, I do not believe this is a problem with the preview button.

Looking at the content multigroup module file: content_multigroup.node_form.inc, specifically the function:
<?php function content_multigroup_node_form_validate($form, &$form_state) { ?>

Looking specifically at these lines:

<?php
if (is_array($form_state['values'][$field_name])){
      foreach ($form_state['values'][$field_name] as $delta => $item) {
?>

I added a watchdog to see what is going on.
It seems that $form_state['values'][$field_name] does not exist.
This seems wrong, based on watchdog data, the field name field data gets stored here:
$form_state['values'][$group_name][0][$field_name]

Then looking at the foreach line, it seems to follow that the delta would be referring to the 0 and so I would guess the code should look like:

<?php
if (is_array($form_state['values'][$group_name])){
      foreach ($form_state['values'][$group_name] as $delta => $item) {
?>

This does not solve the problem but looks more correct.
The problem is, I am not certain what this function is trying to do to even know if this is really correct.
What I do know is that $form_state['values'][$field_name] does not exist so $form_state['values'][$group_name][0][$field_name] is more likely correct.

I can see, based on watchdogs that the text i filled into the form still exists, so the validate function is either the place where the data vanishes or the validate is called before the place where the data vanishes.

I would assume the actual save function is where the problem exists.

I am guessing the next function based on the order shown here: http://drupal.org/node/101746

Perhaps I am looking at the wrong place, but I cannot find any relevant _submit(), _insert(), or update() functions.

Where is the data being inserted?
Or could the problem be that the appropriate insert button does not exist!?

I have rewritten this post to up date it to my latest discoveries.

I originally thought that the #3 issue was a CCK-3 issue, and the bug for some time did not reproduce itself in CCK-2.
I was wrong about this.

On a fresh system, #3 does not happen, but on a well-used system #3 does happen..

I have tried disabling all modules and re-enabling them one at a time with no luck, just like the original bug reporter.

I decided to copy the missing data over manually for the cases where this does happen:

The following code was added:

<?php
      // FIXME: why is this happening?
      // $form_state['values'][$field_name] ends up missing sometimes and $form_state['values'][$group_name][0][$field_name] contains the actual data
      // This is a hack/temporary-fix such that whenever this situation happens, the data ends up where it should be
      //
      if (!array_key_exists($field_name, $form_state['values'])){
        foreach ($form_state['values'][$group_name] as $delta => $item) {
          if (is_numeric($delta)){
            $form_state['values'][$field_name][$delta] = $form_state['values'][$group_name][$delta][$field_name];
          }
        }
      }
?>

The is_numeric($delta) function was added to because only the numeric fields are relevant fields to be copied. All other fields are invalid.

When this is done, saving and loading of data in multigroups works.

This, however, introduces a regression (maybe?) for the cases where fields are required.
For fields copied in this way, the removed state is not present so when trying to remove a required field, a "field is required" error is thrown when it should not be.

I found and fixed the regression in #4:

<?php
      // FIXME: why is this happening?
      // $form_state['values'][$field_name] ends up missing sometimes and $form_state['values'][$group_name][0][$field_name] contains the actual data
      // This is a hack/temporary-fix such that whenever this situation happens, the data ends up where it should be
      //
      if (!array_key_exists($field_name, $form_state['values'])){
        foreach ($form_state['values'][$group_name] as $delta => $item) {
          if (is_numeric($delta) && is_array($form_state['values'][$group_name][$delta]) && array_key_exists('_remove', $form_state['values'][$group_name][$delta])){
            // In the case where '_remove' is set to 1 (TRUE), then the field is to be removed.
            // Do not bother copying removed fields and they will be auto-deleted from the form and the database!
            if (!$form_state['values'][$group_name][$delta]['_remove']){
              $form_state['values'][$field_name][$delta] = $form_state['values'][$group_name][$delta][$field_name];
            }
          }
        }
      }
?>

The patch is attached.

Applying the patch in #5 makes the node savable but the content multigroup values are set to empty. Each time I select a value and then save, it saves successfully but the values are reset to null or empty.

I found that the form submit I have has an error because I changed it to onsubmit="return false;" as I didnt want the form to submit directly. Submit will be done through javascript. anyway I fixed this but still there is a major error which is, the second group doesn't save values at all. anyway I will open a new issue for this problem.

the patch at #5 works for me

What I really need here is some way to reproduce the problem. In all my tests, the fields are where they belong and this patch is not needed. I need a way to create a situation where they are not where they belong so I can fix the source.

This patch got into the nested fieldgroup patch and I want to remove it, so I need to dig into this issue.

Actually, I'm going to remove that patch to force this error out into the open so we can figure out exactly how to reproduce it.

That patch has been removed so we can figure out how/if the problem is still occurring in the latest code. If it is, it may be specific to the type of field. I need exact details about the kind of fields you have that aren't behaving. You can export the fields using Content Copy so I can see exactly how they are configured.

So is anyone still seeing this problem? I am absolutely unable to replicate any problem in the latest code.

I do not think I have seen this bug in the latest code.

I need to review that I did not habitually apply my workaround.
Once I confirm that I did not apply my work-around, I will edit out these two lines.

subscribing

I had a similar problem when doing a custom theme for my form printing the multigroup field like
print drupal_render($form['group_name']);
but the patch in #5 solved my problem.

I have been having this issue as well. It seems to have been caused by placing the multigroup in a field group...

To try to replicate it I would put the multigroup in a normal field and then make one of the multigroup fields required.

Ok, replicated it on two clean installs now. Here is the weird behavior: content type has normal fieldset, in fieldset is a multigroup, in the multigroup is a user ref, date, and option widget. Date is required. Fill in two multigroups, save, add another, don't fill in required field, try to save, save failed, delete the multigroup I tried to add, save, then I get this:

And then when I go to edit it's like this

Then I delete the evil zombie multigroup (attached image) and get this again
https://img.skitch.com/20110512-18i8ufqahj46yg1uidb59wniyw.png

the zombie lives...

I had not applied the patch and had no problems until I removed a field from a multigroup. Now I get this error constantly. I've created new multigroups, moved them in and out of traditional groups and added and removed fields (required and non required) and I can't find any rhyme or reason to what caused this error to appear now.

The patch does seem to make the error go away however.

Hmm I was also overriding the node.tpl.php on this form. When I stopped doing this it worked again. All I was doing was changing the 'save' button to be labeled as 'submit' and then print drupal_render($form)

This is the offending line, taking this out of the template file makes everything work fine. No idea why this matters.

$form['buttons']['submit']['#value'] = t("Submit");

The patch in 5 does not fix this error in some of my multigroups it seems. Digging through the db and code I can't figure this one out. Incidentally if I use the same code in my template override but change the name to Save it works fine. i.e.

$form['buttons']['submit']['#value'] = t("Save"); <---Works
$form['buttons']['submit']['#value'] = t("Submit"); <--- •warning: Invalid argument supplied for foreach() in /www/work/sites/all/modules/cck/modules/content_multigroup/content_multigroup.node_form.inc on line 412 (412 is where the old code gets pushed down to after the application of the patch in 5. It was line 396 in the current cck-6.x-3.dev

This might be a duplicate of #1281450: Clicking custom submit/button form element causes error in multiselect validation. Can anyone confirm this?

I know if a button name is changed outside of the theme layer, then things start to get weird. It's always better to override a theme function for the button if possible. Wish I had more info but I don't have time to dig into this right now.

I was getting this error as well. The problem is that there can be multiple submit inputs and each submission is evaluated based on the value. Therefore changing the value of the submit input is not an option.

<input type="submit" name="op" id="edit-submit" value="Save Changes"  class="form-submit" />
<input type="submit" name="op" id="edit-preview" value="Preview"  class="form-submit" />

I came up with a work around. First, create a block that only displays when a specific node type is created or edited. Place the block below the content. Then copy the following code into the block. The style hides the original button thereby saving the integrity of the original form. Then a new button is added with the adjusted text. Upon onclick the new button will submit the form via the original save button. If anyone is interested I can modify the code the the jQuery equivalent.

<style type="text/css" media="all">
  #edit-submit {display: none;}
</style>
<input type="button" value='Submit Request' onclick="javascript: document.getElementById('edit-submit').click(); return false;" />