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.
There are certain modules that only need and want to work with newly saved content (system objects) after a UI-based submission - disregarding programmatic insertions.
I always wondered why we cannot simply make this information available to form submit handlers that run after the primary submit handler.
Comment | File | Size | Author |
---|---|---|---|
#8 | drupal.confirm-delete-entity-id.8.patch | 5.43 KB | sun |
#5 | drupal.form-submit-save-entity-id.5.patch | 3.44 KB | sun |
drupal.form-submit-save-entity-id.0.patch | 3.62 KB | sun | |
Comments
Comment #2
Dries CreditAttribution: Dries commentedNot sure we need to save both the object and the object ID. Either way, I agree that this is the right thing to do.
IMO, it should be a best practice because it avoids a lot of ugly code in contributed modules. If we think it is a good best practice, it might be good to document this in
form.api.php
.Update: oops, there is no
form.api.php
yet, it seems. Can't have everything in one release, I guess. ;-)Comment #5
sunI realized that we need to revamp the entity handling in $form_state in #367006: [meta] Field attach API integration for entity forms is ungrokable anyway, so populating $form_state[$entity] here makes no sense.
So this one just populates the entity id in the values after saving.
Comment #6
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD.
Comment #8
sunI need the same to happen for entity delete confirmation forms. That's partially in place already, but not consistently for all forms.
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedlooks reasonable to me.
Comment #10
webchickCommitted to HEAD, thanks.
I suppose there's no way to programmatically derive the key field (for example, via schema API)? This is something that 99.9% of module developers are going to forget to do. :\