FacetWP Hierarchy Select - WordPress Plugin

FacetWP Hierarchy Select Guide: Cascading Filters for Sections, Categories, and Nested Taxonomies

FacetWP Hierarchy Select is not meant for a standard single dropdown. It is built for cases where users need to narrow their choice step by step through a term tree: first country, then region, then city; first catalog section, then subcategory, then product type; first broad topic, then a more specific subject. This guide focuses on practical implementation rather than marketing copy: what to prepare in WordPress, how to create the facet, how to choose the data source, how to configure levels, when to enable ghost options, how to verify indexing, and what to do if child dropdowns do not appear.

This article is intended for site administrators and developers working on sites where FacetWP is already used to filter posts, WooCommerce products, recipes, real estate listings, learning materials, documentation, or another type of catalog. If FacetWP is not set up yet, start with the basics: a list of posts, a FacetWP-enabled listing template, at least one facet, and a working index. Hierarchy Select adds a convenient cascading interface for a nested taxonomy on top of that foundation.

The core idea is simple: visitors do not have to scan through one long flat list of terms. They choose the first level, then gain access to the next dropdown, then the next one after that. But for this interface to behave predictably, the details matter: the taxonomy must actually be hierarchical, the levels must be named in the facet settings, the FacetWP index must account for parent relationships, and the page must contain a valid listing template. These are exactly the details that usually separate a working setup from an "empty list" or a filter that resets results in a way users do not expect.

This guide includes dedicated sections on preparation, setup, a real-world example, result validation, safe visual enhancements, troubleshooting, related solutions, and FAQ. Where the official documentation confirms a specific hook or CSS class, you will see small reversible code snippets. Where behavior depends on the theme, page builder, or site structure, the wording stays intentionally cautious and assumes you will test it in your own installation.

What Problem Cascading Hierarchical Selection Solves

A standard category filter works well when there are only a few values. If a catalog has ten sections, checkboxes or a single dropdown are still easy to read. The problem starts when the structure gets deeper: parent categories, multiple levels of subcategories, branches with different numbers of child terms, hundreds of cities inside countries, or dozens of product types inside larger sections. At that point, users see too many choices at once, and administrators end up fighting with sort order, counters, empty values, and performance.

FacetWP Hierarchy Select solves this by guiding users through the tree in a controlled way. Instead of one long panel, it displays a separate dropdown for each taxonomy level. The first dropdown covers the top level, the second appears or fills in after a parent is selected, and the third refines the choice even further. For users, it feels like a clear sequence: "start with the broad group - then narrow it down - then choose the exact section."

The real strength of Hierarchy Select is not the dropdown itself, but the way it preserves parent-child term logic in the filtering interface. If a post is assigned only to a child term, FacetWP can index not just that explicit value but also the implied parent levels. That means selecting a parent can still return posts assigned to child terms, even if the parent was never manually selected in the post editor. This is critical for catalogs: editors do not have to duplicate every parent selection on every item, while visitors can still start filtering from a broad top-level choice.

Typical scenarios where FacetWP Hierarchy Select is especially useful:

• A WooCommerce product catalog with nested categories, for example "Clothing" - "Women" - "Dresses".
• A real estate database: "Country" - "Region" - "City" - "District".
• A recipe or learning site: "Dish Type" - "Cuisine" - "Collection" or another editorial structure.
• Documentation or a knowledge base: "Product" - "Section" - "Topic".
• A catalog of specialists, services, or listings where users first choose a broad area and then refine into a subcategory.

The plugin may be unnecessary if your data is just a flat set of tags with no parent relationships. For tags, colors, sizes, brands, or custom metadata, a regular Dropdown, Checkboxes, Radio, fSelect, Search, or Autocomplete is often a better fit. Hierarchy Select is most effective when a term is not just a "value" but a node in a tree.

Quick check before choosing the interface: if you can draw your data structure as a tree with parents and children, Hierarchy Select is worth considering. If all values are peers with no nesting, a different facet type is usually the better choice.

What FacetWP Hierarchy Select Depends On

To configure FacetWP Hierarchy Select correctly, it helps to think of the system as four layers: the WordPress taxonomy, the FacetWP facet, the listing template, and the index. A problem in any of these layers looks the same to visitors - the filter is empty, does not update results, or shows the wrong values. But the fixes will be different.

Layer 1: The Hierarchical WordPress Taxonomy

The data source for Hierarchy Select is a taxonomy. In WordPress, taxonomies can be flat or hierarchical. The built-in category taxonomy and WooCommerce product categories product_cat are straightforward examples of a hierarchical structure. In this kind of taxonomy, terms have parents and children. When you register a custom taxonomy, that behavior is controlled by the hierarchical argument, which must be enabled.

