Disabled SDC components are re-enabled after cache rebuild

Hello @heyyo

I attempted to replicate the issue, but as per the description everything seems to be working as expected.

Here are the steps I followed:
1. I manually disabled one of the components via /admin/appearance/component.
2. The component correctly appeared under the Disabled Components tab at /admin/appearance/component/status.
3. I cleared the cache both via Drush and through the UI at /admin/config/development/performance. The component remained disabled as expected.

However, I did notice an inconsistency:
When I disabled the component, it was correctly listed under the Disabled Components tab, but it was not removed from the Enabled Components tab. As a result, the component appeared in both tabs simultaneously, which could be misleading.

This seems to indicate a UI or rendering issue where the list of enabled components is not being updated properly after a change.

Please can you help me with more details on it.

Thanks.

I'm able to reproduce the same behaviour as @jatingupta40 - disabling an SDC component shows that component in both lists. Interestingly under "disabled components" the status for the component shows as "Incompatible" but the reason shows as "Manually disabled" I think that the status here maybe at least part of the problem and it should be marked as "Disabled" and not "Incompatible".

Just yesterday I happen to have worked on this code in 📌 Version component prop definitions for SDC and Code components Active — the place to update is src/Plugin/ExperienceBuilder/ComponentSource/SingleDirectoryComponent.php.

Great find!

We're definitely lacking test coverage for this. I think a new ComponentSourceTestBase::testUpdateDiscovery() would probably make sense?

Exact steps with latest dev:

0. Check the status property of the SDC Druplicon with drush, we see status: true
drush cget experience_builder.component.sdc.experience_builder.druplicon
1. Disable druplicon in UI : /admin/appearance/component.
2. check again the status property. As expected status turned now to false
You can also the SDC component is not available anymore in XB UI
drush cget experience_builder.component.sdc.experience_builder.druplicon
3. execute drush cr
4. check again the status property. Status turned back to true !
drush cget experience_builder.component.sdc.experience_builder.druplicon

Thanks @heyyo for the descriptive steps.
I have checked the scenario as per #5, and now i can reproduce the issue.

I've found the code that looks to have been causing this, it was recently changed. I've created an MR to run all the tests and will need further testing, its likely it'll need more logic rather than just removing the enable function.

All the tests look good. Assigning to myself to look at adding a test for this next.

This elegantly fixes a confusing behavior 👍

Minor lingering concern that needs a minor follow-up:

1. I've got a module foo installed that provides a hello SDC
2. if I uninstall foo, then the sdc.hello Component config entity will be disabled by \Drupal\experience_builder\Entity\Component::onDependencyRemoval()
3. if I now reinstall foo because I realize my mistake, then sdc.hello will start working again … but it will not appear in the list of available components in the UI anymore, because it remains disabled

Follow-up created: 📌 `Component::onDependencyRemoval()` should store the reason for disabling that component Active .

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