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?