If you use an ACF field, a custom field, or a flat tag set instead of a taxonomy, the cascading logic breaks down. FacetWP documentation specifically notes that if you want to work with term order through term_order, the data source must be the taxonomy itself, not an ACF field that merely stores a selected term. That is an important real-world boundary: in the editor, a user may see something that looks like a "category" field in ACF, but for FacetWP it is still a different type of data.

Layer 2: A Facet with the Hierarchy select Type

In the FacetWP settings, you need to create a new facet and choose the Hierarchy select type. After that, you set the data source and display options. The most distinctive setting is Show depth levels. It determines which levels will be shown and what labels the dropdowns will use. If your taxonomy has three levels but you add only one depth label in the facet, users will see only the first dropdown. To display all three levels, you need three labels.

This setting is often treated as cosmetic, but it actually controls whether levels appear at all. So when you first configure the facet, do not stop at something generic like "Category." Think in terms of how visitors understand the structure: "Section," "Subsection," "Topic"; "Country," "Region," "City"; "Category," "Subcategory," "Type." Good labels reduce wrong selections.

Layer 3: A Page with a FacetWP-Enabled Listing

The facet does not filter "everything on the site." It filters a specific listing template that FacetWP can recognize: an archive, a custom WP_Query, Listing Builder, blocks, a supported page builder, or another valid output method. The page needs not only the filter UI but also the list of posts it is connected to. If that listing template does not exist, FacetWP has no way to know which posts it should narrow, and the facet behavior becomes unpredictable.

On larger projects, a good rule is to keep one main FacetWP-enabled listing on the page. When the theme, blocks, or builder generate multiple hidden queries, FacetWP may lock onto the wrong one. In those cases, Debug Mode helps you see which query arguments and which template are actually being used.

Layer 4: The FacetWP Index

FacetWP does not recalculate all values on the fly for every request. It scans the site and stores facet data in its own index table for fast lookup queries. After creating or changing a facet, you need to save the settings and click Re-index. Re-indexing is also required after changing the term hierarchy, for example if a term was moved under a different parent.

Re-indexing matters even more for Hierarchy Select: the index is what stores the relationship between a post, a child term, and the implied parent levels. If you change the category tree but do not rebuild the index, the public site may still reflect the old structure.

Who This Add-On Is For, and When It Makes the Interface Worse

FacetWP Hierarchy Select is a good fit for sites where users usually know at least the top level of the choice they want to make. For example, on a real estate catalog, visitors may start with a country or region, then choose a city. In an online store, buyers may start with a broad category and then narrow down to a product type. In a knowledge base, readers may choose a product first and then a documentation section. In these cases, cascading dropdowns keep you from showing the entire tree at once.

The add-on is also helpful for editorial teams. If editors assign the most specific child term to a piece of content, FacetWP can still account for the full parent chain in the index. That reduces manual discipline: no one has to remember that an entry tagged "Paris" should also be assigned "France" and "Europe." But that does not eliminate the need for a clean term structure. If the tree is chaotic, Hierarchy Select will simply make that chaos visible on the front end.

When It Is a Good Choice

• The taxonomy has clear levels, and each level has independent meaning for the user.
• The catalog is large enough that a single flat list becomes inconvenient.
• You need to guide visitors through steps instead of showing dozens of equally weighted options at once.
• The project already uses FacetWP, or you are prepared to build the listing around its logic.
• The team is ready to re-index data after changing the term structure.

When Another Facet Type Is Better

Do not use Hierarchy Select just because "dropdowns look compact." For flat attributes, it only adds an unnecessary step. It is also the wrong tool for price, rating, date, or keyword filtering. For multiselect within a single level, Checkboxes or fSelect are often more useful. FacetWP documentation explicitly notes that fSelect inside Hierarchy Select works in single-select mode because the cascading flow is built around moving through a parent-child chain, not selecting multiple independent values.

Be careful with very deep trees. Four or five levels may make sense in a database, but on the page they can turn into a tiring path. If users usually choose only a top level and a middle level, do not expose every depth automatically. Check analytics, user behavior, and real search tasks first.

Practical rule: show only as many levels as genuinely help narrow the listing. You can keep deeper levels in the taxonomy structure without necessarily exposing them in the interface.

What to Check Before Installation and First Use

Preparation saves more time than troubleshooting later. FacetWP Hierarchy Select depends on the core FacetWP plugin, the taxonomy structure, a valid listing, and the index. Before adding the add-on, it is worth running through a short checklist.

Check the Core FacetWP Plugin and Add-On Access

Hierarchy Select is an add-on facet type, which means it is a separate add-on for FacetWP. The FacetWP add-ons page explains that these extensions are downloaded from your account when you have an active license. This setup guide does not need to get into purchasing or license activation, but in a real project you do need to understand one thing: if the core FacetWP plugin is not installed, or the add-on is not available in the account, the Hierarchy select facet type will not appear in the settings.

