Resolution order

A breakdown of what happens when a storefront page renders content that uses Dynamic Variables.

The pipeline

1. Find placeholders. The plugin scans the rendered content for {key} patterns. Anything between { and } that matches the key format is a candidate.
2. Look up the variable. Each candidate key is looked up against the variable list. Built-ins are checked first, then custom variables.
3. Active check. Inactive variables are skipped — the placeholder is left as-is.
4. Scope check. The variable’s allowed scopes must include the current scope (CMS / Product / Category), or the variable’s scope list must be empty (= any).
5. Channel selection. Among the variable’s value rows, the row matching the current sales channel is picked. If none, the global row (no channel) is used. If neither exists, the placeholder is left as-is.
6. Language selection. Within the chosen row, the translation matching the current storefront language is picked. If empty, the system default language is used.
7. Nested resolution. If the value contains {otherKey} references, those are resolved one level deep (see Nested variables).
8. Replace. The resolved string replaces the placeholder in the rendered output.
9. Track used variables. The plugin records which variables actually appeared on the page so it can inject only their CSS / JS.
10. Inject assets. The CSS rows for used variables are concatenated into a <style> block. The Script rows go into a <script> block.

Caching

• Variable definitions are cached per request, keyed by sales channel + scope.
• The first content scan on a request loads the data once; every other scan in the same request reuses it.
• Across requests, Shopware’s standard HTTP / object cache kicks in. After changing a value in the admin, clear the cache.

Unknown keys

The plugin does not strip unknown placeholders. If you type {tpyo}, the storefront renders {tpyo} literally. This is intentional — it makes typos visible during QA rather than silently swallowing content.

If you want stricter behaviour (e.g. strip unknown placeholders), you can extend the plugin’s replacer service — it is registered with the standard Shopware DI container and follows normal decoration rules.

Order of operations vs other plugins

The Dynamic Variables replacer runs after Shopware’s standard CMS rendering. That means:

• It sees the final HTML output of CMS elements, including any content produced by other plugins.
• If another plugin also rewrites the same fields after Dynamic Variables, its changes can re-introduce raw {...} placeholders that the Dynamic Variables replacer no longer sees. In practice this is rare — but if you write your own subscriber on the same events, register it with a priority that lets you choose where you sit in the chain.