Problem/Motivation
In #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms), the SubFormState class was introduced for BlockPlugin's build/validate/submit callbacks, and additionally $form['settings'] (the sub form array) started getting passed to the build/validate callbacks, but not to the submit callback!
That means that $form is different in these two callbacks for everyone writing a BlockPlugin:
($form is $form['settings'] here)
public function blockValidate($form, FormStateInterface $form_state) {
($form is the complete/parent form here)
public function blockSubmit($form, FormStateInterface $form_state) {
Proposed resolution
We should fix this so that the $form argument passed to these callbacks is consistent.
Remaining tasks
Review the patch.
User interface changes
None.
API changes
The sub form is now passed to BlockPlugin's submitForm method, instead of the complete/parent form.
Data model changes
None.
| Comment | File | Size | Author |
|---|
Issue fork drupal-2948549
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
samuel.mortensonComment #3
idebr commentedAccording to Drupal\Core\Plugin\PluginFormInterface the $form is the complete plugin form. Should this change not be the other way around, so BlockForm::validateForm uses $form instead of $form['settings'] as the first argument?
Comment #4
tim.plunkettWhatever you pass to the method will be called $form, yes. If you see the
form()method in BlockForm, it passes an empty array tobuildConfigurationForm()which becomes $form to the plugin.This is the correct change, but a test is needed.
Comment #5
samuel.mortensonHere's a simple test.
Comment #12
abh.ai commentedRe-rolled patch and fixed test case.
Comment #13
tim.plunkettFixed failing tests.
Comment #14
abh.ai commentedComment #15
catchThis seems like a good bugfix, and I think it's fine for a minor release, but, we should have a change record since it's possible modules are relying on the existing behaviour.
Comment #16
claudiu.cristeaWe need this fix also in Layout Builder, in Drupal\layout_builder\Form\ ConfigureBlockFormBase::submitForm()
Comment #17
tim.plunkettYep I'd bet a lot of money that I copy/pasted that from BlockForm to here. Good catch
Comment #18
andypostIt may also throw deprecation when settings key used to catch old expectations
Comment #20
geek-merlinConsolidating subform related features and wtfs, as in IEF we're working on this.
Comment #21
megha_kundar commentedComment #22
tim.plunkettI don't see any difference between #21 and #13, can you explain @Megha_kundar?
Comment #25
super_romeo commentedDoes this patch still needed?
Comment #27
super_romeo commentedRerolled against D9.4.
Comment #29
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 200, following Review a patch or merge require as a guide.
Hiding the patches as the MR is the path forward for this ticket.
Verified the tests fail without the fix.
#16 appears to still be needed
Moving back to NW for that and the change record + release notes.
Comment #31
liam morland@super_romeo please edit the merge request so that it targets 11.x.
Comment #32
liam morlandI have updated the contents of the merge request so that they are on top of 11.x.
Comment #34
harjappan singh commentedHi! Are there any updates, or when is it planning to be shipped?