After installation, check the WordPress plugin list: the core FacetWP plugin is active, Hierarchy Select is active, and the facet interface opens on the Settings > FacetWP page. If the add-on is activated but the facet type is still missing, refresh the admin page first and check for PHP errors or an admin-side caching conflict.

Check the Taxonomy and Tree Depth

Open the admin section where the relevant terms are managed. For regular posts, that may be Posts > Categories; for WooCommerce products, it will be the product categories screen. For a custom taxonomy, the path depends on which post type it is attached to. Make sure the terms are truly nested: child terms should have an assigned parent, not just a similar name.

It helps to write out a few real chains. For example: "Europe > France > Paris," "Clothing > Women > Dresses," or "Documentation > Facets > Hierarchy Select." If there are no real chains, it is too early to configure a cascading filter. Clean up the structure first.

Check the Posts and Their Assigned Terms

Open a few posts or products that should appear in the listing. Make sure they are assigned to the appropriate child terms. You do not have to assign every parent manually if FacetWP is indexing the hierarchy correctly, but at least one precise term must be selected. If a post has no term at all from the selected taxonomy, it will not contribute values to the cascading facet.

Check the Listing Template

The page where you plan to place the filter should already have a list of posts. That could be an archive, a block, a page builder template, Listing Builder, or a custom query. If you are using a custom WP_Query, make sure it is set up as FacetWP-enabled. If you are using a page builder, check the official integration page for that builder. For Elementor and Beaver Builder, FacetWP provides separate integration add-ons and rules for selecting the correct module on archive pages.

Do not start with five facets at once. First make sure the basic post listing is rendering consistently. Then add one simple facet and re-index. Only after that should you introduce Hierarchy Select. That way, if something breaks, you will find the source of the problem much faster.

Installation and the First Admin-Side Check

The installation process mostly follows the standard WordPress plugin workflow: upload the add-on ZIP file, activate it, open the FacetWP settings, and create a new facet. The important thing is not to mix this up with license or purchase setup. This guide assumes you already have access to the add-on file and the core FacetWP plugin.

Create the Facet and Choose the Type

1. Open Settings > FacetWP.
2. In the facets section, click Add New.
3. Enter a clear label, such as "Categories," "Location," or "Documentation Section."
4. Check the technical facet name. It should be short, use Latin characters, and avoid special symbols.
5. In the Facet type field, choose Hierarchy select.
6. In Data source, select the correct hierarchical taxonomy.

The technical name matters just as much as the label. FacetWP uses the facet name in shortcodes, URL variables, and internal JavaScript. The documentation warns against problematic or reserved names. So do not name the facet name, method, length, or other generic words that may conflict with WordPress or scripts. Use something more descriptive instead, such as catalog_location, product_category_path, or docs_section.

Add Labels for Each Level

Find the Show depth levels setting. By default, Hierarchy Select shows one level. If you need two dropdowns, click Add Label once for the second level. If you need three levels, add three labels. Each label should match the meaning of that level.

Do not use labels like "Level 1" or "Select." Users do not need to understand the internal facet structure. They need a clear hint about what they are choosing at that step. If the site is in Russian, those labels should normally be in Russian in the interface, unless you are intentionally leaving the original English strings for multilingual logic.

Save the Settings and Run the Index

After saving the facet, click Re-index. If you have a large amount of data, wait for the process to complete. FacetWP documentation explains that the indexer rebuilds the facet data table, and interrupting the process before it finishes will leave the index incomplete until the next re-index. For the initial check, it is best to keep the settings screen open so you can watch progress.

After indexing, place the facet on the page. The simplest option is a shortcode like [facetwp facet="the_facet_name"], where the_facet_name is replaced with your facet's technical name. The shortcode can go into a Shortcode block, widget, builder module, or template. For PHP templates, you can use facetwp_display( 'facet', 'the_facet_name' ).

Quick summary of the initial setup: the facet has been created, the data source is a hierarchical taxonomy, the levels are named, the index has been rebuilt, and the shortcode or facet block is placed next to the listing. If any of those pieces are missing, do not move on to visual polish yet.

Key Settings Map: Data Source, Ordering, Levels, and Ghost Options

After the first launch, it is worth reviewing the settings based on how you want the result to behave, not just filling them out mechanically. Hierarchy Select does not have many options, but each one affects what visitors see and how the cascade behaves.

Data source: Choose a Real Taxonomy

For Hierarchy Select, the data source must be a taxonomy with a parent-child structure. In WooCommerce, this is most often Product categories. If the project uses a custom post type, choose the hierarchical taxonomy attached to that post type. With ACF, Meta Box, or Pods, it is important to distinguish between two scenarios: these tools may help you create a taxonomy or a field, but if you need full hierarchical logic, Hierarchy Select should still use the taxonomy itself.

