Flexi-field does not work with multiple flexifields

I'm trying to fix this myself. Have you had any success so far?

Did anyone try Flexifield with CCK 3.x experimental branch ? I read in CCK 3.x there are something like "add row" and "remove row" buttons added.

Same problem appart that I get 4 Flexifields to be filed up by default. It is impossible to get ride of the extra field groups if I need less than 4 value sets.
As no solution was provided to date, this is definitely a bug, which is critical as this does not allow to use this module in production.

Hint: the number of flexifield occurences in the submission form is equal to the number of fields in the group.

I changed the title accordingly

subscribing

No reaction? This should be easy to fix now.
This bug is really critical: I don't think anyone can use this module as is with multiple fields.
I am really curious to know how the 800 weekly downloads are actually used in production sites. Multiple fields cannot be so uncommon.

This is a really useful module. I don't know other ways to create interactive forms that integrate with the site content (Webform don't do that). I hope we can get it work soon.

Thanks for a rapid action by capable people

Hi all, in case anyone here hasn't read my status update on the project page, I wanted to say that I apologize for not having maintained this module well for the past couple months. I've been busy helping out on Drupal 7 core development. The code freeze for that was originally scheduled for 10/15, then extended to 10/19, we hit a snag on a couple important issues, and are now waiting for Dries to announce what is to happen to them. I'm pleased with what everyone has been able to accomplish with Drupal 7 prior to the freeze, and with my small contributions to it. I will be resuming maintenance on flexifield within the next couple days. Thank you for your patience.

Thank you for the notice.
Take care

where does the field (the extra ones) come from? I don't mind removing them 'by hand' if it's a number change somewhere in the database.

I have one administrative user who has two extra fields, and another n00b admin who clicked add by mistkae and now always has three. Neither one of us want this but we can't get rid of it.

Subscribing.

One problem here is that Flexi-field wants to process all the displayed fields: if we get 5 like me, 5 values have to be entered. There are no way to get rid of the unneeded extra fields.
The common practice in Drupal for multiple fields seems to ignore empty fields. If Flexi-field would behave like that, we would not complain so much about these extra fields...

Anyone looking at this problem.?

First, Flexifield is awesome. It is doing exactly what I need (besides this issue). Thanks!

I've read this thread and a number of others. Rather than trying to discuss this in generic terms, I'll explain my application. This may mean that I'll go over stuff that's been discussed before. I hope it is helpful to have it all in one place.

I'm making a song database with transpose, pdf and setlist capabilities.

I've got two content types: Song and SetList.

Song contains the lyrics and the chords and then some fields that are used for interpreting the chords. For the purposes of this discussion, we only care about one of the other fields, Entered Key. This tells the system that the lyrics and chords are in, say, G. This way, later when you want to transpose to A (the Printed Key), it knows that it needs to move each chord one wholestep up.

The SetList contains a list of Song node references paired with Printed Keys. For example:

Song One (C)
Song One (D)
Song Two (Bb)

The reason I am using flexifield is that I need the Song reference and the Printed Key to move together when you change the order or the songs in the SetList. I can't attach keys to the nid of the Song because as you see above, I made need multiple instantiations of the Song with different keys (or just plain old reprises).

So, I created another content type, Transposed Song, for the Flexinode.

During the lifecycle of a SetList it will be edited quite often. Songs need to get removed and added. The order needs to change. Songs need to be switched to different keys. Each time one of these changes are made and saved, a blank pair is added. (It is not limited to the number of fields in the Flexifield as previous entries in this thread suggest). BTW, I'm using "unlimited" for the number of items.

The first thing I did was to change my theme for SetList to skip empty Song/Key items. That works, but every time the user goes into "Edit" they see a large number of empty Song/Key items. It's ugly and confusing. The users ask where the delete button is for Song/Key items. I tell them to live with it.

So, I thought of several approaches to fixing this myself (because programmers are impatient and I need it to work now).

1) Whenever the full node is viewed, delete all the extra items in the SetList theme code.

Easier said than done.

There is information about the Flexifield stored in a number of places. I deleted all the rows in the Transposed Song content type's table where the Song reference was NULL. I then deleted all the rows in the Song/Key field's table when (after unserializing) the Song reference was NULL. I then used the item ids from the last table to delete entries in the flexifield_entires table.

Still, when I enter "Edit" all the blanks are still there. I've search for someplace where there is a count of fields or another place where the Flexifields are held. I can't find it. Any help? Is this some sort of caching issue rather than an actual value in the database that I missed? If so, is there a programatic way to clear that cache?

Can I call flexifield_field directly with a delete operation? I couldn't see it doing anything different than what I described above, anyway.

BTW, just getting rid of these automatically would be way better than having a delete button next to each one. I know that proposal has been floating around. I wouldn't mind having it, but I don't think it is the right solution to this problem.

