Description from the Field Collection project:

Provides a field-collection field, to which any number of fields can be attached.

A field collection is internally represented as an entity, which is embedded in the host entity. Thus, if desired field collections may be viewed and edited separately too.

So you have a "parent" entity that can contain other entity(ies) that behave as fields in that the user can add more than one of them without leaving the "parent" entity form. Since it might be easier to explain with an example, here's a common use case that hopefully makes things clear(er):

Suppose you have a "state" entity that has some regular fields like "state_population", "state_size" and so on. You also need it to have a "cities" field, but you need this field to be fieldable too. So, you can add the cities within each state and at the same time include their own respective "city_population" and "city_size" etc fields. You can set this special filed to have only one value but the common use case scenario is to have multiple values in which case the "cities" field in our example has a "add additional item" button/feature. As you add cities from within the state edit form, new city nodes are created (instead of fields).

I guess you can sum it up by saying that you have other "child" entities being attached/linked to the "parent" entity instead of fields added directly to it. Hope this makes sense.

Note that this is different from the core issue #501366: Add field grouping to Drupal core that aims to bring Field Group into core in order to provide the feature of simply grouping fields together in the form/display.

Comments

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented
Title: (field_collection in core) » field_collection in core.

...sorry

MickL’s picture

MickL commented

the problem of field collection is that it is seperated from the manage fields tab (admin/structure/types/manage/*/fields)

this is an example how a usefull implementation into core could look like:
illustration

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented

Re #2: I think what you mean is #501366: Add field grouping to Drupal core. If not, and you think field_collection.module should use such a UI, then I don't how to distinguish the two, because we need to support both (currently in contrib, but still...).

netsensei’s picture

netsensei commented

Okay. Suppose we go for this. What do we need to do?

  • Convert the Field Collection entity definition to a PSR-0 class in lib/
  • Convert the Field Collection widgets
  • Convert the Field Collection formatters
  • Convert the DB schema
  • Rework the hook_menu implementation. Since field_collection entities are fieldable and have their own Field UI.
  • Rework the FieldCollectionItemMetadataController class

Questions:

  • Which place should Field Collection get in core? As a submodule of Field or a stand alone?
  • There are a few Views handlers associated with FC, I suppose conversion should be treated separately (follow Views in Core?)

Given the amount of work ahead, what are the arguments pro and con getting this into core?

Pro:

  • Compound fields are not an uncommon use case.
  • FC is a well maintained module
  • It's not an overly complex module

Con:

  • It'll still take time to get this in nonetheless. Even with the help of the original maintainers.
  • Does it rank up with i.e. entity reference or taxonomy in terms of use?
swentel’s picture

swentel commented

Which place should Field Collection get in core? As a submodule of Field or a stand alone?

Underneath field, the effort to move entity reference does the same, see #1801304: Add Entity reference field. It would also need a dedicated maintainer, see also #1823042: Add maintainers and d.o components for all field type modules - which ER is also going todo.

My gut feeling is that moving this into core is going to be a complex task and even Field Collection itself in contrib hasn't even had an official 1.0 release until now, so I'd rather move this to D9. But you're free to start moving on of course :)

netsensei’s picture

netsensei commented

I agree. Though, I admit I'm game to take on the challenge, this late into the game, I think there are more pressing issues which need attention.
Suppose we do get this in before feature freeze, getting the code from beta to stable could happen while we clean up bugs.

netsensei’s picture

netsensei commented
Status: Active » Postponed

Okay. To be totally clear about this: Although I like the challenge, given the tight timeframe and the complexity of the request, I'm not committing myself to actually get FC into 8.x before feature freeze.

I'm going with Swentels' recommendation and mark this as postponed (for now).

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Version: 8.x-dev » 9.x-dev

This is most likely D9 at this point.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Working on a d8 version over here if you want to get involved
http://drupal.org/sandbox/larowlan/1966232

lpalgarvio’s picture

lpalgarvio commented
Issue summary: View changes
Parent issue: » #607396: Killer feature: Fieldable Fields in core
lpalgarvio’s picture

lpalgarvio commented
Title: field_collection in core. » Merge field_collection module in Fieldable Fields killer feature in Drupal core
Status: Postponed » Active
Issue tags: +Fields in Core
Related issues: +#501366: Add field grouping to Drupal core
catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

Marking duplicate of #501366: Add field grouping to Drupal core - we only need one issue for discussing the general concept.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.