If you do not see the source you need, check whether the taxonomy is publicly registered, attached to the correct post type, and visible in the interface. If the selected post type is not indexed by FacetWP, its values may also fail to appear.

Sort by: "Most Frequent" Is Not Always Best

FacetWP supports several ways to sort values: by highest result count, by display value, by raw value, and by term order. Sorting is especially noticeable in hierarchical filters. If you choose "Highest count," popular branches may rise to the top, but the catalog structure may feel less intuitive. If you choose "Display value," users get alphabetical order. If you choose "Term order," the order depends on the explicit term order, such as WooCommerce drag-and-drop category sorting or a supported term-ordering plugin.

For navigation-heavy catalogs, preserving an editorial term order is often the better choice. For example, in a store you may want to arrange categories manually from broad to specific or from core product lines to secondary ones. But that works only if the data source is a real taxonomy and the chosen tool actually writes the order into a field FacetWP can read.

Show depth levels: The Setting That Controls Level Visibility

This setting does more than define labels. It controls how many dropdowns are displayed. If the taxonomy has three levels but the facet includes only one label, the public interface will not show the full depth. So after creating the facet, compare the settings to the actual term tree. If some catalog branches are deeper than others, think about whether users really need the deepest level every time.

Different branches may have different lengths. For example, the "Clothing" category may have three levels, while "Gift Cards" may have only one. In that case, an empty child dropdown can look awkward. Hierarchy Select documentation describes the is-empty CSS class, which is added to a child dropdown when the selected parent has no options at the next level. You can use that class to hide empty elements cleanly.

Show ghosts and Preserve ghost order: When to Display Unavailable Options

Ghost options are facet values that were available in the original listing but no longer produce results after the current filters are applied. When Show ghosts is enabled, they remain visible but appear dimmed and inactive. This can be useful when you want users to understand the full map of available paths, even if some branches are temporarily unavailable because of the current filter combination.

For Hierarchy Select, this mode can be helpful in educational catalogs and complex stores: users can see that a subcategory exists even though the current filter combination does not contain matching posts. But in compact interfaces, ghost options may add unnecessary clutter. If visitors should only choose from currently available options, turn Show ghosts off.

Preserve ghost order keeps ghost values in their normal order instead of pushing them to the bottom. But the documentation notes one important limitation: when sorting by Highest count, ghost ordering is not preserved. So do not expect dynamic count-based sorting and strict manual ghost ordering to work together.

When to Change Sorting with a Hook

The official FacetWP documentation points to facetwp_facet_orderby as a way to fine-tune sorting. But that is already developer-level customization. Do not reach for a hook if Sort by or the admin-side term order already solves the problem. A hook makes sense when you need custom behavior, such as numeric sorting, reverse order, or a special sequence that cannot be expressed through term order.

After any change that affects indexed data or the term structure, rebuild the index. If you only changed CSS, you can usually test the visual result without a full re-index.

Term Hierarchy: How Data Becomes Cascading Dropdowns

The most common mistake with Hierarchy Select is treating it like a visual widget that will somehow "figure out" the tree on its own. In practice, everything starts with the data. If terms are not nested, if posts are tagged inconsistently, or if some branches are much deeper than others while others stay flat, the public-facing facet will reflect that inconsistency.

Explicit and Implicit Parent Levels

The official documentation describes an important mechanism: FacetWP indexes both explicit and implicit term hierarchies. If your taxonomy contains a chain like Europe > France > Paris and a post is assigned only the Paris term, filtering by Europe or France can still return that post. This makes Hierarchy Select convenient for editors: they can assign the most precise term, and parent-level filtering will still work.

But this mechanism depends on the tree being correct at the time of indexing. If you move Paris under a different parent, the index must be rebuilt. Otherwise, FacetWP will keep using the old structure. So changing a term's parent is not just an editorial cleanup. It is an event that should be followed by re-indexing.

Why You Should Not Mix Different Meaning Axes in One Taxonomy

Hierarchy Select works best when each level answers one kind of question. For example: "Where?" - country, region, city. Or "What?" - category, subcategory, product type. Problems begin when one taxonomy tries to hold geography, brand, season, and product type all at once. Formally, it is still a tree, but users no longer understand why choosing "Italy" leads to options like "Premium" or "Sale."

If you have multiple independent filtering dimensions, it is better to create multiple facets: Hierarchy Select for the nested category, Dropdown or Checkboxes for brand, Slider for price, Search for keywords. FacetWP can make facets "aware of each other," meaning they show relevant values based on the current listing. You do not need to force one cascading facet to do the job of the entire filter panel.

