Problem/Motivation
@tim.plunkett in #2782891-61: The Page Title block's title behaves in a confusing way with Settings Tray and the Help block incorrectly has Settings Tray styling:
+1, but can you open a follow-up to discuss the differences and a way to resolve them? As the only implementation of this, we need to be clear about how others should use multiple forms
This is that follow-up. We need to clarify these things (quoting @tim.plunkett again, from #2782891-59: The Page Title block's title behaves in a confusing way with Settings Tray and the Help block incorrectly has Settings Tray styling):
+++ b/core/modules/outside_in/outside_in.module @@ -100,8 +100,16 @@ function outside_in_entity_type_build(array &$entity_types) { + if (\Drupal::service('plugin.manager.block')->createInstance($variables['plugin_id'])->hasFormClass('off_canvas')) { +++ b/core/modules/outside_in/src/Access/BlockPluginHasOffCanvasFormAccessCheck.php @@ -0,0 +1,29 @@ + return AccessResult::allowedIf($block_plugin->hasFormClass('off_canvas'));Now that I look again, there's even more robust fallback code in \Drupal\Core\Plugin\PluginFormFactory::createInstance(). These two different has FormClass checks are different, and that is odd. Not the fault of this code though...
+++ b/core/modules/outside_in/outside_in.module @@ -139,17 +147,40 @@ function outside_in_toolbar_alter(&$items) { + // Otherwise fall back to the built-in form for the block plugin. + default: + $definition['forms']['off_canvas'] = $definition['class']; + break;This is an interesting change from HEAD.
\Drupal\Core\Plugin\PluginWithFormsTrait::getFormClass() already provides it's own fallback mechanism, and in HEAD that is relied upon. This changes it so that we explicitly declare the "configure" form as used by "off_canvas" operation.
This isn't bad, but possibly slightly confusing.
That said, the entire concept of multiple plugin forms was added to core to support off_canvas.
Proposed resolution
TBD
Remaining tasks
TBD
User interface changes
None.
API changes
None.
Data model changes
None.
Comments
Comment #14
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!