Reuse of field collection entity type on more than one collection field?

EDIT: I'm an idiot. My use case is not the same as OP's, and is already possible anyway by using an existing field.

I'm interested in this as well. Here's a different use case.

I have several Field Collections as fields on the User entity. I'm using them to group fields that I can then hide/show conditionally with Conditional Fields.

Now I'd like to re-use those collections in another entity type (happens to be Registrations, but it could be anything).

I'd like to be able to add FC bundles I created for the User entity to the Registration entity.

What would it take to get this off the ground? Does it even sound feasible for Field Collection to handle?

Crossreffing #1569714: Allow multiple Field Collections per field and allow the selection of a specific Field Collection at content entry time

One could argue that it would make sense to use content type(s) and views for this

I am looking for the exact same functionality. Am I understanding you guys correctly that field_collections does not have the database structure to provide this? I would be willing to contribute on this if I can.

@nevets: No, thisis not a solution. We use field_collection for some reasons. E.g. not having a required title.

a little confused but i think what you are asking for is:

- can you re-use an existing collection on the same bundle

in other words, from your example above, you have a collection (field_box): title, a body (summary), a link and (optional) an image

and on the frontpage bundle you want to add 2 of these fields?

this would be great; but i think more of a bug in core than f collections - although it applies more obviously to f collections than to other fields as f collection is basically "a custom field structure"

i don't think your title is correct (although i guess you could use a collection on a collection; but i think the generic title is "re-use collection field on a bundle" (but maybe i am missing what you are trying to do).

yes, this would be very handy.

i think this is sort of approaching the idea of a FCK (field creation kit) - which could use f collections to put together custom field structures.. and then they would show in the field type list. possibly we need a separate issue for that.

The idea of creating field collection bundles separately then selecting which bundle to use when you create the field collection field on an entity is a good idea.

This separation would allow 2 things.

1. Multiple field collection fields with the same bundle on an entity
2. The possible of using multiple bundles for one field collection fields

I am in a situation building a website right now where it would be very handy to be able to have several different field collection bundles used by the one field collection field on a node.

The field collection interface as it is now is great, the functionality of the add,delete,edit links right on the node view page is great for many user interface situations. To expand the possible number of bundles used by a field collection would allow the creation, and management of some very complex data structures to come under the realm of site builders.

I am researching the idea, and would be very interested in what the field collection module maintainers think. Is this something they would be interested in including in field collection or would a separate module be appropriate?

++!

We're using field collections to supply a multivalue composite image field with caption, style select, alt/title/longdesc etc (because file entity's fields cannot be overridden per-field-instance and per-content-revision). The approach works well.

But when providing a field collection in code for site builders to use, you also have to specify an instance, which requires that you either attach an instance to an existing content type or entity, or you also create a dummy entity and attach to that. Neither approach is very friendly to site builders.

Creating the field collection bundle separately would presumably make it available to add instances in "manage fields", without needing an actual instance on some existing entity. I'm all for it.

+1.
I really needed this functionality today and am surprised that this module does not allow for this (what I would call multiple fields using the same collection instance on an entity).

I too would like to be able to reuse a Field Collection type at several places on one same content type. I mean, it's the base no ? Field Collection is great but I was really disappointed to realize I could not reuse my structure for more than one field on my content type.

It looks like Node Field could be a solution to Field Collection's limitations. I'll look into it and give some feedback on it.

Seems that Node Field also allows to choose which custom field to use at individual node level...

Yeah that's a really good idea. I thought about it but I thought that entity reference would enforce me to create a node with a node page etc... but no you're right! For the record Node Field does not require to create "nodes" either. But the solution is not perfect yet and quite buggy so I am going to have a look at the inline entity form alternative.

Field Collection creates a new Entity type per collection right? A possible solution could be to reuse or adapt Field Collection's code to be able to reuse Field Collections with Entity Reference and thus with Inline Entity Reference...

I'll definitely look into your solution.

Just awesome :) I didn't even use Field Collection. I seems to do the job perfectly. Inline Entity Form has done some great improvement too, I remember being redirected to a different page in the past to be able to edit a product. Now it's all ajaxified. I haven't tried yet to create multiple Nested Boxes to see if I can choose what kind of Nested Box I want to add each time.

Ok I now understand why the hesitation between Nestedbox all the way vs Field Collection inside Nestedbox...

Personally I want to give my users the possibility to choose on the fly which kind of "Component" they want to add on their node between say simple components like a textfield, a textarea, an image, or more complexe components such as a Slideshow, an Accordion, a block with tabs...

Of course the matter of using Field Collection inside Nestedbox or only Nestedboxes only concerns those complex components...

Using Field Collection inside Nestedbox helps keeping "the list of available Nestedbox types to allow" cleaner, when creating the Entity Reference field. But first, this is no big deal since the client does not see this screen. Plus I guess that a simple checkbox "don't show on Entity Reference list" on the Nestedbox type edit form would do the trick...