How to Handle Branches with Different Depths

In real catalogs, not every branch is the same. One category may have three levels, another only one. By default, Hierarchy Select can display all configured levels even when the next dropdown has no values after a parent is chosen. The documentation describes the is-empty class for those empty child dropdowns and the is-disabled class for levels that are still waiting for a parent selection.

Do not hide everything immediately on day one. First watch how real users move through the chain. Sometimes a disabled dropdown is helpful because it shows that another step will appear after the parent is chosen. Sometimes an empty dropdown really is confusing. In that case, hiding empty or disabled levels with CSS can make the interface cleaner.

Practical Example: Filtering a Catalog by Section, Subcategory, and Type

Let us walk through a concrete scenario. Suppose the site has a catalog of learning materials. The materials are stored in a custom post type called resource. A hierarchical taxonomy named resource_topic has been created for them, with the levels "Area," "Section," and "Topic." The goal is for visitors to choose an area first, then a section, then a specific topic, while the materials list updates through FacetWP.

Goal

Create three sequential dropdowns on the catalog page: "Area," "Section," and "Topic." After selecting the first level, the second dropdown should populate with child terms. After selecting the second, the third should populate as well. The listing results should narrow so that selecting a parent still shows materials assigned to child topics.

Preparation

• The core FacetWP plugin is installed and active.
• FacetWP Hierarchy Select is installed and active as an add-on.
• The resource_topic taxonomy is registered as hierarchical.
• The materials have assigned terms from that taxonomy.
• The catalog page contains a FacetWP-enabled materials listing.

Setup Steps

1. Open Settings > FacetWP and create a new facet.
2. Set the label to something like "Material Topics."
3. Use resource_topic_path as the technical name.
4. Select Facet type - Hierarchy select.
5. In Data source, choose the resource_topic taxonomy.
6. In Show depth levels, add three labels: "Area," "Section," and "Topic."
7. In Sort by, choose the order that fits the catalog. For an editorial tree, start with Term order if term ordering is actually configured, or with Display value if you want alphabetical order.
8. Save the facet and run Re-index.
9. Place the facet shortcode next to the listing: [facetwp facet="resource_topic_path"].
10. Open the catalog page in a private browser window and test the selection flow at each depth.

Validating the Result

Select a top-level term. The second dropdown should become active and display child sections. Select a section. The third dropdown should display topics. After each selection, confirm that the materials list actually narrows. Then choose a parent-level term and make sure the listing includes materials assigned only to child terms. That confirms that implicit parent indexing is working.

Look at the URL after making a selection. FacetWP uses the facet name as part of the variable, so the technical name should be clear and safe. If the URL contains strange or excessively long variables, go back to the facet settings and shorten the name.

Details Worth Checking Right Away

If the second or third dropdown does not appear, check Show depth levels first. You may have added only one label. If the dropdown appears but is empty, check the term tree and re-indexing. If the filter returns the wrong posts after selection, enable Debug Mode and check which query FacetWP is using on the page. If the listing markup breaks after the Ajax refresh, the issue may not be Hierarchy Select at all. It could be theme scripts, lazy loading, Masonry, Isotope, or another JavaScript layer that needs to be re-run after the facetwp-loaded event.

Working definition of "ready": users can move through the chain from top to bottom, the listing updates after each selection, child posts are found through the parent, and resetting the filter returns all levels to a clear default state.

Visual Improvements Without Editing Plugin Core

Once the logic works, you can improve the interface carefully. The key rule here is not to edit the FacetWP core, the main plugin, the add-on, or the theme directly. Use a child theme, a snippets plugin, or the official Custom Hooks add-on. All snippets below are based on publicly documented FacetWP CSS classes and hooks, but you should still test them on a staging copy first.

Hide Disabled or Empty Child Dropdowns

Hierarchy Select adds the is-disabled class to child dropdowns while a parent has not yet been selected, and the is-empty class when the selected parent produces no options at the next level. If your interface is clearer without those dropdowns, you can hide them with CSS. Add the code through a child theme or a safe snippet manager.

add_action( 'wp_head', function() {
  ?>
  <style>
    .facetwp-hierarchy_select.is-disabled,
    .facetwp-hierarchy_select.is-empty {
      display: none;
    }
  </style>
  <?php
}, 100 );

The check is simple: open the page, choose a top-level value with a short branch, and confirm that the unnecessary empty dropdown disappears. Then choose a branch with full depth and confirm that the required child dropdowns still appear. To roll back the change, disable the snippet or remove the CSS block.

Hide Counters Only for Hierarchy Select

Counters are useful when users are comparing available options. But in a cascading interface, they sometimes add visual noise, especially if other facets are nearby. FacetWP documentation describes the facetwp_facet_dropdown_show_counts filter, which you can apply based on the facet type.

