>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3616544. --> Reported by: [ckng](https://www.drupal.org/user/16307) Related to !394 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The "Show only deepest item levels" processor (<code>ShowOnlyDeepestLevelItemsProcessor</code>) is supposed to hide any facet result that has children, leaving only leaf-level items visible. It is not working with facets_exposed_filters, for two independent reasons:</p> <ol> <li><strong><code>supportsFacet()</code> is gated to <code>facet_entity</code> only.</strong> The processor's <code>supportsFacet()</code> hardcodes support to <code>$facet-&gt;getFacetType() == 'facet_entity'</code>, with a <code>@todo Support "facets_exposed_filter".</code> comment acknowledging the gap. Any facet exposed as a Views filter via the Facets Exposed Filters submodule has <code>facet_type == 'facets_exposed_filter'</code> at runtime, so the processor is excluded from that facet's pipeline entirely &mdash; it never even appears as a configurable option on the Views filter's settings form.</li> <li><strong>Processor ordering.</strong> Once the type restriction above is lifted, the processor still has no effect: it declares a default <code>build</code> stage weight of <code>40</code>, while <code>HierarchyProcessor</code> &mdash; the processor that actually populates each result's children via <code>setChildren()</code> &mdash; declares a weight of <code>100</code>. Processors run in ascending weight order, so <code>ShowOnlyDeepestLevelItemsProcessor::build()</code> runs <em>before</em> the hierarchy tree is built. Its check <code>if (!empty($result-&gt;getChildren())) { unset($results[$id]); }</code> always sees an empty children array, so no result is ever excluded.</li> </ol> <p>Reweighting the processor to run after <code>HierarchyProcessor</code> is not sufficient by itself, and surfaces a third, previously-latent bug:</p> <ol start="3"> <li><strong><code>build()</code>'s removal logic discards children along with their parent.</strong> <code>HierarchyProcessor::build()</code> deliberately removes child results from the top-level results array once they are nested under their parent (its own code comment: "Remove children from primary level"). <code>ShowOnlyDeepestLevelItemsProcessor::build()</code> only ever <em>removes</em> a parent when it has children &mdash; it has no logic to promote that parent's children back into the flat results array in its place. Once the ordering bug (2) is fixed and the processor actually runs against a built hierarchy tree, it removes every parent correctly, but their children vanish along with them instead of surfacing as the intended "deepest level" items. Only fixing (1) and (2) together produces a facet that shows no results below the top level at all, worse than doing nothing.</li> </ol> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Create a hierarchical taxonomy vocabulary with at least one parent term that has children.</li> <li>Create a Search API facet on that field, with "Use hierarchy" enabled and hierarchy type "Taxonomy."</li> <li>Expose the field as a Views filter via the Facets Exposed Filters submodule (<code>facets_filter</code> plugin). Observe: the "Show only deepest item levels" processor is not offered as a selectable processor on the filter's settings form at all (bug 1).</li> <li>Patch <code>supportsFacet()</code> only and add the processor to the filter's <code>processor_configs</code> at its default weight. Observe: parent and child terms all still display (bug 2, ordering).</li> <li>Additionally reweight the processor to run after <code>hierarchy_processor</code>, without changing <code>build()</code>. Observe: both parent <em>and</em> child terms disappear &mdash; only childless top-level terms remain (bug 3, children are not promoted after their parent is removed).</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>Update <code>ShowOnlyDeepestLevelItemsProcessor::supportsFacet()</code> to also allow <code>facet_type == 'facets_exposed_filter'</code>, removing the <code>@todo</code>.</li> <li>Change the processor's declared <code>build</code> stage weight from <code>40</code> to a value greater than <code>HierarchyProcessor</code>'s <code>100</code> (e.g. <code>110</code>), so it runs after the hierarchy tree is built and <code>getChildren()</code> is populated.</li> <li>Rewrite <code>build()</code> to recursively descend into each result's children and collect only the leaves (results with no children of their own), rather than simply unsetting any result that has children. This requires no additional queries: it operates purely on the hierarchy tree <code>HierarchyProcessor</code> already built via a single batched <code>getChildIds()</code> call, which matters for taxonomies with large numbers of terms since that call is not batched into a single query internally.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Patch and manual testing against both a classic Facets block and a Facets Exposed Filters (Views) placement, across more than one level of hierarchy depth.</li> <li>Confirm no other core/contrib processor depends on <code>ShowOnlyDeepestLevelItemsProcessor</code> running at its current weight of <code>40</code> relative to processors between weight 40 and 100 (e.g. <code>CountLimitProcessor</code>, <code>ExcludeSpecifiedItemsProcessor</code>, <code>HideOnlyOneItemProcessor</code>, all at weight 50) before finalizing the new weight value.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None. The processor becomes selectable in the Views exposed-filter processor settings form for facets of type <code>facets_exposed_filter</code>, where it was previously silently omitted.</p> <h3 id="summary-api-changes">API changes</h3> <p>None. The processor's plugin ID and configuration schema are unchanged. The plugin annotation's declared default weight, the <code>supportsFacet()</code> return condition, and the internal implementation of <code>build()</code> change; a new protected helper method is added. No public method signatures change.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p>