FacetWP Conditional Logic - WordPress Plugin

A Setup Guide to FacetWP Conditional Logic for Smarter WordPress Filters

FacetWP Conditional Logic is not meant to create the filters themselves. Its job is to control how they behave: show, hide, or change the visibility of facets and related elements based on selected conditions. In this guide, we'll walk through how to use the add-on on a real WordPress page where FacetWP is already installed, a listing template is in place, and a set of facets is powering a catalog, knowledge base, real estate directory, recipe archive, job board, or product listing.

The goal of this guide is not to repeat the button-by-button documentation, but to show the real implementation logic: what to check before installation, how to build a ruleset, when to use Do the opposite, how to avoid mistakes with Page URI, why a facet's technical value matters more than its visible label, how to verify the result, and what to do if a rule behaves unexpectedly.

This guide is intended for site admins, theme developers, catalog editors, and project owners who already understand why they need FacetWP but want to make the filtering interface cleaner and more intentional. If your page shows empty filter groups, unnecessary parameters before a category is selected, extra blocks on specific pages, or different facet sets for different templates, Conditional Logic is designed to handle exactly that part of the job.

What Problem Conditional Logic Solves Alongside FacetWP

In a standard FacetWP setup, facets already understand the results and can display relevant options. But that does not always mean the full page interface is easy to use. A facet may be technically correct and still feel unnecessary in a specific scenario. For example, a "Size" filter makes sense after the user chooses the "Clothing" category, but it gets in the way on an accessories page. A "Model" filter is useful only after a brand has been selected. A helper block may be worth showing before the user makes a choice, but once filtering is active, it is usually better to hide it.

FacetWP Conditional Logic adds a rule layer on top of FacetWP: if the conditions are met, perform the actions. Conditions can refer to the state of facets, a selected value, the number of results, the current page URI, or the listing template in use. Actions can show or hide a single facet, all facets, the template from the condition, or any custom element through a selector. That is why it makes more sense to think of the add-on as a visibility manager rather than a replacement for facet settings themselves.

The biggest difference from a simple CSS tweak: a Conditional Logic rule reacts to the state of FacetWP and can change after the results refresh through AJAX. CSS usually just hides a known block in advance. A conditional rule understands that the user selected a specific facet, that the results dropped to zero, or that the page has a particular URI.

The add-on is especially useful on pages where filtering works in stages. The user first picks a broad criterion and then sees more specific filters. This reduces visual noise and helps avoid showing parameters that do not make sense before the first meaningful choice.

Where the Add-On Delivers the Most Value

• WooCommerce product catalogs where brand, size, material, or compatibility depend on the selected category.
• Directories, listings, and databases where some filters are needed only on certain pages or in specific sections.
• Sites with multiple listing templates where one set of facets serves different content types.
• Pages with empty facets that still leave headings, spacing, or theme containers behind.
• Interfaces where you need to hide technical blocks, helper text, headings, or wrapper elements together with the facet itself.

Conditional Logic should not be used as a substitute for a well-structured data model. If product attributes, taxonomies, or custom fields are filled in inconsistently, visibility rules will only hide the symptoms part of the time. First make sure your facets are indexed and displayed correctly, and only then add the conditional layer.

Who the Plugin Is For and When Another Approach Makes More Sense

FacetWP Conditional Logic is a good fit for sites that already use FacetWP and need to control facet visibility without writing custom JavaScript for every state. It works especially well on projects where filtering is a core part of navigation rather than a decorative sidebar feature. The more conditions depend on user actions, the more valuable the add-on becomes.

The plugin is particularly convenient when the site owner wants to manage the logic from the WordPress admin area. Rulesets can be renamed, temporarily disabled, reordered with drag and drop, and saved as a structured settings layer. For teams, that is often easier than keeping all visibility logic inside theme files, especially when rules change frequently because of seasonal collections, new catalog sections, or different landing pages.

That said, there are cases where Conditional Logic should not be your first choice. If you need to change WordPress queries themselves, indexing behavior, term order, mathematical relationships between facets, or the composition of the results, you should be looking at FacetWP hooks, proper listing template setup, or your data architecture. Conditional Logic controls visibility. It does not turn FacetWP into a general-purpose search algorithm builder.

When It Is the Right Fit

• You already have a working FacetWP setup and a clear set of facets.
• You need to show or hide a facet based on a selected value, a page, a template, or the result count.
• You need to remove empty containers, headings, or adjacent elements together with the facet.
• Your team wants to change rules from the interface without editing theme code.
• You are prepared to test rules on a copy of the page and keep track of ruleset order.

When Not to Start with Conditional Logic

• FacetWP is not showing results yet, or facets disappear because of a listing template issue.
• You need to change the set of posts in the query, not just the visibility of filters.
• You need complex business logic with calculations, external APIs, or user permissions.
• The site is overloaded with cache and minification to the point that AJAX updates are already unstable.
• Your editors are not ready to document the rules and may accidentally create conflicting conditions.

Practical rule of thumb: first get your FacetWP page stable without Conditional Logic. If the core facets, URL parameters, listing template, and AJAX refresh already work, conditional logic becomes a controlled improvement rather than a way to patch a broken foundation.

