Dynamic Filter Configuration in mFilter2 for Auto-Synced Product Options

This scenario came from a Revo and miniShop2 stack, but the problem is broad enough to be useful in the Evolution ecosystem too: product options were generated automatically from an external 1C synchronization, while the filter layer still expected every option to be configured statically by hand.

That model works only for a while. Once new options appear outside the editorial workflow, someone has to notice them, add them to the filter configuration, and assign the right template. That is not sustainable on a busy catalog.

The real design problem

Static filter definitions do not age well when the option schema is dynamic. The right question is not just “Can mFilter2 output all options?” but “Can the filter layer discover new options and decide how they should render without manual maintenance?”

What a better setup looks like

• Generate filter definitions from the current option set instead of hard-coding them.
• Use metadata such as descriptions or types to choose the correct template.
• Treat the filter system as a projection of catalog data, not as a hand-curated list.

This is worth keeping because it captures a common scaling problem in product catalogs: the filter UI should adapt to the data model, not force editors to babysit every new attribute forever.

Source: mSearch2 / mFilter2 documentation and miniShop2 on GitHub.