FacetWP plugin review and common issues

FacetWP uses a “facetwp-template” CSS class to identify the container element it should refresh when filters are applied. In your listing page template or shortcode, the container holding the posts/products loop must have the CSS class facetwp-template. Go to FacetWP → Settings → Templates and verify the template is configured for your listing page. If using a custom theme template, add class=”facetwp-template” to the outer container div of the posts loop. If using shortcodes, the FacetWP template shortcode handles this automatically. Also ensure the FacetWP JavaScript loads on the page.

The price slider range is calculated from indexed product prices. If the range seems wrong: (1) re-index FacetWP (FacetWP → Settings → Index → Re-index) to rebuild price data from current product prices; (2) check if products have sale prices or variable pricing that affects the range calculation — FacetWP uses the regular price by default, configurable to use sale price; (3) custom price fields (from pricing plugins) may not be recognized automatically — configure the facet’s data source to point to the correct price meta key; (4) filter out products with $0 prices that may skew the minimum range.

FacetWP has its own pagination facet type that handles Ajax pagination correctly. If using standard WordPress pagination (next/previous post links or numbered pagination), they may conflict with FacetWP’s Ajax system. Replace standard pagination with a FacetWP Pager facet (FacetWP → Facets → Add New → Pager type). Place the Pager facet shortcode on your listing page. This provides Ajax-based pagination that maintains facet state across pages without resetting the active filters.

FacetWP’s Proximity facet requires latitude/longitude coordinates stored in custom fields for each listing. Ensure each post has latitude (e.g., meta key: lat) and longitude (e.g., meta key: lng) fields populated. Create a new FacetWP facet of type “Proximity,” configure the latitude and longitude field keys, set the default radius unit (miles or km), and optionally set a default location. On the frontend, the proximity facet shows a location input field and a radius selector. Users enter their location and select a radius — FacetWP returns posts within that distance using haversine formula calculation.

Create a new FacetWP facet of type “Checkboxes” or “Radio” (for single-select). In the Data Source dropdown, select the WooCommerce product attribute you want to filter by (e.g., “Product Attribute: Color”). FacetWP automatically extracts all available color terms from products. Place the facet shortcode [facetwp facet=”color”] in your shop or category template alongside the [facetwp template=”woocommerce”] template. After re-indexing FacetWP, the color facet appears with checkboxes for each available color — selecting one filters the product grid to matching products.

FacetWP is significantly more powerful than WooCommerce’s built-in layered navigation widget. FacetWP provides more facet types (sliders, hierarchical, proximity, date range vs. just checkboxes), true Ajax updates without page reload, shareable filtered URLs, and integration with improved search plugins. WooCommerce layered navigation is free and adequate for simple stores with few attributes. For stores with complex product attributes, large catalogs, or customers who need sophisticated filtering, FacetWP’s investment pays off in measurable conversion improvement.

Yes — FacetWP works with any WordPress content including custom post types. A real estate plugin’s Property post type, a job board’s Job Listing post type, a recipe plugin’s Recipe post type — any content type with structured meta fields and taxonomy terms can be filtered with FacetWP. Configure the facet data sources to point to the meta keys or taxonomy slugs used by your custom post type.

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.