Display collection fields within entity form (subform/embedded)

just subscribe

Yes, code in http://github.com/yched/combo is the best thing to start from when implementing widgets. So I have had plans already to use it. :-)
I'm going to work on it ASAP.
Stay tuned. :-)

Subscribing

Subscribing

Subscribing

Subscribing

Any news?? I do believe that having a widget inside the field_collection edit screens is a worthy replacement for multigroup and almost a must have feature.

Looked into the combo code myself, but still stuck a little on how to apply this into field_collection entities.

Subscribe

Did anything happen with this? I'm hoping that maybe the work has been done, but not yet posted to d.o.

subscribe

subscribe

subscribe

Initial patch

Maybe we want this widget in a submodule?

subscribe!

Hi Casey,
I tried this patch and I must be missing something because I do not see a difference. What should I see happening?

You will be able to use a "Subform" widget for field-collection fields instead of the "Hidden" widget.

Thanks casey!

Definitely on the right track.

The only problem is filefield doesn't appear to upload? just resets after upload.

Also hierarchical select gets reset when adding another item, but that's more minor..

If those issues were resolved, definitely useful.

DT

Thanks Casey,
I found the "Subform" widget choice. I assume this requires your "subform" module which I installed and enabled. I am still looking for what I can do next. Davidthomas seems to get it but so far it is not intuitive for me. I also enabled the "subform example" module which I cannot find where it is to try it. I would appreciate any suggestions on how to proceed.

This solution from #13 works for me.

Searching for a solution on this issue I found this site:
http://www.agileapproach.com/blog-entry/compound-fields-drupal-7
and an accompanied module: http://drupal.org/project/dnd_character

It has this solution without the need of the subform module. I don't know if it is usable?

It doesn't need the subform module. I just called the widget "Subform" because it is... a subform :) "Inline" or something else would do too.

Patch needs work though. For example regarding required (sub)fields.

Subscribing

#977898: Filefield upload widget broken in combofield

I think I fixed file field support

Patch works. I tried it out with some basic fields. Glad to see something happening here. This module now does something useful. :-)
UI still has a way to go, but this is a great start.

Simplified patch

Have something working to prevent #required (sub)fields from throwing errors while the field-collection item is empty (and thus not being stored).

It's a bit hacky though... Unfortunately, I don't think we can do it much cleaner without a FAPI change.

Seams to add a new field collection item every time you edit the node if you have a yes/no check-box that will always have a value (the blank row problem). We need some kind of "Delete this row" mechanism like we had with CCK multigroup.

same problem with #29, should get rid of the blank row problem, or just ignore empty rows on Save.
Also adding "Remove" buttons on each row would be nice too.

In general, this is working great for me and is the right idea in terms of UI, I think. Any chance this is still being worked on? I think it would be a substantial contribution to this module if it were to make it into a release (hopefully soon!). Thanks for putting this together.

Oh, and +1 for remove row.

I wanted to try this out, but Field_Collection keeps blowing up on me with its favorite error:
messageException: Invalid field name given. in FieldCollectionItemEntity->__construct() (line 143 of sites/all/modules/contrib/field_collection/field_collection.module).
It makes the node-edit form look really good, and it worked with an image field, so this patch is definitely a step in the right direction.

The patch works great - nice addition to this module, thank you.

+1 for adding a "Remove" button & it'd also be useful if rows could be reordered with drag/drop.

The patch in #28 works fine for most purposes and adds functionality that seems logical but doesn't exist now (to be able to edit the fields in the field collection when editing the node itself).

Seems like it would make sense to commit this and make follow up issues for things like adding a remove button. The fact that empty rows are saved if they are not empty (i.e. when there is a selection field that has a selection) is not really a 'bug' IMO. We just need a better way to remove the row.

Changed the title to make it more clear what this issue was for.

Great stuff to all involved with this widget patch (& field_collection). Its starting to feel a lot more like CCK3 Multigroup now. Awesome!

#34, agreed! Would love to see this in -dev.

Very cool, #28 seems to work great.

Ah- except for the "remove" issue that everyone has mentioned. But I agree that this should probably be committed and then that kink worked out.

Just in case anyone is wondering, this won't get committed for at least another couple of weeks as fago is on vacation.

Thanks a lot Casey. #28 works great. Just need the "remove" and it's perfect. Ho, any idea how to remove the "edit, delete, link" on the node view as it's now manageable on the edit view? I could still use css to hide them but was wondering if there is a better way. Any thoughts ?

@sebish, you can hide those links from the 'Manage Display' screen.

To all: Is anyone working on the remove functionality or should I take a stab at it?

@drclaw, thanks. Removing the texts on the Manage Display screen did the trick.

subscribing

I got time this weekend for the remove button.

