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

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.

Comments & Activities

Not all content is available!

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

Comment about 1 year ago →
🇺🇸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.
Comment 6 months ago →
🇮🇹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 → .
Comment 5 months ago →
🇷🇴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.