\Drupal\Core\Field\FieldConfigInterface::addConstraint()'s docs say:
* Note that constraints added via this method are not stored in configuration
* and as such need to be added at runtime using
* hook_entity_bundle_field_info_alter().
This means it's required to have a module to add a constraint (because you need a module to implement that hook). It's also rather misleading.
Similar problems have been fixed in #2247085: Constraints cannot be added to configurable fields and #2541228: FieldConfigBase::setPropertyConstraints() and addPropertyConstraints() are broken.
It should be possible to add constraints via FieldConfig config entities and have those constraints be stored.
TBD
None.
None.
FieldConfig config entities now store constraints.
Comments
Comment #2
wim leersDiscovered in #2821077-49: PATCHing entities validates the entire entity, also unmodified fields, so unmodified fields can throw validation errors.
Comment #3
amateescu commented#2247085-6: Constraints cannot be added to configurable fields is why constraints are not stored in the field config objects. And, as far as I know, nothing changed in the land of constraints since then to invalidate that point.
Comment #4
wim leersTo quote @Berdir from #2247085-7: Constraints cannot be added to configurable fields:
So clearly this can't be solved today. But … isn't this something we need to do eventually?
Comment #5
dawehnerI think its actually a fair behaviour right now. By default the behaviour of a field is basically defined by the field type + configuration for this field type. Once you are able to add validations on configuration time, we basically integrate another dimension into this behaviour by default, aka. the plugin system around validation.
On top of that you want to do something special when you add validations, and as such I think custom code is not as bad as people think it is.
Comment #6
amateescu commented@dawehner is correct, as always :) I vote for "Closed (works as designed)".
Comment #9
ghost of drupal past> Ouch, schema
That ouch is band-aid'd by #2264179: Clarify use of property/undefined and add an ignore type in configuration schema. We can do this. ignore for the win.
Comment #10
wim leers#9: Does that mean you're in favor of doing what this issue proposes? What are your thoughts about @dawehner's concerns in #5 and @amateescu's confirmation of those concerns in #6?
Comment #11
ghost of drupal pastMy use case is restricting the contents of some link fields. I guess I can use
hook_entity_bundle_field_info_alter... I guess the point of making addConstraint store would be to allow the UI add these constraints ... and that might not be that import to us at least. I guess I am also fine with just closing this then. Although , as with everything else, it's utterly not clear whether changeshook_entity_bundle_field_info_alterneed an update hook or not :( I am completely lost ever since entup was removed.Comment #12
amateescu commentedConstraints don't affect the storage in any way, so using
hook_entity_bundle_field_info_alter()for that doesn't need an update hook :)