Problem/Motivation
In a similar vein as #2256355: Make block plugins usable outside the block entity context...
\Drupal\block\BlockForm is part of the block entity, and happens to always know which theme it will be used by.
Block plugins are themselves not able to know what theme they'll appear in.
The only block plugin relying on this is SystemBrandingBlock.
Amusingly demonstrated in https://www.youtube.com/watch?v=4JMMQW2Vnws
Proposed resolution
Do not put the theme in the $form_state
SystemBrandingBlock doesn't need to link directly to the theme, the appearance page is enough.
Remaining tasks
N/A
User interface changes
The system branding block form links to admin/appearance/settings still, but not admin/appearance/settings/{theme}
API changes
Block plugin forms no longer have access to the theme.
Release notes snippet
Block plugin forms no longer get a 'block_theme' key in form state. See the change record for more details.
Comment | File | Size | Author |
---|---|---|---|
#25 | 2268787-block-25.patch | 2.9 KB | tim.plunkett |
#19 | 2268787-19.patch | 2.99 KB | tim.plunkett |
#19 | interdiff.txt | 543 bytes | tim.plunkett |
#17 | 2268787-17.patch | 2.75 KB | tim.plunkett |
#13 | block-2268787-13.patch | 2.21 KB | tim.plunkett |
Comments
Comment #1
tim.plunkettComment #2
dawehnerWhy can't we at least try to fetch additional information from the current request and fallback in case we can't find out the theme?
Comment #3
tim.plunkettBecause its not about the theme used by the current request at all?
When you configure blocks for Bartik, you're still using the admin in Seven.
And we can't couple it to the route, since other usecases for configuring block plugins would have nothing in the route about the theme...
Also, it's just not worth it for a little bit of help text.
Comment #4
dawehnerOh, well I talk about the URL in which the theme should be encoded, isn't it?
Comment #5
tim.plunkettNo, the URL is built by the Block UI, which is not the same URL when a block is configured in the Page Manager UI.
If a block needed the theme during runtime, we could try declaring it as a context. But that's not the case here, it was just a helpful link in the admin UI that really wasn't that helpful.
Comment #6
cdracars CreditAttribution: cdracars commented1: block-2268787-1.patch queued for re-testing.
Comment #8
cdracars CreditAttribution: cdracars commentedPatch Re-Rolled.
Comment #9
cdracars CreditAttribution: cdracars commentedComment #13
tim.plunkettComment #14
tim.plunkettComment #17
tim.plunkettReroll.
Comment #19
tim.plunkettForgot to hit paste after hitting cut :)
Comment #20
mgiffordPatch no longer applies.
Comment #25
tim.plunkettPlease tag "Needs reroll" next time, thanks!
Comment #26
tedbowre @dawehner's comment in #2
and @tim.plunkett's response in #3
Should we make a follow up to add the link to
\Drupal\settings_tray\Form\SystemBrandingOffCanvasForm::buildConfigurationForm
?Because when using the 'settings_tray' plugin form then the current request's theme is the theme they would want to change the logo for.
Comment #34
JeroenTPatch still applies.
The same error occurs in Block field:
#3119245: Some blocks require a block_theme value.
Patch in #25 fixes the problem.
Comment #36
catchConsidered asking for test coverage for this, but while it's possible to end up with a system branding block bug in contrib, this feels like just refactoring form structure in core itself and existing test coverage should suffice.
Also agreed that linking to the appearance page is enough here.
Committed 62430b7 and pushed to 9.3.x. Thanks!
Comment #37
alexpottAre we concerned about the modules in contrib that rely on this? See http://grep.xnddx.ru/search?text=%24form_state-%3Eget%28%27block_theme%2... - they all have Drupal 9 compatibility.
Comment #38
catchI don't think we should revert due to that, form structure is internal according to the bc policy, but let's at least add a change record.
Comment #39
catchChange record and release notes snippet added.