Capture all reasons why particular SDC is incompatible

I ran across this scenario while exploring the component listing in admin/structure/component

• By default, the experimental component (components/sdc_statuses/experimental) is listed in the component listing and is active.
• Change the status of the component from experimental to obsolete in experimental.component.yml
• The component gets disabled in the component listing (Expected)
• The component gets added in the 'Disabled components' section (admin/structure/component/status) with reason "Component has "obsolete" status" (Expected)
• Changed the status back to experimental in experimental.component.yml
• The component will still be disabled in the component listing
• The component will still be present in the disabled components section with the same reason "Component has "obsolete" status" . Since the component is disabled, it should be listed under the 'Disabled components' section. But the reason is incorrect. I am not sure what reason to use in this case though. Already, there is a 'Manually disabled' reason. But that's also not quiet right for this scenario.

wim leers → credited el7cosmos → .

wim leers → credited longwave → .

Merged 📌 Display disabled Block components in /admin/structure/component/status Active into this, reason:

I'm 95% confident that this is a duplicate of 📌 Capture all reasons why particular SDC is incompatible Active .

Why?

Because for the disabled SDC-sourced Components to be listed at /admin/structure/component/status, XB's decorated SDC plugin manager stores the necessary information in the State service under the \Drupal\experience_builder\Plugin\ComponentPluginManager::REASONS_STATE_KEY key.

To make Block-sourced Components also get listed at /admin/structure/component/status, it'll also need to end up being stored in that same key-value pair.

Conclusion: to make the UI treat both ComponentSources the same, the infrastructure needs to change. Which inevitably requires touching the same code paths.

P.S.: this likely will also require refactoring experience_builder_block_alter() away in favor of XB decorating the Block plugin manager (just like it does for the SDC plugin manager).

— yours truly at #3484672-4: Display disabled Block components in /admin/structure/component/status →

Transferring issue credit.

When disabling a block component, it will get into \Drupal\experience_builder\Plugin\ComponentPluginManager::REASONS_STATE_KEY already.

This is the snippet that does this in \Drupal\experience_builder\Controller\ComponentStatusController::performOperation:

$reasons = $this->state->get(ComponentPluginManager::REASONS_STATE_KEY);
if ($op === 'disable') {
  $component->disable()->save();
  $reasons[$component->getComponentPluginId()] = 'Manually disabled';
}
...
$this->state->set(ComponentPluginManager::REASONS_STATE_KEY, $reasons);

But, this state will be rebuilt each time component plugin definitions are rebuilt, which only accounts for SDC source. Perhaps each component source can define its own state key for where to store its reasons, and then use \Drupal\Core\State\StateInterface::getMultiple for each component source in \Drupal\experience_builder\Controller\ComponentStatusController

But, this state will be rebuilt each time component plugin definitions are rebuilt, which only accounts for SDC source.

That's indeed the problem.

Perhaps each component source can define its own state key for where to store its reasons

I think it'd be better to not have each \Drupal\experience_builder\ComponentSource\ComponentSourceInterface implementation handle its own storage.

I think it'd be better to centralize that, and not store it in State anymore, which was also a concern surfaced by @larowlan in 📌 Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) Fixed .

I think that ideally, we'd expand the API surface of ComponentSourceInterface. But I'm not quite sure how yet.

I think this issue/MR might indeed be best served by doing what you state, and it should also move \experience_builder_block_alter() into a decorator for \Drupal\Core\Block\BlockManager, just like \Drupal\experience_builder\Plugin\ComponentPluginManager did for \Drupal\Core\Theme\ComponentPluginManager.

Do you think you could start tackling that, @el7cosmos? 😊 🙏

I can start with decorating the BlockManager.

Does storing the reasons in the component source definition make sense?

I can start with decorating the BlockManager.

Is storing the reasons in the component source definition make sense?

Bump! This would've allowed 📌 When demo_mode, limit component list to only SDCs, not blocks Active to be done differently.

@larowlan has actually independently implemented overnight an alternative to what this MR was aiming to do WRT storing reasons. But this MR so far contains zero LoC for the storing of reasons, only for making the Block component source auto-creation support better.

So, postponing this on ✨ Create a ComponentSource plugin for JS components Active , because it'll tackle a big chunk of the work this would need to do!

✨ Create a ComponentSource plugin for JS components Active landed, and indeed landed infrastructure that makes this a lot simpler! 🥳

f.mazeikis → changed the visibility of the branch 3473275-support-disabled-block to hidden.

f.mazeikis → changed the visibility of the branch 3473275-support-disabled-block to active.

Looking good, almost there! Can we also get a screenshot in the issue summary, demonstrating both the multiple reasons support and blocks appearing in the UI properly? 🙏

Addressed feedback.

Attaching some screenshots validating the following:

• disabling block component works
• manually disabled block components show up in the reasons list
• multiple incompatibility reasons for SDC components are listed
• enabling block component works

Thanks for the screenshots!

Last bits now :) See review on MR.

Resolved conflict with 🐛 Component names are double escaped Active , awaiting CI results.

With this about to land, next up in this area: 📌 Handle update and delete of Block component config entities Active .

Automatically closed - issue fixed for 2 weeks with no activity.