- 🇩🇪Germany geek-merlin Freiburg, Germany
Imho this has been done with entity and field constraints, so tentatively closing.
Currently, Entity and Field logic is tied up in Field Widgets and Entity forms, which are of relatively no use to developers interacting with Drupal via a headless system that creates and/or updates Entities via an API. This causes developers to either re-write this logic in their headless application, on the REST endpoint in Drupal, or do nothing at all and allow users to set values without any form-like processing. Long term this is going to cause a lot of pain with development teams focused on content editing outside of Drupal.
A simple example of this is File fields - if I'm not using the normal File Field Widget and am uploading via REST, how am I supposed to validate a new upload? The configuration for validation (File extensions, max upload size, etc.) is set at the Field-level, so I would expect the FileItem Field Type to contain a generic "validate" method I can send a new upload to. I shouldn't have to interact with the Form API if I'm not using Drupal Forms, and Forms should only responsible for rendering the form and massaging its values so that it can be validated at a lower level.
In my opinion this is an important issue as it limits the Entity and Field API from properly taking in values from headless systems.
Move all Entity and Field specific logic out of forms into something abstracted from the Form API - I would imagine this would be done both at the Entity and Field level. This is a huge effort, and if people are interested and willing to help out we'll probably need to file issues for each individual Entity/Field to prevent reviewing a huge patch.
Discuss this kind of change and plan out the best way to address this.
None.
Possibly none. Forms should no longer be responsible for juggling Entity and Field values, but that doesn't necessarily mean that contrib modules will have to change their current methods.
None.
Closed: outdated
11.0 🔥
field system
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Imho this has been done with entity and field constraints, so tentatively closing.