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.The hooks for instance and widget settings, hook_field_widget_settings_form() and hook_field_instance_settings_form() both return form arrays, but receive no information at all about the larger form they're inserting into.
This means that they can't add more complex behaviours such as dependencies and ajax -- hook_form_alter has to be used instead.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | form-state-for-field-api-1391196-12.patch | 21.89 KB | larowlan |
| #12 | form-state-for-field-api-1391196-12.interdiff.txt | 1.23 KB | larowlan |
| #10 | form-state-for-field-api-1391196-10.patch | 21.85 KB | larowlan |
| #10 | form-state-for-field-api-1391196-10.interdiff.txt | 2.91 KB | larowlan |
| #8 | form-state-for-field-api-1391196-8.patch | 21.37 KB | larowlan |
Comments
Comment #1
yched CreditAttribution: yched commentedThat's true - cannot wrap a patch myself right now, so any takers welcome :-)
Though, note that introducing a $form param means the code in the existing hook implementations will need to be adapted, since most of them use $form as the name of the sub-element that the hook builds and return (in some cases, initializing $form as an empty array first thing). This internal var should be renamed $element or something.
Comment #2
joachim CreditAttribution: joachim commentedOh I hadn't thought of that.
$element to me implies a single form element which could be confusing perhaps?
How about $settings_form?
Comment #3
yched CreditAttribution: yched commented$element is already used in other parts of drupal to identify "a subpart of a form / render array", I think.
+ that's also what core hook_field_formatter_settings_form() implementations use (because this hook does receive $form and $form_state :-/)
Comment #4
larowlanI'll tackle this, hit it today trying to get ajax behaviour on a settings form
Comment #5
larowlanAssume this is not back-portable?
Comment #6
joachim CreditAttribution: joachim commented> Assume this is not back-portable?
It depends. If you add the new parameters to the end, then yes, it can be backported, as older implementations of the hook simply won't care.
Comment #7
larowlanWill add params at end.
Comment #8
larowlanFirst cut
Comment #10
larowlanTake two ditching module_invoke so we can pass form_state by reference.
Comment #12
larowlanComment #13
CBLooks good to me!
Comment #14
tim.plunkettThis should have automated tests.
Comment #15
larowlanHey Tim
Can you give me an example of how the tests should go here?
Testing ajax functionality on instance_settings_form? or is that too over the top.
LR
Comment #16
larowlanUnless I'm mistaken, this is no longer relevant to D8 as Widget As Plugins has replaced many of these hooks (and the class methods pass $form and $form_state).
Any objections to setting this back to D7 and setting status as 'Patch needs port'?
Comment #17
yched CreditAttribution: yched commentedWidget settings forms have been taken care of in D8 with the "widgets as plugins" patch, but field and instance settings forms haven't yet. They will be, but not in the next couple weeks.
So strictly speaking, a D8 patch should still include the fix for those, and then #12 can be rerolled as a D7 patch.
Comment #18
swentel CreditAttribution: swentel commentedField types are no plugins, so this doesn't apply anymore to D8. I'm not even sure whether we can change those function signatures in D7 though ... feels like a won't fix to me.
Comment #19
larowlanComment #20
mstrelan CreditAttribution: mstrelan at PreviousNext commentedDiscussed this with @larowlan and we agreed this is won't fix as per #18. The lack of interest over the past 9 years solidifies that case.