2) I've also thought that I could patch CCK in general not to display a blank field (to let the user click "Add another item" to add the first item). I don't view that as a hardship and I don't think my users will either. However, I can't figure out where that is within the base CCK code. I also don't like the idea of patching someone else’s code (except to submit the change for the next version). It's a maintenance nightmare.

3) Patch Flexinode to not save the empties. I couldn't find any problem with flexifield_content_is_empty or any other code in Flexinode itself that was responsible for empties.

4) Patch the bug in CCK mentioned in the comments for flexifield_content_is_empty. Well, I'm lost in a sea of code. I don't know how Flexinode registered flexifield_content_is_empty as a call back in CCK, so I can't find where it is being called.

Does anyone have any help in any of these directions, or perhaps a completely different direction?

Thanks!

Since my theme template was already skipping the empties for the display, I just delete them from $node when I skip them and then later call node_save. To my amazement, it worked! I have to congratulate the CCK and Flexifield module teams. There's a whole lot of design and careful coding behind making it that easy.

          $i = 0;
          foreach ($node->field_song_key as $song)
          {
            $n = $song['value']['field_songsheet'][0]['nid'];
            if ($n == '')
            {
              //todo: delete extra songs for later node_save
              unset($node->field_song_key[$i]);
              ++$i;
              continue;
            }
            ++$i;

and then later on

        node_save($node); //makes the delete of empty song/key fields permenant.

There was one tiny snag that is worth mentioning. I also had a date field that I was automatically displaying in the full node. Every time I viewed the full node, another copy of the date was added to the body. I don't see how that is avoidable. Everything is working as designed. So, I just excluded the date field from the full node display and displayed it myself in the theme template. No big deal.

Hum...
Not clear what you are addressing nor how.

Have you found the bug that makes imposssible to use an "unlimited" flexifield (I was never able to save a node with such a field)

I understand that you modifed your theme, which is a hack, not a workable solution.
You give a piece of code, where do you put it?

Thanks

subscribing

This post receives very little attention.
Is nobody using forms with multiple occurences of the same group of fields?
Flexifield seems theoretically the only way to do that.

I changed the title to reflect the actual concern.

Hello???

same problem

If you have site in development stage I recommend switching to CCK Multigroup, if it's not late (I did it myself).
Flexifield idea was great but unfortunatly author failed to provide enough level of polish and bugfixing. There are too many critical bugs that are not getting fixed.
OTOH, Multigroup made great progress, and continues to. There are small number of issues, and there are future plans of adding pluggable storage, that will make it possible to have multiple value fields inside single multigroup row (which is currently single strong point of flexifield over multigroup).

Where is this module?
I an't find it anywhere, just this one wich seems unrelated and not updated since April.
http://drupal.org/project/patch_content_multigroup

It is part of CCK 3.x which is hidden from list of releases on CCK page because it's not 'official'. You can see it at "all releases page" http://drupal.org/node/48429/release
I must say, even while it's considered unstable development version, it's much more stable than Flexifield. I don't have any major problems with it.

Yeah I ended up using cck3 too

These might be related:
http://drupal.org/node/688128
http://drupal.org/node/596940

I at least have similar problems, but not on all flexifields, so my setup:
- nodeform with 3 flexifields
- 1 referencing a type with 2 text fields and works ok
- 1 referencing a type with 2 text fields a link field and a number (checkbox) field: this one keeps adding empty flexifields on every save
- 1 referencing a type with a link and image field: this one keeps duplicating an added image field (looks similar as http://drupal.org/node/596940) on top of that the add another item comes with the previous image allready selected

Hope this helps

Sorry, I got mixed up between multiple issues and posted this to the wrong issue.

Sorry for the mixup.

Subscribing .

+1

Effulgentsia: can you provide any indication of where to start in the code to fix this problem? I have some time to devote to this and would love to help, but not much time so pointers would be appreciated.

It looks like flexifield-cck-overrides.inc has some hacks in it. Perhaps that is a good place to start?

This is quite a big problem, as I have a large form that fills up the page, and an extra one is really confusing.

so my data entry form shows four empty flexifields when i surf to /node/add/flexifield-testground, ie create a new node with a flexifield in it. theme_flexifield_multiple_values() is actually working correctly, creating four because element_children (in includes/common.inc inside core) incorrectly returns four children. replacing theme_flexifield_multiple_values with cck's theme_content_multiple_values() also returns four, so that tells me something is wrong with $element.

on to trace that... perhaps the bug is in the flexifield definition code, not in the display code?

jwc

now I'm looking at hacking theme_flexifield_multiple_values() to call flexifield_content_is_empty() and only show the first empty row. What I find is that flexifield_content_is_empty() returns FALSE for a completely new row in this code:

	// If the content type has no fields, treat the item as not empty.
	if (!count($aContentTypeInfo['fields'])) {
		return FALSE;
	}

Surely a row with no fields (as generated via /node/add/contenttype) must be empty?

Input appreciated.

Well, it appears that the above piece of code is necessary for "Add another item" to perform correctly. Apparently the system can't differentiate between multiple blank forms created by /node/add and blank forms created by Add another item... 8-(

Ok I have a dirty hack for flexifield that fixes this issue for me. I'll do more testing to ensure it doesn't mess up anything and then post it here if it passes muster.

It involved fixing flexifield_content_is_empty() so that it works and hacking theme_flexifield_multiple_values() so that it only shows the first non-empty field. Apparently if flexifield_content_is_empty() is smart enough, it doesn't block "Add another item".

Note that it's a hack. The real fix would be to find out what's causing $element to have those extra children in the first place and fix that code. Since I already have content in my db with the (broken) cck definitions (ie, the extra blank children), I didn't want to fix the cck definitions for fear of losing data.

http://drupal.org/files/issues/content_node_form_320313.patch - this is the solution :)

that's a good start and is similar to what I did. note that your patch doesn't solve the loss of "add another item" nor does it fix flexifield_content_is_empty(), which returns FALSE in several different cases in which it should be TRUE.

this patch required changes in the node-<content-type>.tpl.php template file for my content types, as well, to not show empty fields.

here it is:

http://drupal.org/files/issues/flexifield.diff

cheekdotcom...is the diff in #38 to be applied in addition to the patch in #37 or just by itself?

can you explain what you had to add to your node-.tpl.php file? are you hiding the extra fields via javascript? or killing them on the server using php? what values are you accessing/modifying?

how's it going since you applied the fix?

thanks.

Subscribing.

Here's a patch for CCK to allow configuration of the minimum number of widgets: http://drupal.org/node/320313#comment-4305032

Details in #82. http://drupal.org/node/320313#comment-4274050

This works with Flexifield when editing existing content. When adding a new node I'm still seeing exactly 3 flexifields, whatever I set the number of widgets to.

Digging further, in flexifield.module the function flexifield_widget() is passing $items on to the cck function content_multiple_value_form(). On the node/add screen, $items contains an extra item [1] which is being added in flexifield somewhere.

Also on this screen $items includes field_flexifieldname_add_more for some reason, when it really shouldn't.

content_multiple_value_form() counts the number of $items, which in this case is always 3. I think when adding a node count($items) should be 1 at this stage.

The _add_more item can be removed easily enough by adding the following before $element = content_multiple_value_form($form, $form_state, $field, $items); in function flexifield_widget() .

   $field_name = $field['field_name'];
    if (isset($items[$field_name . '_add_more'])) {
      unset ($items[$field_name . '_add_more']);
    }

"Add another item" still seems to work.

Using dev version. Looks like Flexifields default_value is the problem. On the content type -> manage field screen, it displays 2 flexifields and 1 "Add another item" button in the "Default value" section. These aren't being ignored even if they're all blank so the widget's default_value always returns an array of 3 items.

Which I think is essentially what cheekdotcom is saying.

I now have this working using the patch linked to in #41 and without any changes to flexifield.

Something cheekdotcom said in #36 made me realise I couldn't fix an existing flexifield once it had been created so I started with a new one.

To get it working, patch CCK ( see #41 ) then create a new flexifield field, setting "Number of widgets" to 1 (or anything else, default is 2) and "Number of values" to "Unlimited".

This shouldn't interfere with existing flexifields. If you adjust the number of widgets for an existing flexifield it will only have an effect on the node edit screen.

No code here, I've set it to "needs review" so hopefully others will test it.

A quick update, it seems there is a trick to get it working with flexifield. When creating a new flexifield field, set the "number of widgets" to what you'd like it to be, but set the "Number of values" to 1. Select the content type(s) then save the field. Now configure the field again and set the "Number of values" to "unlimited".

It seems the field needs to be saved with the "Number of widgets" first before being set to "Unlimited".

It seems as if there are actually two issues that have been addressed:

1. Multivalue flexifields in a new piece of content contain a variable number of empty items
2. Multivalue flexifields in an existing piece of content contain extra empty items before the "Add another item" button is pressed

Most of the suggested fixes here seem to require patching cck, with the exception of the patch in #38 above. However, this patch didn't seem to work for me and poking around the code in CCK 6.x-2.9 and FlexiField 6.x-1.0-alpha5, I was able to find a couple hooks that took care of the problem.

To restrict new flexifields to displaying only one blank item, I found that CCK checks our implementation of hook_widget_info() to see if there is a custom callback defined for the default value. By providing a custom function that returns a NULL value, we effectively skip over the logic that seems to create a random number of blank entries. So, in flexifield module, starting at line 458, I changed the code as follows:

/**
 * Implementation of hook_widget_info().
 */
function flexifield_widget_info() {
  return array(
    'flexifield_default_widget' => array(
      'label' => t('Default Widget for Flexi-Field'),
      'field types' => array('flexifield'),
      'multiple values' => CONTENT_HANDLE_MODULE,
      'callbacks' => array('default value' => CONTENT_CALLBACK_CUSTOM),
    ),
  );
}

/**
 * Implementation of CCK's hidden hook_WIDGET_NAME_default_value().
 */
function flexifield_default_widget_default_value(&$form, &$form_state, $field, $delta) {
  // We add a dummy function to keep cck from populating new flexifields with
  // blank items.
}

Then, to tackle issue #2, I noticed that the normal flow of execution when rendering a Flexifield on the content-edit form is as follows: First, regardless of whether the flexifield is set to contain multiple values, CCK runs it through content_multiple_value_form(), which then calls out to flexifield_widget(). This function then calls content_multiple_value_form() again for each item (table row) that the flexifield contains. But the logic for determining how many items there are in the flexifield is actually contained in content_multiple_value_form(), and its logic is off by one, creating the extra blank item.

However, as part of this logic, CCK checks to see if the number of items that should belong in the widget has already been determined and added to the $form_state. So when we're initially processing the form, we set the number of items correctly. And when the "Add another item" button is pressed, we check that this flag has been set and allow the count to increment normally. So, starting at line 544 of the unaltered flexifield.module, I changed the code as follows:

  else {
    $bReturnSingleItem = TRUE;

    // Keep extra blank items from getting added to flexifields with values.
    // We set the item_count flag in $form_state in order to override cck's
    // default behavior in content_multiple_value_form(). When the form is
    // submitted by the 'Add another item' button, we see the flag and allow
    // the item count to increment normally.
    $item_count = count($items);
    $form_state['item_count'][$field['field_name']] = (isset($form_state['item_count'][$field['field_name']]))
      ? $item_count + 1
      : (($item_count) ? $item_count - 1 : 0);

    $element = content_multiple_value_form($form, $form_state, $field, $items);
    $bReturnSingleItem = FALSE;
    module_load_include('inc', 'flexifield', 'flexifield-widget');
    _flexifield_alter_multiple_values_form($element, $form, $form_state, $field, $items);
  }

Hope it helps!

I can confirm that the changes jpklein made:

• Limit the fields on the node/add page to one. The Add another item button is still there and works.
• There are no extra added fields on the node/[nid]/edit page. Here as well, the Add another item button is still there and works.

I created a patch against 6.x-1.x.

subscribe

Thank you,
I applied #47 your Patch, its working fine.

Great!!! Thanks , confirming that patch #47 is also working for me. I've been looking for this for a while. Good job.

There still seems to be 2 fields internally so there are problems with required fields.

Steps to reproduce after patch in #47:

1. Create a field source content type with 1 or more required fields
2. Create a content type with an unlimited flexifield referencing the field source type
3. Create new content with leaving a single flexifield widget, fill in required fields and submit.

Also, after a failed submission due to empty required fields, the "Add another item" button doesn't work. If you then have another failed submission (which is unavoidable), the extra items magically appear. Filling all the required fields in still doesn't work, however.

Actually #51 doesn't seem related to this patch, the same thing happens without it.

Patch doesn't seem to apply to git version but works when manually applied.

Flexifield still doesn't like required fields, either the flexified itself or any sub-fields. It always fails telling me the fields are required, even when they've been filled in.

After installation and at the time of the creation of the new content i fot hte following erro

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 35 bytes) in G:\xampp\htdocs\test\includes\form.inc on line 1338

if any one have good and simple method to solve this problem please give me hint or solution to this....

Thanking you

@vmevada102 as the error suggests, you are out of memory. It's not related to this patch, or this module, but simply means that your server's configuration isn't allotting PHP enough memory in order for it to carry out whatever processes it was in the middle of. Search Google for the error and you'll reach the solution.

#47 looks good, but I do see these errors when I click the "add another item" button:

warning: Parameter 2 to date_form_alter() expected to be a reference, value given in /mnt/www/includes/common.inc on line 2930.
warning: Parameter 2 to date_timezone_form_alter() expected to be a reference, value given in /mnt/www/includes/common.inc on line 2930.
warning: Parameter 2 to og_form_alter() expected to be a reference, value given in /mnt/www/includes/common.inc on line 2930.
warning: Parameter 2 to patchbay_form_alter() expected to be a reference, value given in /mnt/www/includes/common.inc on line 2930.