Kolejność rozwiązywania

Rozkład tego, co się dzieje, gdy strona storefrontu renderuje treść używającą Dynamic Variables.

Pipeline

1. Znajdź placeholdery. Plugin skanuje wyrenderowaną treść w poszukiwaniu wzorca {key}. Wszystko między { a }, co pasuje do formatu klucza, jest kandydatem.
2. Wyszukaj zmienną. Każdy klucz-kandydat jest sprawdzany na liście zmiennych. Najpierw wbudowane, potem własne.
3. Sprawdzenie aktywności. Nieaktywne zmienne są pomijane — placeholder pozostaje niezmieniony.
4. Sprawdzenie zakresu. Dozwolone zakresy zmiennej muszą zawierać bieżący zakres (CMS / Produkt / Kategoria) — albo lista zakresów zmiennej musi być pusta (= dowolny).
5. Wybór kanału. Spośród wierszy wartości zmiennej wybierany jest wiersz pasujący do bieżącego kanału sprzedaży. Jeśli nie ma — wiersz globalny (bez kanału). Jeśli i tego nie ma, placeholder pozostaje niezmieniony.
6. Wybór języka. W ramach wybranego wiersza wybierane jest tłumaczenie pasujące do bieżącego języka storefrontu. Jeśli puste, używany jest język domyślny systemu.
7. Rozwiązanie zagnieżdżonych. Jeśli wartość zawiera referencje {otherKey}, są one rozwiązywane jeden poziom w głąb (patrz Zmienne zagnieżdżone).
8. Zastąp. Rozwiązany ciąg zastępuje placeholder w wyrenderowanym wyjściu.
9. Zapamiętaj użyte zmienne. Plugin zapamiętuje, które zmienne faktycznie pojawiły się na stronie, aby wstrzyknąć tylko ich CSS / JS.
10. Wstrzyknij assety. Wiersze CSS użytych zmiennych są łączone w blok <style>. Wiersze Skrypt trafiają do bloku <script>.

Cache’owanie

• Definicje zmiennych są cache’owane per request, z kluczem kanał sprzedaży + zakres.
• Pierwsze skanowanie treści w requeście ładuje dane raz; każde kolejne skanowanie w tym samym requeście korzysta z nich ponownie.
• Między requestami działa standardowy cache HTTP / object Shopware. Po zmianie wartości w adminie wyczyść cache.

Nieznane klucze

Plugin nie usuwa nieznanych placeholderów. Jeśli wpiszesz {tpyo}, storefront wyrenderuje dosłownie {tpyo}. To celowe — literówki są widoczne podczas QA, zamiast po cichu zjadać treść.

Jeśli chcesz surowszego zachowania (np. usuwanie nieznanych placeholderów), możesz rozszerzyć serwis replacer pluginu — jest zarejestrowany w standardowym kontenerze DI Symfony i podlega zwykłym regułom dekorowania.

Kolejność wobec innych pluginów

Replacer Dynamic Variables działa po standardowym renderowaniu CMS Shopware. To znaczy:

• Widzi finalne wyjście HTML elementów CMS, włącznie z treścią produkowaną przez inne pluginy.
• Jeśli inny plugin też przepisuje te same pola po Dynamic Variables, może wprowadzić ponownie surowe {...}, których replacer Dynamic Variables już nie widzi. W praktyce to rzadkie — ale jeśli piszesz własny subscriber na tych samych zdarzeniach, zarejestruj go z priorytetem dającym Ci wybór miejsca w łańcuchu.