Handle update and delete of Block component config entities

👍

This should add \Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\BlockComponentTest and test — by for example deleting a Menu config entity, which will result in \Drupal\system\Plugin\Derivative\SystemMenuBlock deriving one fewer block.

I bet there will be config dependency-related challenges 😇 In fact … I see that the necessary config dependencies are missing currently. For example:

uuid: 784eab71-dbfa-49da-b932-dc703a5de2f8
langcode: en
status: true
dependencies: {  }
label: 'Administration block'
id: block.system_menu_block.admin
provider: system
source: block
category: Menus
settings:
  plugin_id: 'system_menu_block:admin'
  default_settings:
    id: 'system_menu_block:admin'
    label: Administration
    label_display: ''
    provider: system
    level: 1
    depth: 0
    expand_all_items: true

😱

That

dependencies: {  }

should be

dependencies:
  config:
    - system.menu.admin

That is an oversight in bug when Block support was first added in 📌 Add support for Blocks as Components Active .

Adding dependencies fixes the menus case, but there are other cases where a block might change or disappear which needs additional work and test coverage.

Added additional test coverage for uninstalling a module that provides a block, and updating a block label.

There is the possibility that a block that previously met requirements (ie. it must be fully validatable) stops meeting those requirements, but is this realistically a case we need to handle? I added protection for it by deleting the block component if a reason exists that it is not valid, but unsure if it is worth contriving test coverage for this case.

Yay for 📌 Introduce unit test coverage for both ComponentSource plugins (Block + SDC) Active providing the appropriate place for this new test coverage!

I found a few problems in the MR, but I'm wondering if that's my brain still readjusting from the weekend? 🙈

Once config entities get dependencies, they automatically get deleted if the dependent entity is deleted - ie. if we depend on a menu and that menu ceases to exist, then the component will be deleted too. But we explicitly wanted to add the dependencies here, so what should we do? Prevent the menu from being deleted, or only have a soft dependency on the menu existing?

Right. 🤔

What I'd like to see in the test coverage is — somehow — verifying that there's a confirmation dialog when humans try to delete a menu, which would then inform the user that they're making this component obsolete.

But we explicitly wanted to add the dependencies here, so what should we do? Prevent the menu from being deleted, or only have a soft dependency on the menu existing?

I don't think we need to prevent it. But we need to ensure that we do not cascade it down: if a ContentTemplate depends on a Component that depends on a Menu, the current code is basically saying that Component and ContentTemplate will disappear on you! That's bad 😅

I think we should implement \Drupal\Core\Config\Entity\ConfigEntityInterface::onDependencyRemoval(), to prevent that? 😇

Same exact challenge appeared over at #3519168-10: Cannot delete JS components due to component depending on them → overnight! 😅

Yep was thinking whatever we implement here has to be done in a base class or trait and cascaded down to all our config entities.

IDK about all of XB's config entities — perhaps only Component::onDependencyRemoval() is sufficient to start. Because … how do we remove a component instance in a Pattern, PageRegion or ContentTemplate that itself contains other component instances?! 😅

I guess we could do it automatically if the component instance is provided by a ComponentSource that does not implement \Drupal\experience_builder\ComponentSource\ComponentSourceWithSlotsInterface?

FYI In 🐛 Cannot delete JS components due to component depending on them Active I've added a fallback plugin that can step in and continue to render children when a JS component is removed if any instance exist.

@longwave: I think there's still things here that make sense to land independently of 🐛 Cannot delete JS components due to component depending on them Active ?