add_filter( 'facetwp_facet_dropdown_show_counts', function( $return, $params ) {
  if ( 'hierarchy_select' === $params['facet']['type'] ) {
    return false;
  }

  return $return;
}, 10, 2 );

After enabling this, test Hierarchy Select specifically, along with any regular Dropdown or fSelect facets on the same page. If you need counters in one cascading facet but not another, check by facet name instead of facet type. Do not remove counters just for the sake of a "cleaner" look. In some catalogs, result counts genuinely help users decide.

When to Consider the fSelect Display

The official documentation shows that Hierarchy Select can be rendered using the fSelect dropdown style. That can be useful if you want more consistent behavior across browsers or search inside the dropdown. But there are tradeoffs: within Hierarchy Select, fSelect still works in single-select mode, and if the page already contains a real fSelect facet, you should not load the same CSS and JavaScript files twice.

Do not start here. First make the standard <select> interface work reliably. Then decide whether you actually need an alternate UI. If the cascade is short and the values are clear, the default display is often faster, lighter, and easier to understand.

Placing the Facet on the Page and Working with the URL

After it is configured in the admin panel, the facet still has to be placed in the right spot on the page. That sounds simple, but this is where many errors appear: the filter is inserted into one template while the listing belongs to another query; the shortcode is inside a hidden builder tab; a Reset facet clears other filters but the cascading dropdown does not visually return to the expected state; or the URL becomes confusing because the facet name was poorly chosen.

Where to Place Hierarchy Select

Place the cascading facet next to the listing it is meant to filter. On a normal page, that may be the area above a card grid or the left-side filter column. In WooCommerce, it may be the filter panel before the products or the archive sidebar. In a knowledge base, it may be a compact block above the list of articles. Do not put Hierarchy Select in the global header if it is only supposed to work on one catalog page. That only complicates the context and creates extra checks on pages that do not even contain a FacetWP-enabled listing.

If you are using a shortcode, begin with just one facet and one post listing. For example, use [facetwp facet="resource_topic_path"] for the filter and a separate listing block that FacetWP can update. Once that pairing works, you can add Reset, Sort, Search, or other facets. This order is much more practical than building a five-part filter panel immediately and then guessing which part is breaking the Ajax refresh.

Why the Facet Name Affects Supportability

FacetWP uses the technical facet name in the URL and its JavaScript state. If the name is too generic or uses cryptic abbreviations, troubleshooting gets harder. A good name explains the purpose: resource_topic_path, product_cat_path, location_path. A weak name like filter1 or cat quickly becomes meaningless, especially once several facets appear on the same page.

After the first selection, look at the browser address bar. The URL should help you understand which facet is selected. That does not mean the URL has to be as polished as a static SEO landing page, but it should be predictable for support work. If a user sends a problem link, the administrator should be able to see immediately that the selected value belongs to the cascading facet, not some random theme parameter.

Reset and User Selections

A full filter panel usually needs a Reset facet. It lets users return the page to its original listing without manually removing parameters from the URL. If the page contains multiple facets, Reset also helps you check whether state is lingering in one facet after another is cleared. This is especially noticeable with Hierarchy Select: after a reset, child dropdowns should return to their pre-selection state or disappear if you applied CSS to is-disabled.

User Selections is useful when the page contains many filters and users need to see what is currently active. For a cascading facet, that makes it easier to understand which branch of the tree is selected. But if the panel is short and the choice is obvious, do not add another block just for completeness. Check whether it adds real value: active selections should help users clear filters faster, not simply repeat the labels next to the dropdown.

Testing After Adding Other Facets

Hierarchy Select often works alongside search, sorting, price, date, or checkbox facets. After adding each new facet, test three actions: choose a value in Hierarchy Select, choose a value in the other facet, then reset one or all filters. That shows you how FacetWP recalculates available options and whether ghost values appear.

Do not consider the setup finished until you have tested the combined scenario. A single cascade may work perfectly on its own, but once paired with price or search, some branches may become unavailable. That is normal if ghost options are enabled or if unavailable values disappear in an expected way. The real problem begins when users see an empty dropdown with no explanation or get zero results after making what seems like an obvious choice.

What Not to Do on the Page

• Do not place the same facet twice on the same page without a clear reason.
• Do not put the cascading facet inside a hidden tab that initializes only after a click until you have verified the builder's JavaScript behavior.
• Do not mix multiple unrelated trees into one Hierarchy Select if they answer different questions.
• Do not enable aggressive minification or deferred script loading before basic FacetWP verification is complete.
• Do not rename the facet's technical name on a live site without checking URLs, saved links, and your team's internal documentation.