What to Check Before Installation and Initial Setup

Conditional Logic depends on FacetWP and its filtering page, so preparation starts with the base chain rather than the add-on itself. The page needs a FacetWP-enabled listing template. The facets need to interact with it, the URL needs to update when values are selected, and the results need to change without errors. If that foundation is not in place, rulesets will not behave predictably.

You should also confirm that your technical facet names are clear and consistent. In FacetWP, the facet name is used in the shortcode, JavaScript, and URL parameter. The documentation emphasizes that the name should be unique, short, and safe: numbers and Latin letters only, with no Cyrillic characters or special symbols. This matters for Conditional Logic because you will be working with selected facet values and sometimes CSS classes such as .facetwp-facet-categories.

If the site has multiple filtered pages, create a short map in advance: which listing template appears where, which facets exist on each page, which values should trigger rules, and which theme elements need to be hidden together with the facet. Without that map, it is easy to build a rule that looks reasonable in the admin panel but breaks a neighboring page.

Mini Checklist Before Installation

• FacetWP is installed, activated, and working on the target page.
• The page contains exactly the listing template or query that is supposed to be filtered.
• The facets are already created and displayed through blocks, shortcodes, widgets, a page builder, or the template.
• After selecting a facet value, the URL receives a parameter with the technical value.
• You understand which rules should be global and which should be tied to a specific page.
• Cache, minification, and JavaScript optimization are not interfering with FacetWP AJAX updates.

Why the URL Matters

One of the most common mistakes is entering the nice-looking facet label in a condition instead of the technical value. For example, the user may see "Alfa Romeo," while the URL value is actually alfa-romeo. That is the value you need to use in the Facet Value condition. If you enter the visible label instead, the rule will not fire even though everything looks correct on the page.

On multilingual sites, this matters even more. Visible labels may be translated, while the technical values remain different. And if you are using Page URI and the address contains encoded characters, the field needs the encoded URI rather than the human-readable version. The safest way to verify it is directly in the browser on a test page.

Installing the Add-On and Running the First Check in the Admin Panel

The official installation process for FacetWP and its add-ons is the same as for any standard WordPress plugin: upload the ZIP file through Plugins > Add Plugin > Upload Plugin or place the folder in /wp-content/plugins/, then activate the plugin. This guide does not cover purchasing, licensing, or access workarounds. The focus here is on configuring a product you already have.

After activation, open Settings > FacetWP and find the Conditional Logic interface. This is where rulesets are created. A new ruleset is enabled by default, can be temporarily disabled with the checkbox in the top left corner, and can be deleted with the red X icon. Its name can be changed through the label field, which becomes especially useful once you have more than two or three rules.

It is best to do your first check on a copy of the site or a staging page. Create the simplest possible ruleset that does not affect a critical part of the interface, for example, hiding a test informational block or one secondary facet when a specific value is selected. Do not start with a rule that hides all facets at once. If you make a mistake with the condition or ELSE branch, you can easily end up with a page that has no usable navigation.

Safe Order for the First Check

1. Open the FacetWP page and make sure filtering works without Conditional Logic.
2. Create a ruleset with a clear name, such as Hide model until brand selected.
3. Add one condition that is easy to verify in the URL or on the page.
4. Add one Hide or Show action without affecting all facets.
5. Choose the ELSE behavior carefully. For an initial test, Do nothing is usually the safer option.
6. Save the settings and test the page both in a normal browser window and while logged out.

After the first save, do not judge the result only from the admin's point of view. Check the URL, active selections, result count, and behavior after resetting the filters. Conditional Logic runs on the public front end, and some problems only show up after an AJAX refresh.

Rulesets: How the IF, THEN, and ELSE Chain Works

A ruleset is a single rule. Inside it, you have conditions, actions, and ELSE. The conditions answer the question "when is this rule true," the actions answer "what should happen," and ELSE defines what happens when the conditions are not met. If a ruleset has no conditions, its actions apply all the time. That can be useful for global actions, such as hiding empty facets, but it is also risky because forgetting to add a condition can hide an important element on every page.

The documentation describes the logic as pseudocode: if the condition is true, perform the action; otherwise, perform the opposite action or do nothing. The interface looks simpler than that, but this mental model is what helps you design rules without conflicts.

Conditions

Conditions define what gets checked. In Conditional Logic, you can use basic conditions, facet value conditions, and listing template conditions. Basic conditions include cases such as "no facets in use," "some facets in use," Page URI, and Result count. For Page URI, Result count, and Facet Value, you can choose either is or is not as the comparison.

Multiple conditions can be joined with AND or OR logic. Use AND when the rule should run only if all conditions are true at the same time. Use OR when any one of the conditions is enough. Facet value conditions also support multiple values in a single condition separated by commas, and those values work as OR. If you need true AND logic between multiple values, it is usually better to create separate single-value conditions and combine them with the appropriate operator.

Actions

Actions define what happens next. Each action has two key fields: toggle and object. The toggle is usually Show or Hide. The object can be a specific facet, all facets, the listing template from the condition, or a custom selector. Multiple actions inside one ruleset are always applied as AND: if the rule matches, every action is executed.

