Problem/Motivation
Some layout plugins choose to provide configuration forms.
Those are form_alter-able by custom code.
However, if a layout plugin does not provide its own form, custom code can't do anything about it without swapping out the plugin class itself.
Proposed resolution
This is what PluginWithFormsInterface is for!
Add that to LayoutDefault (the 99.9% use case) and it will allow custom code to alter the layout definition to provide a form for them, without messing with their plugin class.
Remaining tasks
Write tests
User interface changes
API changes
None. LayoutInterface is not changed here (ideally we'd be able to, but erring on the side of no API addition)
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #35 | interdiff-34-35.diff | 1.57 KB | jurgenhaas |
| #35 | 3043879-35.patch | 8.95 KB | jurgenhaas |
| #34 | interdiff-33-34.diff | 2.31 KB | jurgenhaas |
| #34 | 3043879-34.patch | 8.91 KB | jurgenhaas |
| #33 | interdiff-MR-33.diff | 7.88 KB | jurgenhaas |
Issue fork drupal-3043879
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
tim.plunkettUntested patch
Comment #3
bkosborne+1 to this.
This lowers the barrier for a contrib module that wants to allow adding a CSS class to any layouts used on a site, without also defining the layout plugin class.
Comment #4
tim.plunkettPluginWithFormsTrait needs to respect PluginDefinitionInterface (instead of assuming an array)
Comment #6
tim.plunkettStill needs tests, but here's the fix for above
Comment #7
tim.plunkettComment #8
tim.plunkettNW for the tests
Comment #10
rromore commented#6 no longer applies, I'm guessing because of commit 3003cc65 for issue #3073872. Adding updated patch.
Comment #11
rromore commentedLooks like I accidentally left an extraneous '!' which was causing the section config form link not to appear.
Comment #13
tim.plunkettAdded a test. The FAIL patch is equivalent to an interdiff
Comment #15
tim.plunkettDiscussed more with @bkosborne and he helped clarify how to test this.
In order to allow custom code to affect all layout plugins, this requires a change to LayoutInterface. This has a 1:1 mapping to LayoutDefault, and there is a trait available. Added full test coverage for this too.
Comment #18
tim.plunkettNeeds to check if the one plugin we don't control exists
Comment #19
bkosborneThank you for your work on this. I have a very busy week coming up, but I added this to my TODO list to test if this will work well with the layout builder styles module after this week is over.
Comment #20
tim.plunkettMinor reroll for some
usestatement conflicts after #3143635: Change Layout Preparation into an Event to allow proper alterations.Comment #22
jurgenhaasMinor reroll for the test module.
Comment #24
jurgenhaasMinor re-roll for 9.2.x
Comment #25
jurgenhaasAnother re-roll as I missed one broken junk.
Comment #28
tim.plunkettRebased and switched to using an MR
Comment #31
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #33
jurgenhaasThe MR doesn't apply for 11.x or 10.3.x so I did a re-roll. Uploading as a patch since I'm not sure if we want to create a new MR for this or if we change the existing MR to target 11.x
Comment #34
jurgenhaasRe-rolled again by removing some tests that conflicted with upstream changes.
Comment #35
jurgenhaasAnother re-roll.