W piątek, 2 października 2026, Shoper opublikował komunikat Aktualizacja oprogramowania sklepu 5.26.55 i 5.26.56. W samym artykule nie ma opisu zmian — są trzy pliki „Zmiany w stylach graficznych”: dwa dla Storefront (5.26.54 → 5.26.55 i 5.26.55 → 5.26.56) i jeden dla RWD (5.26.55 → 5.26.56). Źródło: Shoper Learn — Aktualizacja oprogramowania sklepu 5.26.55 i 5.26.56 (publikacja 2.10.2026).
Przeczytaliśmy te pliki linijka po linijce i przełożyliśmy je na instrukcję dla właściciela sklepu: co się zmieniło, kogo to dotyczy i jak przenieść poprawki do zmodyfikowanego szablonu. Zrzuty pochodzą z artykułu Learn i z dokumentu zmian Shopera — hostujemy je u siebie.
Kogo dotyczy ta aktualizacja
- Szablon bez zmian w plikach (np. darmowy szablon Storefront, ustawiany tylko w edytorze SVE): zmiany przychodzą razem z oprogramowaniem. Twoja rola to krótki test po aktualizacji (lista niżej).
- Szablon z modyfikacjami w plikach (własne moduły, nadpisane pliki .twig/.less w Storefront albo .tpl w RWD): zmodyfikowane pliki nie aktualizują się same. Shoper publikuje pliki RevisionsDiff właśnie po to, żeby te zmiany przenieść ręcznie.
Różnice między RWD i Storefront od strony technicznej opisaliśmy w hubie: Shoper RWD vs Storefront. A dlaczego aktualizacji szablonu nie warto odkładać: dlaczego szablon trzeba aktualizować.
Zmiana 1: kolejność przycisków w banerze zgód
Pliki: @modules/customer_privacy/customer_privacy.twig (Storefront) i scripts/consents_modal.tpl (RWD). Shoper dodał przełącznik funkcji dev_consents_buttons_order. Gdy jest włączony, przyciski na pierwszej warstwie banera układają się w kolejności:
- Dostosuj zgody (Customize consents),
- Tylko niezbędne (Allow only necessary),
- Zezwól na wszystkie (Allow all) — jako przycisk główny.
Gdy przełącznik jest wyłączony, zostaje dotychczasowy układ: „Tylko niezbędne” przed „Dostosuj zgody”. Prefiks dev_ sugeruje, że Shoper włącza to stopniowo — dlatego po aktualizacji po prostu sprawdź swój baner w oknie incognito.
Kontekst prawny. Wytyczne europejskich organów ochrony danych (EROD) i praktyka UODO idą w jedną stronę: odmowa ma być tak samo łatwa jak zgoda, przyciski powinny mieć porównywalną wagę wizualną, a kategorie nie mogą być zaznaczone z góry. Sama kolejność przycisków nie jest przepisem — ale jeśli w zmodyfikowanym szablonie ukryłeś „Tylko niezbędne” albo zrobiłeś z niego szary link, to jest dobry moment, żeby to poprawić. Więcej: RODO i regulamin w sklepie Shoper.
Jak przenieść do zmodyfikowanego pliku: skopiuj cały blok {% if ObjectApi.getFeatureFlag('dev_consents_buttons_order').isEnabled %} … {% else %} … {% endif %} w miejsce dwóch dotychczasowych przycisków. Nie wpisuj tekstów na sztywno — zostaw translate('…'), wtedy tłumaczenia działają w każdej wersji językowej.
Zmiana 2: „Promocja trwa do…” tylko przy produkcie w promocji
Pliki: @modules/product_prices/product_prices.twig, @macros/featured_product_prices.twig i @macros/product_price.twig. Do warunków wyświetlania czasu trwania promocji Shoper dopisał sprawdzenie, czy wariant faktycznie ma promocję (productVariant.hasSpecialOffer, a w makrze product.specialOffer). Wcześniej sam wybór typu („wszystkie promocje” albo „promocje dłuższe niż 30 dni”) mógł uruchomić komunikat także tam, gdzie promocji nie było.
- {% set showSpecialOfferDurationForAllPromotions = moduleConfig.specialOfferDurationType == 'allPromotions' %}
+ {% set showSpecialOfferDurationForAllPromotions = productVariant.hasSpecialOffer and moduleConfig.specialOfferDurationType == 'allPromotions' %}
Przed Black Friday to ważne: przy produktach z wariantami często tylko jeden rozmiar czy kolor jest przeceniony. Komunikat o czasie promocji przy wariancie bez obniżki to informacja nieprawdziwa dla klienta. O prezentacji cen i historii najniższej ceny z 30 dni pisze Shoper w artykule Historia cen produktu — dyrektywa Omnibus. Plan promocji na cały sezon: kalendarz promocji i Black Friday.
Test: ustaw promocję tylko na jeden wariant produktu, włącz w module cen wyświetlanie czasu trwania i przełączaj warianty na karcie produktu. Komunikat ma się pojawiać wyłącznie przy przecenionym wariancie — także w module produktu wyróżnionego.
Zmiana 3: nowe zmienne wstążki BOGO
W ribbon/ribbon_variables.less pojawiły się dwie zmienne: @bogoRibbonBgColor: @secondaryColor i @bogoRibbonFontColor: @neutralColors0. BOGO to skrót od „buy one, get one” (kup jeden, drugi gratis). W tym komunikacie Shoper nie opisuje nowej funkcji promocji — w plikach są tylko kolory nowego typu wstążki, podpięte pod kolor dodatkowy szablonu.
Co z tym zrobić: jeśli masz własne pliki LESS ze wstążkami, upewnij się, że nie definiujesz zmiennych o tych samych nazwach. Jeśli chcesz, żeby przyszła wstążka miała inny kolor niż kolor dodatkowy — nadpisz te dwie zmienne, zamiast stylować klasę na sztywno.
Zmiana 4 (5.26.55): hasAtLeast() zamiast |length i .count
Największy plik (18 stron) dotyczy wersji 5.26.54 → 5.26.55. To przede wszystkim jedna zmiana powtórzona w kilkudziesięciu modułach i makrach — blog, okruszki, filtry, galeria produktu, kafelki, warianty, koszty dostawy, moduły lojalnościowe, listy produktów. Warunki typu article.tags|length > 0 albo product.images.count > 1 zastąpiono metodą hasAtLeast(n).
- {% if article.categories|length > 0 %}
+ {% if article.categories.hasAtLeast(1) %}
- product.images.count > 1 ? ... : ''
+ product.images.hasAtLeast(2) ? ... : ''
Dokumentacja Object API Storefront wyjaśnia powód: hasAtLeast(minCount) sprawdza, czy lista ma co najmniej tyle elementów, i nie musi liczyć wszystkich — przy dużych listach jest wyraźnie tańsza niż count. Źródło: Shoper Storefront — Object API, metoda hasAtLeast. Twój stary kod nadal działa, ale w modyfikowanych modułach warto przejść na nowy zapis — to drobna optymalizacja szybkości, a przy okazji Twoje pliki nie odjeżdżają od wersji Shopera.
W RWD 5.26.56 doszedł jeszcze w scripts/header.tpl znacznik apple-itunes-app za przełącznikiem przypisanym do konkretnego sklepu z aplikacją mobilną. Dla większości sklepów nic z niego nie wynika.
Procedura krok po kroku dla zmodyfikowanego szablonu
- Zrób listę zmienionych plików. W Storefront sprawdź, które moduły i makra nadpisujesz (edycja plików szablonu albo repozytorium, jeśli pracujesz w Shoper CLI). W RWD — które pliki .tpl są zmodyfikowane.
- Pobierz trzy pliki RevisionsDiff z artykułu Learn i odszukaj w nich swoje pliki. Pozostałe zmiany wejdą same.
- Pracuj na kopii stylu/szablonu, nie na aktywnym szablonie. Najpierw kopia, potem zmiany.
- Przenieś zmiany ręcznie, plik po pliku: blok przycisków zgód, warunki czasu promocji, ewentualnie
hasAtLeast. Nie podmieniaj całych plików wersją Shopera — stracisz własne modyfikacje. - Jeśli korzystasz z Shoper CLI, tryb Watch wysyła zmiany na bieżąco (Shoper CLI: tryb Watch) — przy kilku plikach to oszczędza sporo klikania.
- Przetestuj na kopii: baner zgód w incognito (desktop i telefon), produkt z promocją tylko na jednym wariancie, produkt z jednym zdjęciem (komunikat galerii), lista bloga z kategoriami i tagami, okruszki na telefonie.
- Aktywuj kopię i powtórz szybki test na produkcji.
Checklista po aktualizacji 5.26.55 / 5.26.56
Mniej plików do łatania przy każdej aktualizacji
Każda modyfikacja w pliku szablonu to potencjalna praca przy aktualizacji Shopera. Dlatego aplikacje z rodziny GrowX dokładają funkcje bez ręcznej edycji motywu: GrowCart (pasek darmowej dostawy i dodatki w koszyku, bez zmiany checkoutu), GrowBundle (zestawy), GrowSub (subskrypcje — integracja instaluje się i usuwa razem z aplikacją) czy GrowWish (lista życzeń). Aktualizacja szablonu ich nie rusza.
Jeśli Twój sklep stoi na Modern 3.0 Storefront, przenoszenie poprawek Shopera możesz zostawić nam: Roczne Aktualizacje dla Modern 3.0 albo wariant Aktualizacje PLUS. Własne zmiany w wyglądzie zamówisz w pakietach modyfikacyjnych.
