When an entity delete form implements ContentEntityConfirmFormBase the validation of field constraints will still happen. In case the entity fields data is not valid anymore the deletion will not happen, moreover it ends up with "... NestedArray::getValue() must be of the type array, null given ..." as the form element is not present.
You can reproduce as follows:
- For a content type add link field and create a node with correct url
- Update the url directly in the database to make it invalid
- Try to delete the node
Make the ContentEntityConfirmFormBase prevent the validation of field constraints.
-
-
-
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | no-validation-2232321-6.patch | 664 bytes | berdir |
Comments
Comment #1
blueminds commentedComment #2
berdirComment #3
sunThis reminds me a lot of #588550: Allow the user edit form to only ask for the current password when necessary (in a followup confirmation step)
The very old/experimental approach over there tried to fully remove the separate concept of confirm forms, and instead, make the form that needs confirmation dynamically rebuild + adjust itself to
That was for a more complex case of a confirmation form though (changing your password requires to confirm with your current password).
Aside from that, isn't the concrete case here going to be fixed by #216064: Entity form "Delete" button triggers server-side + HTML5 form validation; change "Delete" button to a link ?
Comment #4
berdirEntity confirm forms are often displayed on separate pages, it is not something that happens as part of a form submission, so no, it's not really related to that.
Comment #5
amateescu commented#2235457: Use link field for shortcut entity is now blocked on this, so updating the priority to match the other one.
Comment #6
berdirI think this is all we need here?
We'll need test coverage however. Maybe it's easier to just merge this into the shortcut issue as it needs it to work?
Comment #7
amateescu commentedDone :)