Problem/Motivation
The new LanguageItem's value should only be allowed to contain a valid language code. Currently, the property definition of the 'value' property is set to "string". There should be additional logic to capture invalid language codes.
Proposed resolution
See if this can be fixed by implementing a getConstraints() method in the LanguageItem class by using the OptionsProviderInterface.
Remaining tasks
- Write failing test that attempts to set an invalid language code
User interface changes
- None
API changes
- None
Original report by @mauzeh
Comment | File | Size | Author |
---|---|---|---|
#15 | 2350843-language-field-item-type-15.patch | 5.72 KB | vijaycs85 |
#15 | 2350843-diff-13-15.txt | 1.58 KB | vijaycs85 |
Comments
Comment #1
mauzeh CreditAttribution: mauzeh commentedComment #2
mauzeh CreditAttribution: mauzeh commentedI'm at the sprint at DrupalCon Amsterdam, I'm going to write the test that attempts to set an invalid language code.
Comment #3
mauzeh CreditAttribution: mauzeh commentedAdded failing test.
Comment #5
mauzeh CreditAttribution: mauzeh commentedAdded constraint validation.
Comment #6
mauzeh CreditAttribution: mauzeh commentedChanged / improved inline documentation.
Comment #7
mauzeh CreditAttribution: mauzeh commentedComment #11
yched CreditAttribution: yched commentedAdding tags.
Also, I have no clue whether this is a good thing to do or if all hell will break lose, but if we do this, it should be done by having LanguageItem implement OptionsProviderInterface.
Comment #12
yched CreditAttribution: yched commentedUpdated summary with the OptionsProviderInterface approach.
Comment #13
mauzeh CreditAttribution: mauzeh commentedRewrote the patch, the LanguageItem now implements OptionsProviderInterface.
I'm not too happy about simply calling \Drupal::service('language_manager'); in order to retrieve the list of allowed languages. Feels dirty to access a global scope. Perhaps there is a better way of doing it?
Comment #15
vijaycs85#13 - How about this one?
Comment #17
Gábor HojtsyFieldItemBase also uses
\Drupal::entityManager()
directly already. Don't seem like there would be a way to inject services in a straightforward fashion.Still several fails on existing tests. EntitiyValidationTest and UserValidationTest. Invalid languages used?
Comment #18
Gábor HojtsyClearly nobody is working on this.
Comment #22
dagmarReferenced from #2872790: Deprecate \Drupal\Core\Field\FieldItemBase::generateSampleValue.