Allow cardinality to be restricted (overriden and reduced) in the field instance settings

Created on 17 January 2011, about 13 years ago
Updated 15 February 2024, 16 days ago

Modules can alter a widget and some of its settings via hook_field_widget_properties_alter.

Some settings though are in field instance settings and can not be altered right now. Examples:
* maximum number of values (note: don't get this wrong, this is not about field schema cardinality)
* widget type for widgets like og_complex that do kinda chaining

Simply passing settings by reference in $context allows modules to alter these.

(D8 killed that hook per pluginification)

Original summary

Original title: Allow cardinality to be restricted (overriden and reduced) in the field instance settings

It is Impossible to override the field cardinality for a specific instance even when set to unlimited. When a field's cardinality is set to unlimited it shouldn't be a problem when it is overridden to a fixed number for a specific instance.

This functionality would be very handy. An example would be the audience field of the Organic groups module; you can't limit the number of groups for one entity type while keeping it unlimited for another.

Or when using for example views you might want to list nodes of several types including a icon. It would be handy if you could use the same field. But what if you want to limit the number of images for the one node type while allowing multiple images for another.

Unfortunately getting this to work is impossible. There are no suitable hooks (I found one way, but that one is very very hacky).

Of course it would be possible for the field defining module to include a instance setting to limit the cardinality. Also a wrapper widget would be possible, except it might give unexpected results for widgets that handle multiple values themselves.

My request is to provide the possibility to limit the cardinality for field instances (when the field cardinality is set to unlimited) for any field type.

Feature request
Status

Active

Version

11.0 🔥

Component
Field 

Last updated about 8 hours ago

Created by

🇳🇱Netherlands casey

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates : some issue and comment data are missing.

  • 🇺🇸United States devkinetic

    Just as an update, field config cardinality is going strong and will be addressing the constraint update soon, so if your looking into this feature, give it a spin.

  • 🇮🇹Italy plach Venezia

    It seems the use cases described in the OP could also be addressed by #1234624: Limit the number of fields to display .

  • 🇷🇴Romania amateescu

    I've been thinking about this issue in the past couple of days, and I think there is a way to implement this cleanly thanks to the OO code that we didn't have in D7.

    Here's my plan for how we could do this in D10+:

    • deprecate FieldStorageDefinitionInterface::isMultiple() and FieldStorageDefinitionInterface::getCardinality()
    • introduce FieldStorageDefinitionInterface::isStorageMultiple() and FieldStorageDefinitionInterface::getStorageCardinality() to replace them
    • introduce FieldDefinitionInterface::isMultiple() and FieldDefinitionInterface::getCardinality() that would default to the new storage methods
    • the new methods above also solve the problem of BaseFieldDefinition, which implements both FieldStorageDefinitionInterface and FieldDefinitionInterface, so the storage-level cardinality would still have to be specified, but each bundle-level field definition could use a different cardinality (equal to or lower than the storage-level one)
    • write a detailed change record to explain the difference between the storage-level and field-level cardinality, and when each of them should be used (hint: the field-level cardinality is the one that should be used in most cases)

    This approach achieves the following goals:

    • before the existing methods are removed from core, contrib and custom module authors will get a heads-up that they have to change something
    • after the methods are removed from core (e.g. in 11.0), they will need to take this change into consideration and update their code accordingly

    @Wim Leers, re #99, note that core already defines a Count constraint based on the field storage cardinality in \Drupal\Core\Field\FieldItemList::getConstraints(), and it would just need to be updated to use the field-level cardinality instead.

Production build https://api.contrib.social 0.61.6-2-g546bc20