- Issue created by @wim leers
π Implement fallback plugin for Block plugins Fixed introduced:
\Drupal\Core\Block\Plugin\Block\Broken
class BlockManager extends DefaultPluginManager implements BlockManagerInterface, FallbackPluginManagerInterface {
β¦
public function getFallbackPluginId($plugin_id, array $configuration = []) {
return 'broken';
}
β¦
}
Which means that ANY invalid block plugin ID in a block config entity automatically falls back to this broken
block plugin.
The primary purpose was to make it possible to install block
config entities while the corresponding block_content
content entity does not yet exist, and hence allow referencing block_content:<UUID>
block plugins to automatically fall back to the broken
plugin ID.
But β¦ this is VERY broad. Too broad in many cases. So broad that it makes validating block
config entities less meaningful π This became clear in
#3362457-17: Fix all PluginExistsConstraint constraint violations in tests β
.
But changing this is hard now, because there could be other block plugins in contrib/custom that have similar π± [meta] Deploying configuration that depends on content Active -style needs. Still, we should aim to narrow this.
See
#3362457-17: Fix all PluginExistsConstraint constraint violations in tests β
: run \Drupal\Tests\block\Kernel\BlockValidationTest::testInvalidPluginId()
and observe how a nonsencial plugin ID does not trigger any validation errors.
For contrast, see \Drupal\Tests\editor\Kernel\EditorValidationTest::testInvalidPluginId()
, where a validation error is triggered.
public function getFallbackPluginId($plugin_id, array $configuration = []) {
// Provide fallback for `block_content:*` blocks.
// @see \Drupal\block_content\Plugin\Block\BlockContentBlock
// @see \Drupal\block_content\Plugin\Derivative\BlockContent
if (str_starts_with($plugin_id, 'block_content:')) {
return 'broken';
}
// No fallback for anything else.
return $plugin_id;
}
public function getFallbackPluginId($plugin_id, array $configuration = []) {
// Provide fallback for content-dependent block plugins.
// @see \Drupal\block_content\Plugin\Block\BlockContentBlock
// @see \Drupal\block_content\Plugin\Derivative\BlockContent
foreach ($this->getContentDependentBlockPluginTypes() as $base_plugin_id) {
if (str_starts_with($plugin_id, "$base_plugin_id:")) {
return 'broken';
}
}
// No fallback for anything else.
return $plugin_id;
}
This needs some mechanism to identify the content-dependent block plugin types to allow contrib/custom block types to get the same behavior. Suggestion: do this via an annotation on block plugin types.
TBD
TBD
TBD
TBD
TBD
Active
11.0 π₯
Last updated
Makes Drupal easier to use. Preferred over UX, D7UX, etc.