Also, what about putting the (sub)fields in table columns? Seperate widget?

subscribe

#45 casey: would be awesome to have a separate widget for that!

sub

subscribing

sub

sub

sub..

Subscribing

+1 for delete and reorder options. Please paste issue # for those if this is commited as is.

subscribing

Sub

subscribe

Patch from #28 applied to the latest dev version. (Appling patch with git apply is not working, with osx patch command ok)

Patched module with subform widget works as intended, looks good and no error messages.

#28 works here too

confirming that #28 works

Hi,
I really like the subform patch, nice work! However, I am having a problem with it currently. I have a custom field that I've added to the field_collection which has a custom #element_validate callback at the "root" level of the widget form element (as returned by MODULE_field_widget_form). The $element looks something like this:

<?php
$element['#element_validate'] = array('MODULE_custom_validate_callback');
$element['field_column_1'] = ...;
$element['field_column_2'] = ...;
...
return $element;
?>

I can confirm that the custom field works correctly (and validate callback is called correctly) when attached to a non-field_collection bundle. When attached to field_collection (using subform patch as in #28) the field is correctly stored to the sql DB but the validate callback is NOT called.

I don't claim to fully understand the field_collection and subform code but is it possible you are overwriting the callback? Maybe in this code (starting at line 790 in field_collection_field_widget_form):

<?php
$element += array(
   // @todo - properly declare element type in hook_element_info().
   '#type' => 'field_collection_widget',
   '#element_validate' => array('field_collection_field_widget_validate'),
   '#parents' => $parents,
 );
?>

Hope this helps and I'll be happy to provide any extra information as needed. Thanks.

I am using the patch in #28 with Drupal 7.0 and Field Collection 1.0-beta1.

I have a Decimal field in the collection (a price), and the number_field_widget_validate callback fails. I did some digging around and found that the validate callback is not able to get a reference to the field and instance using field_widget_field / field_widget_instance, probably because the $form_state is not in proper condition?

I don't think this is related to the number field but probably any field that has a validate callback ?

It could be the same problem as in #61..

I applied the patch in #28, and functionality seems good. I would love to see two things (or be pointed to them if they are already there):
1. A remove function on the node edit page rather than just 'delete' on the view page.
2. A pointer to how to hide the edit/delete buttons on the view page (I looked in field collection > my collection > manage display).

I will be happy to test updates!

Patch #28 doesn't work for me.

Current Items are not chown in block. And new Items result in an empty field.

I faced the same issue of empty fields as #64. But it went away when I did a update.php after applying the patch, and updated to latest Entity API. New fields added to a collection having existing fields with values too works fine. I am yet to try a nested field collection though.

I felt it would be good if one can easily display the fields in a collection as a table (not related to the current issue) - maybe it can be done using views - I haven't checked.

#28 was working great for me, until I enabled the i18n modules and started translating the site. The field collection widget no longer stores any data in the database, though I can still add field collection data the original way (on the parent node view page). The site is due very shortly so I'll try and come up with a patch or work around, but I don't understand the code that well (and don't have a lot of time to figure it out). If anyone has any ideas I'd be eternally grateful.

#28 works seems to work fine for me, btw. awesome module!

subscribe

subscribe

subscribe

Same problem as #66. Patch worked very well, but got problems with locale module too. After disabling it patch works fine again.

Is this really a problem with the patch?

The readme says that there is no revision and language support at all at the moment.

Restrictions
-------------

* As of now, the field-collection field does not properly respect different
revisions or languages of the host entity. Thus, for now it is suggested to
only use the field for entities that are not revisionable and translatable.

sub

subscr. #28 work for me

sub

subbing

sub

Thanks casey for working on this!

>Maybe we want this widget in a submodule?
Yes, I think it would be a good idea to great a "field-collection widgets" sub-module and just leave the simple-hidden widget in the main module.

Also, I'm not sure whether subform is the best name for it. Maybe, just "Embedded" would fit? Anyway, I'm fine with whatever people think is best.

@the-code:

       $item['entity']->setHostEntity($entity_type, $entity);
+      entity_get_controller('field_collection_item')->save($item['entity']);
       // Pass FALSE, as we the host entity is already being saved.
-      $item['entity']->save(FALSE);
+      //$item['entity']->save(FALSE);
       $item = array('value' => $item['entity']->item_id);

Instead bypassing the usual save function, I think we should add an option for skip saving the host entity, so one can easily save field-collection entities e.g. in node-hooks. If we do so, I think we don't need the current internal $create_link option any more.

@field_collection_field_is_empty()
I don't feel like this check is a good idea, as the naive interpretation would be to tell me whether an entity exists. I think we should better leave it up to the widget to *not* add an field-collection item if it thinks it is empty. That approach should also work better then when listing field-collection items during display or in a view.

+      if ($recursion++ > 5) {
+        return $element;
+      }

Though It's unlikely people hit this limit, I think we should a message explaining why the form is missing - with the exception of embedding the form of its own field-collection by adding the fieldcollection-field to the field-collection.
We could add a separate check for that here, but I guess it's fine to add a validation to not allow users to do that at all.

+        // @todo - properly declare element type in hook_element_info().
+        '#type' => 'field_collection_widget',

For what is this element needed?

Any cause you decided to store the entity in the form element instead of storing it in the form state by using field_form_set_state()? I think having it in the state would be superior, as that way the same entity instance can be easily kept across form rebuilds.

>+ // @todo : not sure how 'required' should behave.
I'd say in that case it should just validate any required form-elements if any.

I agree, that we should move on and commit this asap + then handle issues like i18n but also proper handling of empty-items in follow-ups. Let's just get things right now that might affect the existing module, such as the save function.

Hello

I'm using this module for a project.
I've created a custom module and altered the node form to show the field_collection add/edit/delete links of all instances of a particular content type.

I hope it can help someone

Fago, I would love to see this committed. I just manually patched the most recent dev version with patch in #28 (git apply didn't work). So far it seems to work.

Subscribing

Ok, there is no multilanguage support, but if you can fix this for not translatable content type that have language, it would be great :D

Notice: Undefined index: #language in field_collection_field_widget_form() (Line 800 www/sites/all/modules/field_collection/field_collection.module).

There is problem with Date field - no label, no help text, no pop-up calendar. Also validation error.

Notice: Array to string conversion in drupal_validate_utf8() (Line 1381 www/includes/bootstrap.inc).
Warning: preg_match() expects parameter 2 to be string, array given in drupal_validate_utf8() (Line 1387 www/includes/bootstrap.inc).

Unlimited value field has an add button and only one field-collection form, I want this button also for limited value fields. If max=5, I don't want to see all five forms, I need one form and an add button, that disappear after 4 clicks.

I have also several notices on host-entity's 'manage fields' page after editing field collection and after saving node with fc

Notice: Undefined index: #field_parents in field_widget_instance() (Line 545www/modules/field/field.form.inc).
Notice: Undefined index: #field_name in field_widget_instance() (Line 545 www/modules/field/field.form.inc).
Notice: Undefined index: #field_parents in field_widget_field() (Line 520 www/modules/field/field.form.inc).
Notice: Undefined index: #field_name in field_widget_field() (Line 520 www/modules/field/field.form.inc).

I worked over the existing patch and improved/polished it based on my suggestions in #78, beside separating it into another module. Not sure about that yet..

Basically it should be good to go, please test.

subb

@Fago nice!

Tested with a field collection of text + integer in a content type.

Using hidden:
On node view I receive:
Notice: Undefined property: stdClass::$field_collection_test in locale_field_node_form_submit() (line 409 of (...)/modules/locale/locale.module).
Then I can clic the add button, and submit some content in my fields. As a result the notice disappears.
As admin I can edit it or delete it.

When you create a field in your field collection and then delete it you receive Notice: Undefined index: field_collection_item in field_info_instances() (line 682 of /Users/jerome/Sites/acquia-drupal/modules/field/field.info.inc). If you create a field again it's gone.

When you want to use the field collection as a multiple value (set Number of values to unlimited) with the embedded widget, the Add button is still displayed on node view, it shouldn't imo. If you use it nothing is saved.

Appart from that everything is very fluid and works very well.
Further testing might be interesting with more specific contributed modules fields.
Is this translatable (aka. multilingual)?

Using the embed widget, I've tested a field collection containing an image and file field. When you click 'upload', the field doesn't update to show the image thumbnail or file.

If you don't actually upload the file but save the node, everything appears the next time you go to edit the node. Other than that, it's looking really good!

I reinstalled the newest dev (june 06), applied the patch. I had to reset my two field collections from hidden to embed, which removed this error:
Notice: Undefined index: hidden in field_ui_field_overview_form() (line 360 of /Users/mariagwyn/Sites/acq-dpl/drupal-7.2/modules/field_ui/field_ui.admin.inc).

Also, since I am showing the fields via view, I received this error if there is no data in the fields:
Notice: Undefined offset: 0 in views_handler_field_field->set_items() (line 725 of /Users/mariagwyn/Sites/acq-dpl/drupal-7.2/sites/all/modules/views/modules/field/views_handler_field_field.inc). Edit: on the views issue, unrelated to this, see http://drupal.org/node/1153066

Otherwise, looks nice. I got around the 'delete' issue by putting in help that says to delete info by removing content from the field. It would still be nice to have this as a function on the edit view rather than content view.

Looks good!

I also think it would be useful to have a delete function in the edit view.

EDIT: I tested the patch in #83 with views, you can read further in: http://drupal.org/node/1047784#comment-4568236

I tested the patch in #83 with content translation, if you want to read further, here it is: http://drupal.org/node/1156468#comment-4568210

Sorry for the noob question, but how do i patch a module? I just did it manualy but there's gotta be an easier way no? I'm working under windows environment.

I've added the patch but as #87 said there are issue with the image uploading. If you just add the pic without clicking upload it will display in your article, but if you click upload then it doesnt show thumbnails and won't be added to your article either.

And when i click on edit, there is automaticaly a new group field opened on top of those i created. I created and filled 2 and there's a third one empty when i click on node edit tab.

Other than that it's really looking good.

Thanks in advance.

This looks like the simplest answer available on this site at the moment. There may be better options but I'm afraid I tend to do my patching in linux. http://drupal.org/node/75790#comment-2615716

ad #87:
hm, I got already similar reports in profile2, so this might be a core-problem.

ad #88:
indeed, once you specify a default value, the field API saves NULL values. I've fixed that.

To move one, I've just committed #83 with the mentioned improvements. So let's handle everything left like i18n, better delete functionality and any problems with it in follow-up issues.

I am getting an "fatal: corrupt patch at line 284" when trying to apply the patch from #83.

My steps:
1) Upload the patch to the field_collection module directory
2) git apply -v field_collection_widget.patch
3) I then receive the erro.

