What happen if a provider is disabled but SDC were placed in XB ?

Created on 6 January 2025, about 2 months ago

Overview

As an editor and as a developer, I want to know what will happen to the content placed in XB if we switch and/or disable the provider.

In other words, I have a mycomponent SDC provided and I place it in an XB page.

  • If the SDC is provided by a theme, what happen if I want to uninstall the theme?
  • If the SDC is provided by a module, what happen if I want to disabled the module?

Original Slack thread here
.

Proposed resolution

TBD

User interface changes

TBD

🌱 Plan
Status

Active

Version

0.0

Component

Page builder

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @matthieuscarset
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    First: disabling modules does not exist in D8+, only in D7-. In D8+, a module is either installed or uninstalled, not installed and enabled or disabled.

    Uninstall is prevented thanks to XB's Component config entity declaring explicit config dependencies on a theme/module providing an SDC that is being used!

    That's exactly why XB uses Component config entities under the hood.

    Read more about it at https://git.drupalcode.org/project/experience_builder/-/blob/0.x/docs/co... — although I'm sure the docs can be improved to stress this further.

    The same thing is true for the field type plugins used to populate an SDC's props: the Component config entity has a config dependency on all modules whose field types are used by a Component config entity, thus preventing the module providing the field type getting uninstalled. See FieldTypeUninstallValidatorTest, introduced by 📌 Prevent modules from being uninstalled if they provide field types used in an Experience Builder field Fixed . We could repeat/generalize that test coverage to also explicitly test SDCs getting removed.

    All this means that long-term, we could implement \Drupal\Core\Config\Entity\ConfigEntityInterface::onDependencyRemoval(), and provide a UX for automatically transitioning/migrating/upgrading to another SDC. The logic in FieldTypeUninstallValidator proves it's possible to query across all XB field data.

    Also related: 📌 [PP-2] Add ComponentAuditabilityTest Active .

    Does that answer your question?

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • Thank you! It does answer my question for modules. I assume the behavior is the same for SDCs provided by themes - preventing themes from being uninstalled if it provides a SDC used in at least one XB field instance.

    I think this will be an issue when we will upgrade Drupal sites with a lot of XB field instances - nobody will be able to uninstall old modules or themes because there will be old components using at least one of their SDC.

    But this will happen in far future from now and there will hopefully be some

    UX for automatically transitioning/migrating/upgrading to another SDC
  • 🇦🇺Australia pameeela

    Sounds like this is covered then!

Production build 0.71.5 2024