The need for collections of fields comes up in most Drupal projects and is normally solved by contrib modules or by coding custom fields.
The normal solution is a light-weight entity such as
Paragraphs →
or
Field collection →
.
Paragraph module →
is the go to solution for this in Drupal 8. Over time the paragraphs module was expanded to control content-type display so that content editors could effectively control layouts with it.
Drupal core has a stable layout builder, the need to use paragraphs for layouts is no more. But there is still a need to use it for fieldable fields/field collections.
Paragrpahs doesn't integrate well with layout builder because there is a disconnect between content-editing and layout building.
In addition, in core we have a use case for such a collection of fields in the ingredients field on the Umami recipe content type. At present it is implemented as a text-field, which prevents us from using Drupal's modelling tools to build powerful features such as a view listing 'all recipes featuring chocolate'. This is because the ingredients field is used to list three distinct items. E.g.
1 cup of flour
When really this should be three fields
1 (quantity) cup (unit) of flour (ingredient).
If we had a way to build collections of fields from the UI in core, we could construct a new field-type for the ingredients list comprising the following sub-fields
- Quantity - number
- Unit - text-list or taxonomy term
- Ingredient - taxonomy term
This would unlock Drupal's relationship modelling power
Add a collection field type to core with a proposed target of being an experimental module in Drupal 9.1
The field will provide a UI to allow site-builders to build new field-types by combining existing field types.
All other functionality should continue to work
- view support
- formatter support
- widget support
- data storage and retrieval
- serializer support (json api etc)
- translation support
- revision support
Work has commenced in both the Field union → (PreviousNext) and rich field (Lullabot) projects to investigate how feasible this is.
The two have agreed to join-forces and work towards a common goal
We have a slack channel #multifield
The solution provided by and the concept of fieldable fields/field collections is strikingly similar but distinct from the concept of
compound fields.
As mentioned by @moshe in a comment below a field with subfields can be created
programatically, drush generate can even do it for you.
This could meet the needs for the specific use case of an ingredients list for core but would involve a core "ingredients list" field.
There is a ticket open for ✨ Add field grouping to core Needs work
Field groups relates to the visual grouping of a set of fields visually on a form, think fieldset, container and details form field types.
Field groups provided a 'group' on the Fields UI in order to arrang fields into groups.
This is different from the concept of a field collection or fieldable field. A Fieldable field is a single entity with fields of it's own versus simply a group of related fields shown together on a form.
webchick and I were discussing the progress of #301071: Remove profile module from core → , and were wondering if "fieldable fields" would be a better direction. One of the issues is dealing with profile module categories. IMO, those categories are best expressed as taxonomy fields. If fields could contain other fields, then profile categories would be simple to build with Taxonomy.
I'm going to investigate and see how difficult this would be to implement, though I'm fairly raw at the fields API so any pointers would be appreciated :)
This has evolved into creating a better api around building more complex fields with in core. This would better support a unification of efforts among modules like, link, date, multifield, and complex_field.
See:
#1792072: Merge field_collection module in Fieldable Fields killer feature in Drupal core →
✨
Add field grouping to core
Needs work
Needs work
Idea
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.