Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Greetings! I am running into an issue porting a module to Drupal 8 that uses the Field API. The issue is that the value my field provides is stored as a string, but at validation time, it is composed of several values that will be coerced into a string during preSave. Since it looks like TypedDataManager places the PrimitiveType constraint on all fields which extend FieldItemBase, it causes PrimitiveTypeConstraintValidator to run against your field, even if you specify a custom constraint in the @FieldType annotation.
I'm attaching a patch that will help to describe the problem by proposing a simplistic solution. I don't know if this is robust enough, but it should at least illustrate the problem a little better. The suggestion is for TypedDataManager::getDefaultConstraints() to not add the PrimitiveType constraint to all primitive types. Rather, let the fields define the constraint themselves.
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drupal-allow-constraint-overrides-2333733-1.patch | 4.71 KB | Kevin Hankens |
Comments
Comment #1
Kevin Hankens CreditAttribution: Kevin Hankens commentedComment #2
dawehnerLet's have a look what the testbot thinks. It seems odd that you don't do that kind of work on a widget level, but yeah maybe you have a proper usecase.
Comment #4
vitalie CreditAttribution: vitalie commentedI think one could apply some massage to the form values as an alternative solution, to make sure that returned value is of the necessary PrimitiveType.
See: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Field!WidgetBase....
Comment #9
longwaveThis came up as random bug of the day in the Bug Smash Initiative.
I'm not sure if this is actually a bug; if your value isn't strictly a primitive then should you be implementing PrimitiveInterface?
PrimitiveTypeConstraintValidator then does checks based on type, so if you're implementing StringInterface but your value isn't a string, I think it is right for it to fail. You could still implement PrimitiveInterface but none of the core child interfaces, and PrimitiveTypeConstraintValidator would be a no-op in that case as it fails safe if it doesn't know the type.
Comment #10
quietone CreditAttribution: quietone at PreviousNext commentedSince we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). See the question asked in #9. If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #12
smustgrave CreditAttribution: smustgrave at Mobomo commentedReading the explanation in #9 seems correct. Think this is good to close. If still an issue please reopen.