Custom selectors make the add-on much more flexible because they let you target not only the facet itself but also its container, heading, neighboring block, or theme wrapper. What matters here is that the add-on uses FacetWP's built-in fUtil library rather than full jQuery. Many familiar methods are available, including closest(), find(), parents(), prev(), and next(), but not everything from jQuery is supported.

ELSE

ELSE looks like a small setting at the bottom of the actions panel, but it is often the source of unexpected behavior. The Do the opposite option reverses the action when the condition is false. If the action hides a facet when the condition is true, the opposite branch will show it when the condition is false. The Do nothing option leaves the element unchanged when the conditions are not met.

For rules tied to Page URI, it is usually best to start with Do nothing. If multiple rulesets using Page URI and Do the opposite affect the same facet, they can override each other based on their order on the page. That is not a plugin bug. It is simply the result of each rule honestly applying its own ELSE branch.

Ruleset Order

Rulesets are applied from top to bottom in the order shown in the admin panel. You can change the order by dragging them using the icon in the top left corner. If two rulesets control the same facet or the same custom selector, the lower one can effectively undo what the upper one did. That is why order is part of the configuration, not just visual housekeeping.

A good practice is to place broad, general rules higher up and more specific rules lower down only when they truly refine the result. But if a specific rule needs to protect an element from being hidden by a global rule, the order may need to be reversed. Make a note of that in your project documentation, because a month later the reason for the reorder will no longer be obvious.

Using Facet Value, Page URI, and Result Count Without the Usual Mistakes

These three conditions provide the most practical value and also cause the most mistakes. Facet Value lets you react to a user selection. Page URI limits a rule to one page or a group of pages. Result Count lets you show or hide elements based on the number of results. They are worth covering separately because this is where Conditional Logic stops being a simple hide/show tool and becomes a real interface design instrument.

Facet Value: Use the Technical Value

When a user selects a facet value, FacetWP adds a parameter to the URL. If the facet is named make and the selected value is bmw, the URL will contain something like ?_make=bmw. The condition must use bmw. If the visible label on the site says "BMW," "Bmw," or a localized version, that does not mean the same value is used in the logic.

For taxonomy terms, the technical value often matches the slug, while the display value remains a human-readable label. For custom fields, they may be the same. If a value contains special characters, it may be processed differently. That is why there is really only one reliable method: select the value on the public page, inspect the URL, and take the value from there.

Empty Value in Facet Value

If you leave the value field empty, the condition can check whether the facet is in use or not. That works well for cases such as "show the Size filter only after Category is selected" or "hide Size while Category is empty." In many cases, that is better than listing every possible category, especially if editors regularly add new terms.

Page URI: Not the Full URL and Not a Path with Extra Slashes

In Conditional Logic, Page URI is the part of the address after the domain, with no leading or trailing slash and no query variables. For the page https://example.com/shop/, the correct value is shop, not /shop and not shop/. For the home page, the field should be left empty.

