Rule-based property filters: listing filters that maintain themselves

About the Extension

A customer is looking for a dishwasher that ships today. Your shop knows the answer already, it sits in the stock level of every article. The listing still has no filter for it, because Shopware only filters by properties. So the customer clicks through thirty product pages, or buys somewhere else.

The problem

Storefront filters depend on properties. Most of what actually defines a product lives elsewhere: the stock level in the inventory field, technical details in custom fields, the weight in the shipping data. Turning any of that into a filter means assigning the right property to every product by hand. With 20 articles that is an afternoon. With 8,000 articles it is not, and after the next delivery half of them are wrong again.

The solution

You create a rule: one condition, one property group, done. The plugin evaluates that rule every time a product is saved and assigns or removes the matching property on its own. Your listing filters stay correct without anyone maintaining them. What you wrote once as a rule applies to the whole catalogue.

What's in it for you

You maintain rules, not products. A condition such as "stock above zero and not a clearance item" replaces the manual work on every single article. A new product is covered the moment it exists.

Data that cannot be filtered becomes a filter. Stock, price, weight, manufacturer, tax rate and every custom field can be used in a condition. The result is an ordinary Shopware property that shows up in the listing sidebar.

You see the outcome before you save. In the "Test condition" card you pick a product and let the rule run without saving it. True, false or the calculated value appears right away.

No guessing about variables. The "Variables" sidebar shows the real structure of a sample product, searchable, and writes the path you click straight into the active input field. You never have to remember field names.

Your daily routine stays untouched. The plugin writes only the assignments that actually changed, and only inside the property groups it manages itself. Properties you assigned by hand stay where they are. If a rule fails, the failure goes to the log and the product still saves.

Existing products catch up in one go. "Resync all products now" works through the catalogue in the background. If you prefer the console, one command does the same job, optionally as a dry run without writing anything.

How the plugin works

The administration gets its own area with a list of your rules: name, active state, priority, mode, property group and creation date. Every rule runs in one of three modes. "Two values (true/false)" assigns one option for a match and another one for no match, Yes and No for example. "Presence/absence" sets a single option or takes it away again. "Value (calculated)" turns the calculated result itself into the filter option and rounds it commercially, down or up, optionally to a fixed step size.

You write the condition as a Twig template. The property group is either picked from your existing ones or created straight from the rule via "Create new property group", in which case it is filterable immediately and hidden on the product detail page. Priority decides which rule is evaluated first.

Typical use cases

Availability as a filter. "In stock" against "On order", derived from the stock level and the clearance flag. The filter updates with every delivery your ERP books in.

Custom fields made visible. Energy rating, material or certificate sit in a custom field and become a filter option through a rule, without you touching 3,000 articles.

Shipping method up front. Above a certain weight an article gets the property "Pallet delivery", below it "Parcel with Royal Mail". Customers see in the listing what they are getting into.

Price brackets as a filter. The price is rounded to steps of 50 GBP and lands in the listing as a price bracket, with no maintenance at all.

Technical facts for your IT team

Shopware 6.6 and 6.7, PHP 8.2 or newer. The plugin ships exactly one table of its own (swp_conditional_property_rule) and stores the rules there. Shopware's standard tables are neither modified nor extended. Property groups and options are ordinary Shopware records, not a special construct.

Conditions run inside a sandboxed Twig environment with a strict allow-list. Expressions written in the backend cannot reach object methods, cannot cause side effects, and their output length is capped. The evaluator hooks into the product save at low priority, guards itself against re-entrancy and catches every error.

The storefront gets no additional code. No extra queries appear in the listing or the checkout, because the result is stored as a plain property assignment in the database. The full resync runs asynchronously through the message queue, in batches of 100 products by default.

The plugin sends no data to external servers. It processes product data only, no personal data. Logging happens only when you switch it on, and then into a log channel of its own. Backend access is covered by the "Conditional properties" permission with the usual roles.

Uninstalling with the option to keep user data leaves everything in place. Without it, the plugin removes its own table and its settings. Property groups and options it created stay on purpose, because products, orders and filters may depend on them.

To be honest

Conditions are written in Twig syntax. This is no click-together builder, and in our experience the first rule costs you half an hour of learning. The variables sidebar and the test button take the edge off, but if you never want to type anything, this is not your plugin. Assignments also happen when a product is saved or a resync is triggered, not at the moment you create the rule. And if five filters that never change are enough for your catalogue, you do not need this.

Legal notice

We accept no liability for legal requirements. Please check the use of this plugin with a qualified legal advisor.