Any help would be appreciated.

@russelltaylor05 no need to patch anymore, as #83 has been commited by fago, yet, before patching, make sure you apply the patch to las git: http://drupal.org/project/field_collection/git-instructions

A little aside to anyone updating from a version where the widget is called "subform" to the latest where it is called "embedded": the widget selection on your manage fields page will be set to blank and throw an error. Re-selecting "embedded" as the widget fixes it right up.

For those having image upload problems in #87 and #92 (and myself), I've opened a separate issue at #1187010: Image field malfunctioning on embedded field collection form..

It might be just me, but it seems there is still no "remove" functionality on the node edit form. Using the last dev (june 14). Could you confirm I'm stupid and it's hidden somewhere I haven't had the chance to find?

And am i the only one to have this issue:
Let's say i've a collection field containing 2 fields, and that collection field is repeatable an unlimited number of time.
Well when i go edit the node i always have an extra empty collection field.
Is that a normal behavior? It gets quite confusing for the user.

@sebish - From what I see you are correct - no remove button, to delete a collection, blank all of its fields.

@William - I believe this is the default behavior for any unlimited field in Drupal. An unlimited text field always has a blank text field before the add more button, an unlimited image field has a blank file upload button.

Ok thank you for answering.

I am having a similar problem with this as well. I have made some of fields required in my "Degree" collection such as school, program, etc. This works great, but embedding the field into my user entity causes problems on the user edit screen. Since the 'new' collection contains blank info that is considered required, it will not let me save it. Is there anyway to get around this?

