Implement hierarchical structures in facets

THNX! :D

Next week I'll test this is our D8 project.

Also attributing @aspilicious for this patch per feedback on irc.

1. +++ b/src/Annotation/FacetsHierarchy.php
   @@ -0,0 +1,44 @@
   + * @see \Drupal\facets\Processor\ProcessorPluginManager
   

   c/p remnant.

2. +++ b/src/Entity/Facet.php
   @@ -100,6 +102,20 @@ class Facet extends ConfigEntityBase implements FacetInterface {
   +   * @var array
   

   Of what is this an array, can we add a more descriptive annotation?

3. +++ b/src/Entity/Facet.php
   @@ -100,6 +102,20 @@ class Facet extends ConfigEntityBase implements FacetInterface {
   +   * @var \Drupal\facets\Hierarchy\HierarchyPluginBase
   

   Is there an interface we can use to hint on instead?

4. +++ b/src/FacetManager/DefaultFacetManager.php
   @@ -366,4 +389,19 @@ class DefaultFacetManager {
   +  protected function buildHierarchicalTree($keyed_results, $parent_groups) {
   

   This needs some docs.

5. +++ b/src/Hierarchy/HierarchyInterface.php
   @@ -0,0 +1,23 @@
   +interface HierarchyInterface {
   ...
   +  public function getParentIds($id);
   ...
   +  public function getNestedChildIds($id);
   

   Needs docs as well.

6. +++ b/src/Hierarchy/HierarchyPluginBase.php
   @@ -0,0 +1,23 @@
   +    $request = $container->get('request_stack')->getMasterRequest();
   

   Is there a reason why we use MasterRequest instead of CurrentRequest here? I'm actually not very sure what the difference is. So maybe just ignore this

7. +++ b/src/Plugin/facets/hierarchy/Taxonomy.php
   @@ -0,0 +1,94 @@
   +  public function getNestedChildIds($id) {
   +    $children = &drupal_static(__FUNCTION__, []);
   

   Nice that this is cached!

8. +++ b/src/Plugin/facets/hierarchy/Taxonomy.php
   @@ -0,0 +1,94 @@
   +      $subchilds = [];
   

   I'm not sure about subchilds, maybe grand_children makes more sense?

9. +++ b/src/Plugin/facets/hierarchy/Taxonomy.php
   @@ -0,0 +1,94 @@
   +  protected function taxonomy_get_parent($tid) {
   ...
   +    $parent = &drupal_static(__FUNCTION__, []);
   

   Nice that this is cached as well, but let's make this camelCase

10. +++ b/src/Plugin/facets/url_processor/QueryString.php
    @@ -97,6 +97,17 @@ class QueryString extends UrlProcessorPluginBase {
    +          // If hierarchy is active, unset parent trail and every child when
    +          // building the enable-link to ensure those are not enabled anymore.
    

    This is a perfect comment!

I mostly looked at how this was built architecturally, but I don't see anything that I'd change, very cool!

css file is missing

Overall this looks great, still needs tests and some battle-testing.

cleanup attached.

1. +++ b/css/hierarchical.css
   @@ -0,0 +1,3 @@
   +.block-facets ul ul li {
   +    margin-left: 10px;
   +}
   

   Is there a way we can do this just on the li class instead of doing this?

2. +++ b/src/Entity/Facet.php
   @@ -261,6 +299,18 @@ class Facet extends ConfigEntityBase implements FacetInterface {
   +    $container = \Drupal::getContainer();
   +
   +    return $this->widget_plugin_manager ?: $container->get('plugin.manager.facets.hierarchy');
   

   can we change this to return $this->widget_plugin_manager ?: \Drupal::service('plugin.manager.facets.hierarchy');

3. +++ b/src/Entity/Facet.php
   @@ -319,6 +369,45 @@ class Facet extends ConfigEntityBase implements FacetInterface {
   +    return $this;
   

   Most of our setters don't return $this, so let's remove this.

Patch at #23 partially failed because I implemented https://www.drupal.org/node/2784349#comment-11707151 .

This is probably to be expected, but just wanted to warn you all the same :)

For the rest I can confirm it seems to work as expected, building a term tree and allowing the facet to filter on the term chosen.

Done!

#28 still needs to be addressed.

Resolves #28.

This still needs tests, but I think we should probably get #2815187: Cleanup entities and write kernel tests for them in first, so we can add a kernel test as wel as integration tests.

back to NR

It works :).
For some reason I had to rebuild the facet before it appeared, but hey it works now :)

A bug we found: When selecting "Always expand hierarchy", "Enable parent when child gets disabled" is also selected (wrong default value)

Fixed some docs.

Back to needs review, the fail was a random fail (AlreadyInstalledException)

Awesome work!

FYI: When using this patch in combination with the "current search" patch from #2735891, I no longer see the facet tree (only the root elements appear) and I get the following notice:

Notice: Undefined offset: 0 in Drupal\facets\Plugin\facets\url_processor\QueryString->buildUrls() (line 99 of modules/contrib/facets/src/Plugin/facets/url_processor/QueryString.php).
Drupal\facets\Plugin\facets\url_processor\QueryString->buildUrls(Object, Array) (Line: 65)
Drupal\facets\Plugin\facets\processor\UrlProcessorHandler->build(Object, Array) (Line: 297)
Drupal\facets\FacetManager\DefaultFacetManager->build(Object) (Line: 82)
Drupal\facets\Plugin\Block\FacetBlock->build() (Line: 203)
Drupal\block\BlockViewBuilder::preRender(Array)
call_user_func('Drupal\block\BlockViewBuilder::preRender', Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 151)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 152)
Drupal\Core\Render\Renderer->renderPlain(Array) (Line: 166)
Drupal\Core\Render\Renderer->renderPlaceholder('', Array) (Line: 659)
Drupal\Core\Render\Renderer->replacePlaceholders(Array) (Line: 544)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 139)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 140)
Drupal\Core\Render\Renderer->renderRoot(Array) (Line: 258)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->renderPlaceholders(Object) (Line: 131)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', Object) (Line: 184)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 652)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

@mpp: we probably shouldn't worry about that yet. I think this one'll go in before the other one, especially because this is being used in development on a couple of sites already and we haven't really heard anything that isn't working about this.

It works for me . But can i select all children on just select of a single parent and deselect all childrens on deselect of single parent . Is it feasible to achieve this kind of functionality

May be we could give flexibility for the users to have this option . If we are implementing this feature i can start working on this . This will be a "good to have" feature in facets . I would rather like to hear from experts though

Selecting children automatically would imply it needs to be tagged with a child too

Yes only the tagged childrens should get selected automatically when the parent is selected. And only the tagged children is visible on facets otherwise the term is not visible whichever is not tagged in facets

May be we could give flexibility for the users to have this option . If we are implementing this feature i can start working on this . This will be a "good to have" feature in facets . I would rather like to hear from experts though.

You did hear from an expert, @StryKaizer is exactly that. Anyway, I think that is something we can discuss in a follow-up. The only thing that this needs before committing is an integration test that tests this behavior. Let's try to get that written so we can commit this.

I tested out the processor here and came across one problem: Using the "translate entity " processor to change the taxonomy terms into back into their labels I am seeing the following error:

Error: Call to a member function getSetting() on null in Drupal\facets\Plugin\facets\processor\TranslateEntityProcessor->build() (line 111 of /var/www/build/html/modules/contrib/facets/src/Plugin/facets/processor/TranslateEntityProcessor.php) #0 /var/www/build/html/modules/contrib/facets/src/FacetManager/DefaultFacetManager.php(297): Drupal\facets\Plugin\facets\processor\TranslateEntityProcessor->build(Object(Drupal\facets\Entity\Facet), Array) #1 /var/www/build/html/modules/contrib/facets/src/Plugin/Block/FacetBlock.php(82): Drupal\facets\FacetManager\DefaultFacetManager->build(Object(Drupal\facets\Entity\Facet)) #2 /var/www/build/html/core/modules/block/src/BlockViewBuilder.php(203): Drupal\facets\Plugin\Block\FacetBlock->build() #3 [internal function]: Drupal\block\BlockViewBuilder::preRender(Array) #4 /var/www/build/html/core/lib/Drupal/Core/Render/Renderer.php(376): call_user_func('Drupal\\block\\Bl...', Array) #5 /var/www/build/html/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, true) #6 /var/www/build/html/core/lib/Drupal/Core/Render/Renderer.php(151): Drupal\Core\Render\Renderer->render(Array, true) #7 /var/www/build/html/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() #8 /var/www/build/html/core/lib/Drupal/Core/Render/Renderer.php(152): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #9 /var/www/build/html/core/lib/Drupal/Core/Render/Renderer.php(166): Drupal\Core\Render\Renderer->renderPlain(Array) #10 /var/www/build/html/core/modules/big_pipe/src/Render/BigPipe.php(527): Drupal\Core\Render\Renderer->renderPlaceholder('callback=Drupal...', Array) #11 /var/www/build/html/core/modules/big_pipe/src/Render/BigPipe.php(395): Drupal\big_pipe\Render\BigPipe->renderPlaceholder('callback=Drupal...', Array) #12 /var/www/build/html/core/modules/big_pipe/src/Render/BigPipe.php(137): Drupal\big_pipe\Render\BigPipe->sendPlaceholders(Array, Array, Object(Drupal\Core\Asset\AttachedAssets)) #13 /var/www/build/html/core/modules/big_pipe/src/Render/BigPipeResponse.php(41): Drupal\big_pipe\Render\BigPipe->sendContent('...', Array) #14 /var/www/vendor/symfony/http-foundation/Response.php(374): Drupal\big_pipe\Render\BigPipeResponse->sendContent() #15 /var/www/build/html/index.php(20): Symfony\Component\HttpFoundation\Response->send() #16 {main}.


It looks like everything should be working correctly based on the SC provided above but I am cannot see if I have a mis-configuration or if their is an issue with the processor and Solr as the backend.

Search-API -> Beta3
Search-API-Solr -> Beta1
Core -> 8.2.1
Facets -> 3d18651 (dev-master -1 at time of writing). I will debug some more but outside of this, which might be un-related, I am excited to see this finally make it in.

So the entity translation processor issue looks like known issue: https://www.drupal.org/node/2777217.

I found one issue and I am not sure what the solution might be or if its a facets issue or not but it looks like the field stored for hierarchical fields are coming back a node entities and not taxonomy entity types. which is causing a few issues displaying the label for the taxonomy ID.

I found one issue and I am not sure what the solution might be or if its a facets issue or not but it looks like the field stored for hierarchical fields are coming back a node entities and not taxonomy entity types. which is causing a few issues displaying the label for the taxonomy ID.

That's a good question, I don't think we've tested those together already but will defer to @StryKaizer, he's been more involved in this work.

I get correct labels too.

@StryKaizer and @borrisson_ I indexed the top level taxonomy term, which happens to be the tid which works with the current implementation of the entity processor. What I did find was that if you drill down in the taxonomy term and index the actual term ID field_name:entity:tid the processor will through the error identified in #49. I believe what I was originally seeing was a caching issue with the processor not working with Hierarchical facets but I do think there is still an issue with the null call on getSettings() in the Entity processor. I added a patch in the other case worked for my particular case.

I can confirm #39 patch works for my case. The hierarchy can be retrieved perfectly.

The translate entity label issue is kind of not related with hierarchy issue. So it would be great #39 patch can be committed.

I been testing the patch out and I am seeing the same error as described in #42 but I do not have the patch for #2735891 applied. Oddly enough, everything seems to function without issue, the facets is applied to the URL, if the children aren't expanded they expand correctly. Clicking on the top most parent is the only way to cause the issue; if you select a child even is that child has children of its own no error. I am going to see if I can make sense of where its happening.

stack trace:

Notice: Undefined offset: 0 in Drupal\facets\Plugin\facets\url_processor\QueryString->buildUrls() (line 99 of /var/www/community/build/html/modules/contrib/facets/src/Plugin/facets/url_processor/QueryString.php) #0 /var/www/community/build/html/core/includes/bootstrap.inc(548): _drupal_error_handler_real(8, 'Undefined offse...', '/var/www/commun...', 99, Array) #1 /var/www/community/build/html/modules/contrib/facets/src/Plugin/facets/url_processor/QueryString.php(99): _drupal_error_handler(8, 'Undefined offse...', '/var/www/commun...', 99, Array) #2 /var/www/community/build/html/modules/contrib/facets/src/Plugin/facets/processor/UrlProcessorHandler.php(65): Drupal\facets\Plugin\facets\url_processor\QueryString->buildUrls(Object(Drupal\facets\Entity\Facet), Array) #3 /var/www/community/build/html/modules/contrib/facets/src/FacetManager/DefaultFacetManager.php(297): Drupal\facets\Plugin\facets\processor\UrlProcessorHandler->build(Object(Drupal\facets\Entity\Facet), Array) #4 /var/www/community/build/html/modules/contrib/facets/src/Plugin/Block/FacetBlock.php(82): Drupal\facets\FacetManager\DefaultFacetManager->build(Object(Drupal\facets\Entity\Facet)) #5 /var/www/community/build/html/core/modules/block/src/BlockViewBuilder.php(203): Drupal\facets\Plugin\Block\FacetBlock->build() #6 [internal function]: Drupal\block\BlockViewBuilder::preRender(Array) #7 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(376): call_user_func('Drupal\\block\\Bl...', Array) #8 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, true) #9 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(151): Drupal\Core\Render\Renderer->render(Array, true) #10 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() #11 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(152): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #12 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(166): Drupal\Core\Render\Renderer->renderPlain(Array) #13 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(659): Drupal\Core\Render\Renderer->renderPlaceholder('<drupal-render-...', Array) #14 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(544): Drupal\Core\Render\Renderer->replacePlaceholders(Array) #15 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, true) #16 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(139): Drupal\Core\Render\Renderer->render(Array, true) #17 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() #18 /var/www/community/build/html/core/lib/Drupal/Core/Render/Renderer.php(140): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #19 /var/www/community/build/html/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(258): Drupal\Core\Render\Renderer->renderRoot(Array) #20 /var/www/community/build/html/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(131): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->renderPlaceholders(Object(Drupal\Core\Render\HtmlResponse)) #21 /var/www/community/build/html/core/lib/Drupal/Core/EventSubscriber/HtmlResponseSubscriber.php(45): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object(Drupal\Core\Render\HtmlResponse)) #22 /var/www/community/build/html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #23 /var/www/community/vendor/symfony/http-kernel/HttpKernel.php(184): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent)) #24 /var/www/community/vendor/symfony/http-kernel/HttpKernel.php(166): Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object(Drupal\Core\Render\HtmlResponse), Object(Symfony\Component\HttpFoundation\Request), 1) #25 /var/www/community/vendor/symfony/http-kernel/HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #26 /var/www/community/build/html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #27 /var/www/community/build/html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #28 /var/www/community/build/html/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #29 /var/www/community/build/html/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #30 /var/www/community/build/html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #31 /var/www/community/build/html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #32 /var/www/community/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #33 /var/www/community/build/html/core/lib/Drupal/Core/DrupalKernel.php(652): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #34 /var/www/community/build/html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #35 {main}.

So I have been working through a bit of this here tonight and I think I found one issue that was causing a potential configuration issue

$form['facet_settings']['expand_hierarchy'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Always expand hierarchy'),
      '#description' => $this->t('Render entire tree, regardless of whether the parents are active or not.'),
      '#default_value' => $facet->getExpandHierarchy(),
      '#states' => array(
        'visible' => array(
          ':input[name="facet_settings[use_hierarchy]"]' => array('checked' => TRUE),
        ),
      ),
    ];

I think the '#default_value' => function call is incorrect. I think instead of getExpandHierarchy() it should be getEnableParentWhenChildGetsDisabled

I am also seeing that the processor essentially not working. The parents are still being selected even with the above code change.

I have been testing Hierarchical Facets. I understand that when we deselect a child the parent is automatically selected. I am seeing a weird behavior if a parent has two children. I selected the both the children I see some search results narrowing it down according to my selection but when I uncheck the one of the children the parent gets selected and this is actually showing wrong search result. As a front-end tester this travelling back up the tree is very confusing for a user. It would be nice if we unselect the children the parent gets unselected as well

Please look at the screen shots uploaded in the file sections

I was able to solve the disabling parent term functionality that isn't working with patch #39. The url was not being set correctly and was using the URL from the parent even with the the Enable parent when child gets disabled disabled. The interdiff is against #39 and includes the fix described in #58

@stryKaizer what I was seeing was when the $url was being set outside of the $results loop there was a remnant of the previous terms query param being added to the checked facet here:

$url = clone $url;
      if ($result_get_params->all() !== [$this->filterKey => []]) {
        $url->setOption('query', $result_get_params->all());
      }

      $result->setUrl($url);

The if statement in the above will evaluate to false for the checked facet but the $result->setUrl($url), since the $url was just set by the last loop, will set the selected facet's data-facetredir to have a redirect to that term in the last loop.

Resetting the $url for each $result makes sure that the $url isn't being reused.

I think we could also just move the $result->setUrl($url) inside the if.

#56 is right the notice occurs without the current search patch.

          if (isset($parent_ids[0]) && $parent_ids[0]) {
            $filter_params[] = $this->urlAlias . self::SEPARATOR . $parent_ids[0];
          }

I applied the patch to drupal 8.2.3 and found that some of the new plugins were placed in the wrong directories. I fixed it and created a new patch from those changes.

One of the issues I saw was that in my drupal root directory a src folder was created with the Hierarchy folder containing the HierarchyInterface, HierarchyPluginBase, HierarchyPluginmanager files.

@jbertoen The patch is to be applied from the facets directory (cd modules/contrib/facets; curl https://www.drupal.org/files/issues/implement_hierarchical-2807333-65.patch | git apply - not the core root folder.

Facet sorting still seems to go wrong when you enable "Sort by active state" (Sorts the widget results by active state).

I will try to write some tests for it.

Here are my tests for this issue. It took me a while to generate all the structures but i think i got it working. Lets see what the testbot says. If there are any cases missing, let me know. During my tests i ran into a configuration schema exceptions, due to a missing schema for the translate_entity option. Thats why i also edited facets.facet.schema.yml although this is obviously not in scope of this issue. Maybe there are more schema entries missing?

In my tests i do the following stuff:

setup:

1. Create a new vocabulary
2. Create a term structure with hierarchy
3. Entities "item" and "article" and add a term reference to the new vocabulary
4. Generate some content
5. Add the newly created term reference to the search index
6. Index all items
7. Create a facet for the new field in index

tests:

1. tests for the use hierarchy option
2. tests for the always expand hierarchy option
3. tests for the Enable parent when child gets disabled option

I just did a review and I have no remarks. It looks great. I'll have another look tomorrow but that's absolutely great work @dermario!

Certainly good enough for now.
I'm using this in production for a while now, so I would love to get this in.

Looks like a couple of things slipped in with @dermario's patch that shouldn't have. Applied #65 + interdiff from #71 locally. Result is attached. If testbot's green I'll commit this right away.

Awesome, thanks so much everyone. Please open followups if the behavior isn't as expected yet.

Sweet. One step closer to a beta!

I'm using search api(backend = database) - and I see the hierarchy checkbox. I have a commerce product with term references - and I see the facets - but the hierarchy is flat. I dont know exactly what is meant by "Requires the hierarchy processor configured in search api for this field" - I havnt be able to find how to disable/enable this. I guess thats where my problem is.

Can someone point me in the right direction?

I'm sorry if this is not the right place?

Tks

@peterStub You need to enable the search API processor the Hierarchy, which is located here /admin/config/search/search-api/index/<index_name>/processors

Looks something like the attached SC.

Tks @ndrake86...I did visit that page once - but could see it - but its there now...GREAT - tks alot...

And I confirm it all works...

#2833681: Improve hierarchy description opened.