A good page with FacetWP Hierarchy Select feels calm: users first see a clear top-level choice, then get the next step, the results update without unexpected jumps, and Reset brings the state back to the beginning. If the filter requires a separate set of instructions on the page, the taxonomy structure or the level labels probably still need work.

Compatibility with WooCommerce, Page Builders, and Caching

FacetWP Hierarchy Select rarely works in isolation. In most cases, it sits on a store page, catalog, archive, or builder-driven page. So it is useful to understand in advance which dependencies can affect the outcome.

WooCommerce: Product Categories and Term Order

For WooCommerce, the most natural use case is product categories. They are hierarchical, they support drag-and-drop ordering in the admin panel, and they work well in a cascade. If your store uses categories as a tree like "main section - subcategory - product type," Hierarchy Select can make the filter more compact than a long checkbox panel.

Do not confuse product categories with attributes. WooCommerce product attributes are also taxonomies, but they are not necessarily hierarchical by default. FacetWP taxonomy documentation shows that for some WooCommerce attributes, hierarchy can be enabled programmatically, but that is already an architectural decision. Do not change the data model for the sake of one filter until you have checked the impact on the admin UI, imports, URLs, SEO, and store integrations.

Elementor, Beaver Builder, Blocks, and Other Output Methods

If the listing is built in Elementor or Beaver Builder, follow the official FacetWP integration guidance. On archive pages in particular, it is important that the builder use the correct query. In Elementor, for example, FacetWP documentation explicitly warns about the difference between a regular posts widget and an archive widget. If the filter looks correct at first but starts returning the wrong posts after a selection, query detection is almost always the first thing to investigate.

In the block editor, you can use a shortcode block or a FacetWP block if the corresponding add-on is installed. The main point is not to place the facet separately from the FacetWP-enabled listing. The filter and the listing should live on the same page and belong to the same working context.

Caching, JavaScript Optimization, and Removing HTML Comments

Caching itself is not forbidden, but it can break filtering behavior if an optimizer defers scripts, merges JavaScript without respecting dependencies, or removes the HTML comments that FacetWP relies on to recognize the listing. The official FacetWP troubleshooting documentation mentions a case where a caching plugin removes the fwp-loop comment on archive pages, which prevents FacetWP from detecting the correct container.

If the page does not refresh the listing after a selection, values get stuck, or the browser console shows JavaScript errors, temporarily disable script optimization for the page with facets. Then re-enable the optimizations one by one. For Cloudflare and similar services, review caching rules, Ajax or REST exclusions, and minification settings.

How to Verify the Result on the Site After Setup

Verification should not stop at "the dropdown is visible." With Hierarchy Select, you need to test the sequence, the data, the URL, indexing, reset behavior, and compatibility with other facets.

Front-End Testing

1. Open the page in a private browser window to eliminate the influence of the admin bar and browser cache.
2. Check the initial state: the first dropdown is available, and child dropdowns are either disabled or hidden if you applied CSS.
3. Select a first-level term and confirm that the second dropdown receives the correct child values.
4. Select a second-level term and check the third dropdown.
5. Compare the number and composition of results with the posts you expect to see.
6. Select a parent term whose posts are assigned only to child terms, and confirm that they still appear in the listing.
7. Reset the filter through a Reset facet or by removing the URL parameter and confirm that the original listing is restored.

Checking in the FacetWP Admin Panel

Open the FacetWP settings and check whether there is a message indicating that re-indexing is required. If you changed the facet, the taxonomy, the term structure, the post type, or code that affects the index, click Re-index. If the indexer gets stuck, do not hammer it with ten retries in a row. Wait first, then check the common indexing issues: server memory, blocked self-requests, WP-Cron, a problematic post, or bad term data.

Checking with Debug Mode

If the filtered result does not match expectations, enable Debug Mode in Settings > FacetWP > Settings. Then open the facet page, open the browser console, and inspect FWP.settings.debug, FWP.settings.debug.query_args, FWP.settings.debug.sql, FWP.settings.debug.row_counts, and FWP.template. This helps you understand which template and which query FacetWP is actually using.

Turn Debug Mode back off after troubleshooting. The documentation warns that it outputs extra data and can affect load time. It belongs in temporary diagnostics, not in ongoing use on a public site.

Common FacetWP Hierarchy Select Problems and How to Diagnose Them

Most problems with FacetWP Hierarchy Select are not caused by the dropdown itself, but by the data, the index, the listing template, or caching. Below are common symptoms and a practical order of checks.

The Facet Appears but Contains No Values

Symptom: the page shows an empty dropdown or only the initial label. Possible causes: re-indexing was never run, the wrong data source was selected, the posts do not have terms from the selected taxonomy, the post type is not indexed by FacetWP, or the page does not contain a valid listing template.