This is a pretty long issue, i've tried to read it entirely and i ended up installing the subform module and the latest dev of field_collection module.
I didn't patch the module since that patch should have been already commited, right?
Is there anything else needed to enable the new widget for a field collection?
I see only the "hidden one" like with the stable release of the module.
Thanks.
Da.

@planctus. The "embedded" widget is commited in the latest dev of this module, it's available to me. Then you go to manage fields and the widget for you field collection, it should be there. Try clearing the cache or update.php? As far as I know, the field collection module doesn't use the subform module, it's just been referenced as a term: the general idea of a "subform".

@daniel.tyree, I think that would probably be a separate issue, of overriding the 'require' property for a field collection, because since it's an entity with required fields, it's behaving as it should.

@daniel and the remove/delete conversation: I created a new issue for this at #1222608: Allow for deletion of a single value of a multiple value field. Now that embedded is committed we should probably start new issues for any new bugs or feature requests.

Ok, it was me, i didn't realize i was still using the beta and not the latest dev in the environment i was working on. I also removed the unused subform module,
Thanks,
Da.

#13 works for me! :D

Thanks!!

fago -- in #78 you point out the new public function save($skip_host_save = FALSE) { that allows the saving of a field_collection without saving the hostEntity to avoid recursion.

I'm having the same problem across a few sites right now where the user wants to be able to start editing the node, click an embedded link to edit a field_collection, and then work on the node some more before hitting save. This is impossible since saving the field_collection updates the last modified timestamp on the hostEntity and we end up seeing the "this content has already been modified..." message when trying to submit the node edit form. Is it somehow possible to save an entity via the standalone form and not have the hostEntity updated?