The wildcard * is supported only at the end and only once per condition. For example, shop/*, shop*, or shop/category-* are valid, while */brand and shop/*/ are not. It is better to account for that limitation early so you do not build your rule architecture around an unsupported pattern.

Result Count: Show Helpers and Actions Based on Output State

The Result count condition is useful when the interface should react to how many items were found. For example, you might show an explanatory block when there are zero results, hide an irrelevant CTA, remove an extra sorter, or suggest resetting the filters. But this condition should be used carefully: the result depends on the current selection, the FacetWP index, and the listing template query.

If a result count rule is not working, do not start by rewriting the ruleset. First verify that the selected facets really produce the expected number of results, that the listing is updating, that cache is not interfering, and that there is no indexing issue. A visual block may be hiding correctly while the real problem is in the data.

The best way to avoid confusion is to design rules from the page state outward: what the user selected, what URL appeared, how many results remain, which element should disappear, and what should become visible in its place.

Custom Selectors, Special Targets, and Hiding Containers

In a real theme, a facet rarely exists by itself. Usually there is a heading next to it, a wrapper, a grid column, a WordPress widget, a page builder block, or a container with spacing. If you hide only the facet, the page may still show an empty heading, border, or gap. That is why Conditional Logic supports custom selectors in actions.

To use a custom selector in an action, add an action, choose Hide or Show, then select Selector as the object. A field will appear where you can enter one or more selectors, each on a new line. This makes it possible to control not only the facet itself but also its surrounding elements.

Common Selectors

If a facet is named categories, its standard class on the page often looks like .facetwp-facet-categories. To hide the parent widget, you can use a chain with closest():

$('.facetwp-facet-categories').closest('.widget')

If your facets are wrapped in a custom container such as .facet-wrap, it is usually better to hide that container directly:

$('.facetwp-facet-size').closest('.facet-wrap')

This approach is safer than trying to guess spacing with CSS. You are removing the full logical filter block instead of leaving behind an empty page skeleton.

Special Targets $EMPTY, $NONEMPTY, $ACTIVE, and $INACTIVE

Conditional Logic supports special target selectors: $EMPTY, $NONEMPTY, $ACTIVE, and $INACTIVE. They let you target groups of facets by state. For example, $EMPTY targets empty facets with no visible choices, while $ACTIVE targets facets that currently have an active selection.

To hide containers for empty facets inside WordPress widgets, you can use:

$EMPTY.closest('.widget')

If your facets have automatically added labels or headings and the wrapper uses the class .facet-wrap, this is often a better fit:

$EMPTY.closest('.facet-wrap')

One important detail is the ghosts setting. The official documentation warns that facets with ghost choices enabled will not be treated as empty in this sense. So if $EMPTY is not catching the facet you expect, check the settings for that facet type and how its choices are displayed.

Headings and Mobile Flyout

If the heading appears before the facet and is not inside a shared wrapper, you can target it separately with prev(). For example:

$('.facetwp-facet-size').prev('h3')

For Mobile Flyout, the documentation shows a different selector format for automatically added labels: .flyout-row.name-myfacetname h3. That is a separate case because the flyout structure is different from a normal sidebar. Do not blindly reuse a desktop selector inside the flyout.

What Not to Do with Selectors

• Do not use an overly broad selector such as .widget if the rule is supposed to affect only one filter.
• Do not rely on temporary theme or page builder classes that may change after an update.
• Do not use jQuery methods that are not available in fUtil without checking the documentation first.
• Do not hide containers that also include important navigation, reset controls, or result messages.

A good selector should be precise, readable, and easy to verify. If you cannot tell what block it hides a week later, the rule is already too fragile.

Detailed Post-Install Setup: From a Simple Rule to a Manageable System

After installation, do not rush into creating ten rulesets at once. Start with a behavior map. Split your rules into groups: global, page-specific, selection-driven, result-driven, and helper rules for containers. That structure helps avoid chaos because Conditional Logic applies rulesets sequentially.

In the interface, each ruleset should have a clear name. The name should explain the intent, not just repeat the technical selector. For example, Hide empty sidebar widgets is clearer than $EMPTY closest widget, and Show model after make selected is much more useful than Rule 3. The name does not affect the logic, but it absolutely affects how maintainable the site is.

Step 1. Set Up Basic Visibility Rules

The first layer is made of rules you almost always need. For example, hiding empty facet wrapper elements so the page does not show headings with no available choices. In that case, you can use the special selector $EMPTY and the parent container. For this kind of rule, Do the opposite often makes sense in ELSE, because if the facet is no longer empty, its container should come back.

But there is one exception: if another ruleset may intentionally hide the same container for business logic reasons, the automatic opposite action can bring that block back too early. In that case, it is better to split the rules or use Do nothing and let a separate, more precise ruleset restore visibility.

Step 2. Configure Staged Facets

For dependent filters, it is convenient to use Facet Value with either an empty value or a specific value. Example: hide size until category is selected. If any category is selected, show size. If you need that behavior only for one category, use the technical value from the URL.

In a product catalog, this reduces noise: the user first chooses a section and then gets additional parameters. In a professional directory, it might be a "city" - "district" - "service" chain. In a knowledge base, it could be "product" - "documentation version" - "article type." The key is not to hide a filter the user needs for the first meaningful step.

Step 3. Separate Rules by Page

If the same facet set is used on multiple pages, Page URI helps make your rules more targeted. For example, on shop you may want to show general product filters, while on shop/sale you want to hide certain parameters. But Page URI is especially sensitive to slashes, caching, and language-specific URLs. Enter the URI without the domain, without a leading or trailing slash, and without the query string.

If you need to cover a group of pages, use a wildcard at the end. But do not build complex masks with a wildcard in the middle, because Conditional Logic does not support that. For more complex routing, it can sometimes be better to target a body class through a custom selector, as the documentation suggests.

Step 4. Check ELSE and Order

After saving each rule, test it in two states: when the condition is true and when it is false. If the true state hides a facet, make sure the false state does not bring it back where another rule is supposed to keep it hidden. If you are using Do the opposite, make sure to test neighboring pages and reset behavior as well.

Check ruleset order not only in the admin panel but also in real scenarios: page load, facet selection, value changes, reset, and opening a direct URL with parameters already selected. FacetWP stores state in the URL, which means users can land on a page with an active query string already in place.

Step 5. Save a Backup of Your Rules

Conditional Logic includes import/export in the add-on settings tab. Export is useful before a major change, a site migration, or an experiment with a new set of conditions. Import replaces the existing rulesets, so it should be used only after making a backup and only on a clearly understood version of the site.

Before importing, write down exactly what is supposed to change. If the import replaces your rules and you no longer remember the original state, recovery turns into manual troubleshooting rather than a quick rollback.

Practical Example: Dependent Filters for a Product Catalog

Let us walk through a scenario that clearly shows the value of FacetWP Conditional Logic. Imagine a WooCommerce catalog with a FacetWP listing template. The sidebar contains product_category, brand, size, color, price, and reset facets. Before the user makes the first choice, the page shows too many parameters, and some facets become empty or irrelevant in certain categories.

Goal

The goal is to create cleaner filtering: before a category is selected, show only category, price, and reset. After a category is selected, show brand, color, and size, but hide size if the selected category is not related to clothing. Empty facet containers should disappear together with their headings.

Preparation

The page should already have working FacetWP, WooCommerce source fields, and a listing template. You need to know the technical name of each facet. For category values, check the slug in the URL. For example, after selecting "Clothing," the URL might contain ?_product_category=clothing. That means the condition must use clothing, not the visible label.

Rule 1: Hide Empty Filter Blocks

Create a ruleset called Hide empty facet wrappers. Do not add any conditions so the action applies all the time. In actions, choose Hide, set the object to Selector, and use this selector:

$EMPTY.closest('.facet-wrap')

You can leave ELSE as Do the opposite if this rule does not conflict with other visibility rules. If your wrapper class is different, replace .facet-wrap with your theme's container.

Rule 2: Show Refinements After Category Selection

Create a ruleset called Show refinements after category. Add this condition: Facet Value for the product_category facet, comparison is not, and leave the value empty. That means the condition is true when the category facet is in use. In actions, choose Show for the brand, color, and size facets. In ELSE, choose Do the opposite so those refinements stay hidden until a category is selected.

Rule 3: Size Only for Clothing

Create a ruleset called Size only for clothing. Add this condition: Facet Value for product_category is clothing. In the action, choose Show for size. For ELSE, choose Do nothing if the previous rule is already controlling the base visibility of size. If you choose Do the opposite here, the rule can conflict with other categories and make size reappear where you do not expect it.

Verification

1. Open the catalog with no parameters in the URL. Only the basic facets should be visible.
2. Select the clothing category. Brand, color, and size should appear.
3. Select another category. Size should disappear if the rule is truly limiting it to clothing.
4. Reset the filters. The refinements should return to their initial hidden state.
5. Open a direct URL with ?_product_category=clothing. The page should load immediately with the correct visibility state.

One Important Detail

If size does not appear after selecting clothing, check three things: the technical value in the URL, the ruleset order, and whether the facet is empty. If size is empty for the current selection, the rule $EMPTY.closest('.facet-wrap') may be hiding it correctly. In that case, the problem is not Conditional Logic but your product data or the FacetWP index.

Verifying the Result on the Site and in FacetWP Data

Testing Conditional Logic needs to be scenario-based. It is not enough to open the page and see that some block disappeared. You need to confirm that the user can move through the flow without dead ends: select a value, see the right refinements, reset the filters, keep access to key navigation, and avoid landing on a page with an empty sidebar area.

Start from the state with no active filters. Then test one facet, several facets, a value that produces zero or very few results, reset, a direct URL with a query string, and another page using the same set of facets. If you are using Page URI, separately verify pages that should match the rule and pages that should not.

What to Check Visually

• The facet is hidden together with its heading and outer container if that is the intended behavior.
• After the AJAX refresh, there are no empty gaps, borders, or separators left behind.
• The reset button or User Selections remain available if the user could otherwise get lost in the filters.
• Mobile Flyout does not show headings for hidden facets.
• When entering through a direct URL, the state matches the selected query variables.

What to Check Technically

• The URL uses the correct technical values.
• Facet names do not conflict with reserved WordPress query variables.
• There are no two rulesets controlling the same selector for no clear reason.
• FacetWP Debug Mode is turned off after troubleshooting, because it can expose settings and affect performance.
• Page caching and script optimization are not breaking AJAX updates.

For production sites, keep a short rule log: ruleset name, condition, action, ELSE behavior, page of use, tested scenario, and date of change in your internal documentation. Dates do not belong inside the HTML guide itself, but for your team this record can save hours during the next revision.

A good sign that the setup is successful: the user does not notice Conditional Logic as a separate feature. They simply see fewer unnecessary filters and reach the right result faster.

Compatibility with Themes, Cache, WooCommerce, and Page Builders

FacetWP Conditional Logic works on top of FacetWP, which means it inherits the same requirements for proper front-end output. If your theme, page builder, or custom template renders facets inside unusual wrapper elements, you will need to choose selectors based on the actual markup. If a WooCommerce catalog uses non-standard loops, first make sure FacetWP is filtering the exact query the user actually sees.

With caching, there are two layers to consider. Standard page cache speeds up the initial HTML page, but FacetWP AJAX requests are usually not served as static HTML. That is why the first page load can be fast while filtering after a click feels slower. That is a normal characteristic of AJAX filtering, not necessarily a Conditional Logic issue.

The official source also warns that rulesets using Page URI may behave inconsistently in some cases when a caching plugin is involved. One possible fix is to exclude that page from cache or use conditions that do not depend on Page URI. This does not mean you must always disable cache. It means Page URI rules need to be tested under the site's real caching setup, not just while logged in as an administrator.

WooCommerce

On WooCommerce sites, Conditional Logic is often used for categories, attributes, brand facets, stock facets, and price ranges. But before configuring visibility, check how FacetWP indexes products and variations. If variation support is enabled, the index may be heavier. If out-of-stock products should not appear, the relevant FacetWP and WooCommerce settings should be aligned before you start building rules.

Page Builders and Blocks

If facets are added through blocks or a page builder, the HTML structure may differ from that of a classic widget. FacetWP documentation notes that the Facet block has its own Hide when empty setting, which can replace custom code for empty facets. So do not duplicate the same behavior in both the block setting and Conditional Logic unless you have a clear reason to do so.

Mobile Filtering

If you use the Mobile Flyout add-on, check the separate structure of the flyout rows. Hiding the desktop wrapper does not always hide the mobile heading. For automatic labels in Mobile Flyout, the documentation recommends a selector such as .flyout-row.name-myfacetname h3. Test the mobile scenario on a real viewport: the user should understand why some filters appear only after a selection is made.

Safe Enhancements and Technical Techniques

Conditional Logic already covers most scenarios without code. But in some cases, you may want to add lightweight diagnostics or grant access to settings for an editor role. Any code should be small, reversible, and placed in a child theme, Code Snippets, or the official Custom Hooks add-on. Do not edit WordPress core, FacetWP, the add-on, or the parent theme files.

Diagnostics After Applying Rulesets

The official Conditional Logic documentation describes two JavaScript hooks: facetwp/ruleset/apply for a specific ruleset and facetwp/rulesets/apply after all rulesets have been applied. The following snippet is suitable only for temporary diagnostics on a test page. It outputs an event to the browser console after all rulesets have been applied. Remove it after testing.

add_action('facetwp_scripts', function () {
  ?>
  <script>
    FWP.hooks.addAction('facetwp/rulesets/apply', function() {
      console.log('Conditional Logic rulesets applied');
    });
  </script>
  <?php
}, 100);

The check is simple: open the page with facets, select a value, then inspect the browser console. If the message appears after FacetWP refreshes, the hook is firing. If you see the error FWP is not defined in the console, the snippet is loading in the wrong place or on a page without FacetWP. To roll it back, remove the snippet and clear the site cache.

Giving Editors Access to Settings

The version of Conditional Logic with the updated interface introduced the ability to manage access through the facetwp_admin_settings_capability hook. This affects not only Conditional Logic settings but also the main FacetWP settings and the Caching add-on, so it should not be granted to a role you do not trust. It is safer to assign a separate capability through a role manager and test access on staging.

If your team is not confident about permissions, it is better not to add code at all. Assign one responsible administrator and keep a ruleset change log. A mistake in conditional logic may not break the site technically, but it can easily make navigation worse for visitors.

Local CSS Cleanup Without Touching the Logic

If a small visual gap remains after a wrapper is hidden, do not try to fix it with another ruleset. In some cases, a bit of CSS for a specific theme container is enough. But that CSS should be independent of FacetWP logic and should not hide facets based on state. For example, you can normalize the spacing of an empty wrapper if the theme leaves a margin behind:

.facet-wrap:empty {
  margin-bottom: 0;
}

Test the CSS on pages without FacetWP and after AJAX refreshes. If the rule starts hiding elements that should remain visible, remove it and solve the problem with a custom selector inside Conditional Logic instead.

Working Ruleset Recipes for Different Pages

Once the basic setup is in place, it helps to move from abstract logic to practical rule recipes. These are not universal templates meant to be copied verbatim, but they show the thought process: which state to check, which object to change, which ELSE behavior to choose, and how to verify that the rule does not conflict with neighboring rulesets. In practice, these small scenarios are what turn Conditional Logic from a set of toggles into a clear filtering design tool.

Before using any recipe, replace the facet names, values, and selectors with your own. Do not guess them from the visible label in the interface. Open the page, select a value, inspect the query string, verify the facet's HTML class, and only then recreate the rule in the admin panel. If the site is multilingual, repeat the check for each language because URI patterns and values may behave differently.

Recipe 1: Hide Refinement Filters Until the First Selection

This scenario works well on pages where the user should first choose a broad category. For example, in a real estate catalog, the first choice may be property type, and only then district, room count, and features. In a knowledge base, the first choice may be product, followed by article type, difficulty level, and documentation version. The point of the rule is to avoid overloading the first screen and to keep refinements hidden until there is context.

Create a ruleset called Show refinements after primary facet. In the condition, choose the main facet, for example property_type, set the comparison to is not, and leave the value empty. That means the condition is true when the facet is already in use. In actions, add Show for the refinement facets: district, rooms, and features. In ELSE, choose Do the opposite if those facets really should stay hidden until the first selection.

Test three states: the page with no parameters, the page after the main facet is selected, and the page after reset. If the refinement facets stay visible before a selection is made, check the ruleset order. There may be another rule farther down that shows them again. If they do not appear after selection, check whether they are being hidden by an $EMPTY rule. That outcome may be correct if the selected property type has no available values for those facets.

Recipe 2: Different Filter Sets for Different Site Sections

Page URI is convenient when the same FacetWP logic serves multiple sections. For example, you might have a shared catalog at resources and sub-sections at resources/plugins, resources/themes, and resources/tutorials. The plugins page may need a compatibility facet, the themes page a layout facet, and the tutorials page a difficulty-level facet. Users should not see a filter that belongs to the wrong section.

Create a separate ruleset for each section. For the page resources/plugins, the condition would be Page URI is resources/plugins. Action: Show the required facets, such as compatibility and license. ELSE is usually safer as Do nothing if neighboring pages are controlled by other rulesets. Then create separate rules for resources/themes and resources/tutorials.

The biggest risk with this approach is trying to handle all sections with one ruleset through the opposite branch. If a rule says "show compatibility on plugins, otherwise hide it" and sits above or below a similar rule for themes, the two rules can keep overriding each other. For multi-page setups, it is safer to use precise rulesets with Do nothing and one separate base rule that hides all special facets until the page-specific rule takes over.

How to Check Page URI

Open the page without a query string and write down only the part after the domain. For https://example.com/resources/plugins/, that is resources/plugins. If the URL also contains a filter such as ?_category=seo, do not include that part. If you need a group of nested pages, resources/plugins* or resources/plugins/* can work, but a wildcard at the beginning cannot.

Recipe 3: Show a Helper Block When There Are No Results

A user can select a combination of facets that is too narrow and end up with an empty result list. In that case, it is useful to show a helper block suggesting that they clear one filter, choose a broader category, or check the spelling in a search facet. Result Count makes it possible to tie that helper block to the number of results.

Prepare a helper block on the page with a class such as .no-results-help. Hide it by default through the theme or a separate initial ruleset. Then create a ruleset called Show help when result count is zero. Condition: Result count is 0. Action: Show, object Selector, selector $('.no-results-help'). In ELSE, Do the opposite is usually a good choice so the helper disappears as soon as results return.

Your test should include not just the zero-results case but also the return to a normal result set. Choose an overly narrow combination, confirm that the block appears, then remove one filter or hit reset. The helper should disappear. If it stays visible, check whether another rule is showing that selector regardless of result count.

Recipe 4: Hide a Technical Intro Block After the First Selection

On some pages, a short instruction appears above the filters, such as "Choose a category to see more options." Once the user makes a selection, that text only gets in the way. For this case, you can use either the "some facets in use" condition or the Facet Value of the main facet. If the helper relates only to the first selection, the main facet is the better trigger.

Create a ruleset called Hide intro hint after primary selection. Condition: main facet is not with an empty value. Action: Hide, object Selector, selector $('.facet-intro-hint'). ELSE: Do the opposite. The logic is easy to follow: while the main facet is empty, the hint is visible; as soon as the user makes the first choice, the hint disappears.

If your site uses direct URLs with a facet already selected, test those separately. The hint should already be hidden when the page loads from such a URL. This is an important check because users often arrive from saved links, internal linking, or ads with preselected filters.

Recipe 5: Separate Selectors for a Heading and a Facet

Sometimes a theme outputs the filter heading outside the wrapper. In that case, closest('.facet-wrap') will not help. You can add two selectors to a single action, one per line: the facet itself and the heading immediately before it. For a size facet, that can look like this:

$('.facetwp-facet-size')
$('.facetwp-facet-size').prev('h3')

This approach is best used as a temporary solution when you cannot change the markup. A more stable option is to wrap the heading and facet in one shared container and hide that container. But if the project is built on a ready-made theme or a page builder, a focused selector is often faster and safer than editing the template.

The general rule for all recipes: one ruleset should have one clear purpose. If a single rule hides empty facets, handles Page URI, reacts to category selection, and shows a zero-results helper all at once, troubleshooting becomes much harder. Split rules by intent and name them so a future administrator can understand the purpose without rereading the entire article.

Common Conditional Logic Issues and How to Diagnose Them

Conditional Logic problems often look similar: a facet does not hide, hides in the wrong place, reappears after a selection, or disappears together with a neighboring block. But the causes are different. That is why troubleshooting should start not from the feeling that "the plugin is broken," but from the actual chain: condition, action, ELSE, ruleset order, selector, cache, and the current FacetWP state.

The Rule Does Not Fire When a Facet Value Is Selected

Symptom: the user selects a value, but the target facet or block does not change visibility. One likely cause is that the condition uses the visible label rather than the technical value. Check the URL after the selection. If it shows ?_make=alfa-romeo, then the condition must use alfa-romeo, even if the page displays "Alfa Romeo."

Also verify that the condition is tied to the correct facet. On sites with similar facets such as category, product_category, and brand_category, choosing the wrong source is a common mistake. The fix is to select the correct facet name, save the rule, clear cache, and repeat the scenario.

Page URI Works Only Sometimes

Symptom: the rule works on one page but not on a similar one, or becomes inconsistent after caching is enabled. Check the URI format first. You must enter the part after the domain with no leading or trailing slash. For the home page, leave the field empty. If you are using a wildcard, it must appear only once and only at the end.

If the format is correct, temporarily exclude the test page from cache or test the rule without Page URI. FacetWP documentation explicitly warns that Page URI and caching plugins can produce inconsistent behavior. If the rule becomes stable when cache is disabled, configure a cache exclusion for that page or switch to a template/body-class-based condition instead.

One Ruleset Cancels Out Another

Symptom: a facet hides at first, then reappears after the AJAX refresh, or the opposite happens. The cause is often the combination of ruleset order and Do the opposite. Rulesets run from top to bottom. If two rules control the same object, the lower one can change the result produced by the upper one.

The fix is to temporarily disable rulesets one by one, find the conflict, then reorder them or change ELSE to Do nothing in one of the rules. Pay especially close attention to the combination of Page URI and opposite-action behavior, because in that case ELSE applies to every page that does not match the URI.

The Facet Hides but an Empty Heading Remains

Symptom: the filter field disappears, but the heading, border, or widget stays in place. The reason is that the action targets only the facet, not the wrapper. Use a custom selector with closest(), prev(), or the exact container class. For example, if the wrapper is .facet-wrap, you can hide $('.facetwp-facet-size').closest('.facet-wrap').

Do not use an overly broad selector, or you may hide neighboring elements along with the filter. If the mobile structure is different, configure a separate selector for Mobile Flyout.

$EMPTY Does Not Catch the Facet

Symptom: a facet that looks empty is not hidden by $EMPTY. One possible reason is that ghost choices are enabled, or the facet is not technically considered empty. Check the facet type settings. In some cases, ghost elements display unavailable options, so Conditional Logic does not treat the facet as empty.

The fix depends on your goal. If you specifically need to hide blocks with no available choices, disable ghosts where they are not needed. If ghosts are important for UX, do not use $EMPTY for that facet and control visibility through Facet Value or a more specific scenario instead.

Filtering Became Slow After Setup

Symptom: the page takes a long time to update after clicking a facet. Conditional Logic is rarely the main reason for slow requests, because the heavy work is usually done by the AJAX refresh, the WordPress query, the FacetWP index, the number of facets, and the theme. First check the speed of the base FacetWP page without the new ruleset.

The official documentation points out that FacetWP AJAX requests do not benefit from standard page cache in the same way the initial HTML page does. If the site is large, check the number of indexed post types, WooCommerce variations, the number of facet choices, and overall server health. After diagnostics, Debug Mode should be turned off again.

Import Replaced the Rules

Symptom: your original rulesets disappeared after an import. That is expected behavior: importing rulesets replaces the current set. The fix is to restore your exported copy if you have one. If not, you will have to rebuild the rulesets manually from your change log. That is why you should always export first and save the text in a separate file before importing.

Questions About Setting Up FacetWP Conditional Logic

Can I use Conditional Logic without the main FacetWP plugin?

No. It is an add-on for FacetWP and depends on the facets, listing template, URL parameters, and front-end logic of the main plugin. You need a working FacetWP setup first, and only then do you add conditional logic.

Why does the condition need a slug or technical value instead of the label shown on the site?

FacetWP stores and passes selected values through technical URL values. The visible label may differ, be translated, or contain spaces. Conditional Logic checks the state of FacetWP, so you need to rely on the value from the URL, such as alfa-romeo, not the label "Alfa Romeo."

What should I choose in ELSE: Do the opposite or Do nothing?

Do the opposite is convenient when one rule fully controls the visibility of a single object. Do nothing is safer when other rulesets also affect the same facet, when Page URI is involved, or when you want to avoid an automatic restore of the element. On more complex pages, start with Do nothing and add opposite behavior only after testing.

Can I hide not only facets but also theme blocks?

Yes, through a custom selector. You can target a wrapper, widget, heading, or another element. But the selector must be precise and compatible with fUtil. Do not use overly broad classes, or you may hide unrelated parts of the page.

What should I do if rules break after caching is enabled?

First check whether the rule depends on Page URI. For those conditions, FacetWP documentation specifically notes possible inconsistency with caching plugins. Test the page without cache, then add an exclusion or replace the condition with a template/body-class-based approach. Also make sure JavaScript optimization is not interfering with FacetWP AJAX behavior.

Does Conditional Logic help speed up filtering?

Its main job is visibility control, not query performance. It can improve the perceived experience by hiding unnecessary elements, but AJAX filtering speed depends on the server, theme, data volume, the FacetWP index, WooCommerce variations, and other plugins. For performance work, look at FacetWP settings, the index, and the Caching add-on.

Do I need to add code for a normal setup?

Usually not. Most tasks can be handled with rulesets, conditions, actions, ELSE, and custom selectors. Code is only needed in less common cases such as diagnostics after rulesets are applied, special access permissions, or additional integration. Any code should go only into a child theme, Code Snippets, or the Custom Hooks add-on, and it should always be easy to roll back.

When FacetWP Conditional Logic Is the Right Choice

FacetWP Conditional Logic is worth using when your core filtering already works, but the interface needs to become smarter: remove empty groups, show refinement filters only after the first selection, adapt the facet set to the page, hide wrappers together with headings, and control helper blocks based on result state. This is not a decorative add-on. It is a UX logic layer on top of FacetWP.

Before rolling it out, verify the foundation: listing template, facet names, URL values, index, cache, and mobile interface. Then build rulesets gradually, document their order, avoid overusing Do the opposite, and test direct URLs with active selections. That approach makes the setup predictable even on a complex catalog.

If that matches your site's needs, you can download FacetWP Conditional Logic and test the add-on on a page copy first. The safest starting point is one simple rule, one clear selector, and a result check after every change.