- π³π±Netherlands Web-Beest
I've got the same problem as well (in need of facets that can be disabled when needed). I've found one little issue in the code; when the facetblock is built, it returns an error because the facet is not active.
`Warning: Undefined array key "[facet_id]" in Drupal\facets\FacetManager\DefaultFacetManager->processBuild() (regel 323 van /app/web/modules/contrib/facets/src/FacetManager/DefaultFacetManager.php)`
This is due to the fact that the facet hasn't been built yet, but isn't available in the list of facets because it's not loaded. So I've added a check in FacetBlock::build that checks the facet status and returns an empty array if disabled.
- π³π±Netherlands Web-Beest
Fix for broken blocks. This patch lets the FacetManager load all the blocks (disabled or not) but disables the rendering of the block that uses that facet. This way you can configure the blocks for all facets, but select which block should be rendered by disabling the facet.
- Status changed to Needs work
about 1 year ago 1:26pm 10 April 2024 - πΊπΈUnited States smustgrave
Probably would be good to get test coverage for this one.
- π΅πͺPeru krystalcode
I think that it is important to keep the change in
getEnabledFacets
for performance reasons. Facets withstatus: false
should be filtered out. If you look at theinitFacets
, the manager still not only loops over all facets but it actually instantiates all of its processors and even runs its pre-query processing - this looks like a bug. For Drupal core, if you have the "status" in the entity keys - which is the case here, then that config entity is considered to be disabled.On complex, multi-domain or multi-site applications, there can be hundreds of facets as stated in the issue description.
If there are issues elsewhere related to config e.g. blocks etc., I think it is best to handle them in different ways e.g. config splits, domain config overrides etc.