What to check: open the facet settings and confirm that Data source points to the correct taxonomy. Check several posts manually. Click Re-index. If there are still no values after that, open the "Show indexable post types" action in the index settings and verify that the required post type is included. For custom post types, check the exclude_from_search argument.

How to fix it: select the correct taxonomy, assign terms to the posts, fix the post type registration or the settings of the plugin that creates it, then rebuild the index again. If the problem is the template, first make sure the FacetWP-enabled listing itself works correctly.

Only the First Level Is Displayed

Symptom: the taxonomy has multiple levels, but the page shows only one dropdown. The first thing to check is Show depth levels. In Hierarchy Select, the number of depth labels determines how many levels will be displayed. If there is only one label, there will be only one level.

How to fix it: add labels for the required levels, save the facet, run Re-index, and test the page again. If the second level is still empty, inspect the actual term tree and make sure child terms are assigned to the posts.

The Child Dropdown Is Empty After Choosing a Parent

Symptom: the first level can be selected, but the next dropdown contains no options. Possible causes: the chosen parent has no child terms, posts are not assigned to child terms, that branch is shorter than the others, or the index was not rebuilt after a tree change.

What to check: in the WordPress admin area, open the selected term and inspect its children. Then check the posts in that branch. If the branch really is shorter, that is not an error. In that case, you may want to hide empty dropdowns using the is-empty class. If child terms do exist but the facet is still empty, rebuild the index.

The Filter Returns the Wrong Posts

Symptom: after selecting a value, the list changes but shows a different post type, the wrong number of posts, or the wrong listing entirely. A common cause is that FacetWP detected the wrong query on the page. This often happens on complex archives, builder pages, and templates that contain multiple hidden queries.

What to check: enable Debug Mode and inspect FWP.settings.debug.query_args, FWP.settings.debug.sql, and FWP.template. Compare post_type, posts_per_page, and the other arguments against what your listing is supposed to use. If FacetWP is using the wrong query, enable stricter query detection or rebuild the template according to the official documentation for your chosen output method.

The Layout Breaks After the Ajax Refresh

Symptom: the initial page looks fine, but after selecting a filter, the cards shift, images do not finish loading, or Masonry or the grid stops working. The cause is usually JavaScript from the theme or a third-party plugin that applies its enhancement only on the initial page load.

How to fix it: temporarily disable lazy loading, Masonry, Isotope, or the other script and see whether the issue disappears. If the feature is required, a developer should re-run it after the facetwp-loaded event. Do not try to fix this through Hierarchy Select settings. The facet updates the listing, but it cannot be expected to account for every decorative theme script.

The Indexer Gets Stuck or Shows an Empty Table

Symptom: Re-index never completes, stays stuck at one percentage, or you see a message saying the index table is empty. The official common indexing issues page lists several possible reasons: not enough memory, blocked self-requests, WP-Cron issues, a specific post or term with bad data, a non-indexable post type, or a missing Multilingual add-on when using WPML or Polylang.

What to check: wait a few minutes, because the indexer has built-in resume behavior. If it consistently stalls, check the server log, wp-content/debug.log, the list of indexable post types, and any recent changes to the term structure. If HTTP Basic Authentication is enabled on a staging site, indexing may fail to continue unless the server can authenticate its own requests properly.

When It Is Better to Roll Back the Change

Roll back your most recent changes if they broke the listing, removed values, or increased the number of JavaScript errors. Start with the safest layers: disable the most recent snippet, restore the default appearance, turn off script optimization, and rebuild the index. Do not delete the taxonomy or rewrite the term structure in bulk until you have a backup and understand the real source of the problem.

When FacetWP Hierarchy Select Is the Right Choice

FacetWP Hierarchy Select is worth using when the site already has, or is moving toward, a FacetWP-based architecture and the data is organized as a term tree. It is especially useful for catalogs where users think in sequential levels: section, subcategory, exact type; country, region, city; product, section, topic. In those cases, cascading selection reduces visual noise and helps visitors move through the structure without long flat lists.

Do not start with visual polish or extra snippets. First confirm four things: the taxonomy is hierarchical, the posts are assigned the right terms, the facet has the necessary depth labels, and the index has been rebuilt. Then test the listing on the public page, the URL, reset behavior, and Debug Mode when results look questionable. Only after that does it make sense to hide empty dropdowns, change counters, or consider the fSelect display.

If your task matches this use case and you are ready to test on a staging page, you can download the ZIP archive, install the add-on, and configure your first cascading facet on a small controlled dataset. That is the easiest way to see the real value of the product without letting data-structure mistakes spread across the entire catalog.

For simple flat filters, a different facet type is usually better. But for large stores and catalogs with nested sections, Hierarchy Select addresses a very specific pain point: it turns a complex term tree into a clear step-by-step path where each choice narrows the listing and leaves users with a sense of control.