Designing a product filtering system for 1C-Bitrix

Product Filter System Design for 1C-Bitrix

The filter in a catalog is where architectural decisions manifest most painfully. A slow filter is almost always the result of incorrect property types or a missing facet index. An incorrect filter (showing products that don't exist, or failing to find ones that do) is the result of confusion between product properties and trade offer properties. A filter that returns zero results when combining criteria is a problem with AND vs. OR logic within a property.

The bitrix:catalog.smart.filter Component: Capabilities and Limitations

The standard smart filter component in Bitrix supports:

• Filtering by "List" and "Reference" (HL-block) type properties using the facet index
• Range filtering for numeric properties (price, size)
• Filtering by trade offer properties (OFFER_IBLOCK_ID)
• SEO URL generation for selected filters (SEF_FOLDER)
• AJAX updating of the product list without page reload

Limitations:

• Does not support filtering by properties from multiple iblocks simultaneously
• Does not compute smart combinations (showing available values based on already selected ones)
• Does not support geo-filtering out of the box

When the standard component is insufficient, a custom filter is built using direct SQL queries against the facet tables or with ElasticSearch.

Filter Logic: AND Within a Property vs. AND Between Properties

A design decision that is often overlooked. Example: a product has a "Color" property with multiple values ("red", "blue"). The user selects "red" and "blue" simultaneously.

OR logic: show all products that have red OR blue. Most filters work this way. AND logic: show only products that have both red AND blue. Makes sense for tags ("show articles tagged with both 'Laravel' and 'PostgreSQL'").

The standard Bitrix filter component uses OR within a single property and AND between different properties. Changing this without modifying the component is not possible.

Filtering with Stock Availability

A common scenario: the filter shows property values where all products are out of stock. The user selects "red" and gets 0 results.

Solution at the facet index level: when the index is rebuilt (\Bitrix\Iblock\PropertyIndex\Manager::runIndex()), Bitrix automatically excludes elements with ACTIVE = N. But stock levels are not accounted for automatically — a custom mechanism is needed:

• Event handler for stock changes in b_catalog_store_amount
• Update the IN_STOCK flag property on the parent product
• Elements with IN_STOCK = N are marked inactive or filtered out in the component

SEO URLs for Filters

Bitrix generates SEO URLs for the filter automatically when SEF URLs are configured for the catalog.smart.filter component. Format: /catalog/smartfon/filter/brand-is-samsung/. But this only works with correct SEF_FOLDER configuration and corresponding rules in urlrewrite.

Design decision: which filter combinations get SEO pages with meta tags, and which simply work without being indexed. For large catalogs, generating all combinations in the sitemap is impractical — a prioritization strategy is needed (e.g., only single-factor filters).

Case Study: Filter System for a Clothing Marketplace

A multi-vendor platform with 180,000 SKUs across 8 clothing categories with different attributes. Requirement: a unified filter accounting only for variants in stock.

The challenge: attributes vary by category. In "Footwear" — shoe size (35–46), in "Outerwear" — size (XS–4XL) and length. Building a single facet on one iblock with 60 properties would mean showing "Shoe size" in the "Jackets" section.

Solution:

• Single iblock, but a filter with a dynamic set of properties depending on the section
• A custom category_filter_props table (via DataManager): category → list of properties to display in the filter
• Facet index on the offers iblock with a stock availability flag
• An agent runs every 30 minutes and updates offer activity based on stock

Result: filter by size + color + availability — 0.2 seconds on 180,000 SKUs.

What Filter System Design Includes

• Analysis of attributes to be filtered
• Choosing property types with the facet index in mind
• Designing filter logic (AND/OR, stock availability handling)
• Configuring bitrix:catalog.smart.filter or designing a custom solution
• Designing SEO URLs for filters
• Facet index update strategy
• Test scenarios: correctness, performance, edge cases

Design timeline: 3–10 working days depending on the number of categories and requirements for SEO and stock availability handling.