Another reason to use Field Collection inside Nestedboxes would be that it creates a visual difference between adding / reordering components (Nestedbox) and component items (Field Collection instances). That can be a positive point for the client experience. But here again, I think a good padding or a different background color could do the trick too.

The less module one has to install, the better. So unless Field Collection provides advantages over Nestedboxes I would recommend not to use it.

But actually I've got one good reason to use Nestedbox all the way: because Inline Entity Form nicely simplify each line by hiding all its fields. Inline Entity Form only displays an administrative title and the component type per line. This makes the form cleaner and reordering items easier. Much easier than with Field Collection especially if you have a least one CKEditor body field per item...

So I'll definitely go with Nestedbox all the way ! Although I don't love the name :) I'd have preferred "Components" but it sure is because of my use case!

Thanks a lot for contributing this module and I see it is not the first! Looks like the code is of great quality with Drupal 8 PSR4 techniques and stuff... so even though still in sandbox state I am personally very comfortable using it on production sites.

Actually Nested Box did not bother me as the module's name but I did not like the fact that Inline Entity Form buttons were showing "Add new Nested Box" where I would have preferred "Add new component" or "Add new slideshow item"... and there actually is a solution to that! Inline Entity Form allows to Override Labels per Entity Reference field. That's very well thought. More about this here: https://drupal.org/node/1880850

Nice catch. Well this could be a feature request for IEF! :)

Looks like the Paragraphs module is a candidate too!

Btw, one more thing to add here is that with entity reference + inline entity form, you need to save each embedded entity before saving the container entity.

I think this is not true.
I have a "Page Components" (Entity Reference + Inline Entity Form) field which allows me to create "Accordions" (Nestedbox), that are themselves composed of "Accordion items" (Nestedbox). Whenever I edit an accordion item I can directly go save the whole node at once. All modifications are automatically saved.

I also want to point out that nestedbox does nothing magical. It only defines an entity type with bundle support and the usual add/edit/create stuff. The magic really comes form inline_entity_form + entityreference.

The name 'nestedbox' is because you can nest this stuff.
One nested box type can have an entityreference field that references yet another nested box, etc.

In the past I often used blockreference + bean instead

I think the name Nestedbox lets people think Nestedbox does more than it actually does. Nesting. You said it yourself, the nesting part actually comes from Entity Reference. Nestedbox is closer to a the Bean module. So Nestedbox should more likely be called something like "Basic Entity". Speaking of which... there is a module already going by that name (almost) and that intended to do the same I believe. https://drupal.org/project/entity_basic

But I think "Basic Entity" would actually be too generic... entities generally have a more specific name such as Product or Entityform that tells right away what they're meant for. Well I think Nestedbox is no different, even though it's structure is really basic, it has a goal too. Nestedbox is meant for us to be able to create custom component types that we can later use to build our content. That's why I think it should be called "Content Components". Which is also the name I would recommend for the Paragraphs module, that for me is more than just a better body field.

The Paragraphs module is based on and a good improvement on the field collection module.
It works well but also still requires a good solution for reusing a combination of paragraph bundles. I posted a features request here with example use cases: https://drupal.org/node/2280053

As a workaround for field collection module, I now use the 'node clone field collection' module to just clone empty nodes that I call 'node templates' for end users. Not ideal but it works and allows end users to create such node templates by themselves without the need to create new content types.

The advantage of the paragraph module is that you basically allow end users to create a custom combination of selectable field collections (called paragraph bundles) for their node. This is absolutely awesome, and even more awesome if those combinations could be remembered or cloned. But a 'node clone paragraph' module does not exist yet.

https://www.drupal.org/node/2213261#comment-8952163 illustrates solution to OP using Paragraphs module.

You can achieve the reusage of field collection fields in any entity with field collections itself: simply define a new field collection field as a container for the field collection to reuse. You can even extend the reused field collection. Using css you can simply remove unwanted titles and borders in the entry form.

In general I would not recommend the solution in #30 as it has complexity and performance implications.

You are creating nested entities that will make your database queries very unfriendly and just make things generally more confusing.

Things like creating views gets more complex because you need more relationships (views can make some pretty poor performing queries when you start to get complex).

Also, having to hack around it with css is a sign that something is maybe not quite right.

I can see there being some use cases where nesting may be useful but I wouldn't do it unless I had to.

We looked into field collections for something similar but couldn't achieve what we wanted, We ended up going with ECK to create a simple entity with one bundle.

In our content type we use single value IEF fields to add multiple instances of the same entity to the same content type.

e.g.

Qualification Entity Fields

• Description
• Date Issued
• Date Expired

There are a set number of qualifications so we just add them all as separate IEF fields, creating a new Qualification Entity each time.

The bundle and field are tied together and it's outside the scope of field collection to try to separate them.

I'd say paragraphs is the best bet for this use case.

If something for this were to be implemented in the field collection side it would be more like #2044309: any way to clone a collection structure.