Czy moduł Magento działa z Hyvä? Jak to sprawdzić

Szybka odpowiedź: 3 kroki do weryfikacji modułu w 5 minut

Sprawdzenie kompatybilności modułu z Hyvä przed sfinalizowaniem zakupu polega na weryfikacji oficjalnego Hyvä Compatibility Tracker na GitLabie, przeszukaniu repozytorium vendora pod kątem dedykowanej paczki hyva-themes/magento2-compat-... oraz ocenie, czy moduł ingeruje w warstwę prezentacji (frontend), czy wykonuje operacje wyłącznie po stronie backendu. Jeśli wdrażasz nowoczesny frontend, jakim jest Hyva Theme dla Magento, zakup wtyczki bez zweryfikowanego wsparcia oznacza, że po wydaniu 150–300 EUR na licencję wydasz kolejne 2 000–6 000 PLN netto na przepisanie szablonów z Knockout.js na Alpine.js i Tailwind CSS.

Poniższa ścieżka pozwala bezbłędnie ocenić stan modułu jeszcze przed podaniem danych karty płatniczej:

1. Zweryfikuj Hyvä Compatibility Tracker – publiczny rejestr na GitLabie prowadzony przez core team Hyvä oraz społeczność developerów.
2. Sprawdź dokumentację i changelog vendora – producenci tacy jak Amasty, Mirasvit, MageWorx czy Mageplaza oznaczają kompatybilność w sekcji wymagań technicznych modułu.
3. Zidentyfikuj architekturę modułu – moduły stricte backendowe (np. integracje z Comarch ERP Optima, Subiekt GT/nexo, KSeF, JPK) nie wymagają adapterów frontendowych i działają natywnie.

Dlaczego moduł z klasycznego Magento 2 nie zadziała na Hyvä od razu?

Domyślny frontend Magento 2 (motywy Luma i Blank) opiera się na przestarzałym stosie technologicznym: RequireJS, Knockout.js, jQuery, widgetach jQuery UI oraz setkach zagnieżdżonych plików XML tworzących tzw. UI Components. Hyvä całkowicie wycina ten narzut. Zamiast 200 zapytań HTTP o pliki JS i 1,5 MB kodu blokującego renderowanie, otrzymujesz czysty HTML ostylowany przez Tailwind CSS oraz reaktywność opartą na lekkim Alpine.js v3.

Gdy instalujesz moduł przygotowany pod Lumę na sklepie z aktywnym motywem Hyvä, silnik Magento poprawnie zaczyta backend (modele, repozytoria, tabele w bazie danych, pluginy DI), ale silnik renderujący Hyvä zignoruje pliki zdefiniowane w przestarzały sposób. Efekt w konsoli przeglądarki jest natychmiastowy:

Uncaught ReferenceError: jQuery is not defined
Uncaught ReferenceError: ko is not defined
Uncaught TypeError: mage/apply/main is not a function

W rezultacie formularz dodawania do koszyka nie reaguje, popup z newsletterem nie istnieje w DOM, a zaawansowany widget wyboru Paczkomatu InPost po prostu się nie wyświetla.

Jak korzystać z Hyvä Compatibility Tracker?

Oficjalny Compatibility Tracker to baza ponad 600 modułów firm trzecich, których szablony zostały przepisane na Alpine.js i Tailwind CSS. Dostęp do gotowych modułów kompatybilności wymaga aktywnej licencji Hyvä (kosztującej jednorazowo 1 000 EUR dla sklepu), która daje dostęp do prywatnego GitLaba gitlab.hyva.io oraz rejestru Packagist.

W rejestrze każdy moduł ma przypisany jeden z czterech statusów:

• Supported / Official – paczka kompatybilności jest w pełni przetestowana, utrzymywana przez Hyvä Themes lub bezpośrednio przez vendora (np. Mirasvit, Amasty). Instalacja sprowadza się do jednej komendy: composer require hyva-themes/magento2-vendor-module-compat.
• In Progress – kod adaptera powstaje w publicznym branchu; możesz go przetestować na środowisku deweloperskim, ale może zawierać nieobsłużone edge-case'y.
• Community Maintained – moduł stworzony przez agencję zewnętrzną. Kod działa, ale aktualizacje zależą od zaangażowania autora repozytorium.
• Not compatible / No compatibility module – brak dedykowanego kodu. Moduł wymaga ręcznego wdrożenia frontendowego od zera.

Polskie realia e-commerce: InPost, Przelewy24, KSeF, Allegro i ERP

U nas w projektach kwestia kompatybilności rzadko rozbija się o generyczne slidery banerów – te przepisuje się w 2 godziny. Prawdziwym wyzwaniem są specyficzne dla polskiego rynku integracje logistyczne, płatnicze i fiskalne.

1. Bramki płatności (Przelewy24, PayU, Autopay, BLIK)

Oficjalny moduł Przelewy24 dla Magento 2 posiada gotową i stabilną kompatybilność z Hyvä Theme oraz Hyvä Checkout. Obsługa BLIK 0 (bezpośrednie wpisanie 6-cyfrowego kodu w koszyku) została przepisana na Alpine.js. W przypadku PayU i Autopay integracje przekierowujące na zewnętrzną formatkę płatności działają bez żadnych modyfikacji frontendowych, ponieważ cały proces autoryzacji transakcji odbywa się poza warstwą szablonu sklepu.

2. Dostawa i Paczkomaty (InPost, DPD Pickup, Orlen Paczka)

Standardowy moduł InPost korzysta z biblioteki Geowidget opartej na jQuery. Aby mapa punktów odbioru otworzyła się w koszyku Hyvä, niezbędne jest zastosowanie paczki hyva-themes/magento2-inpost-compat lub dedykowanego adaptera. W SISL unikamy osadzania ciężkich bibliotek JS z Lumy wewnątrz Hyvä – Geowidget InPost uruchamiamy asynchronicznie poprzez natywny event w Alpine.js dopiero w momencie wyboru metody dostawy przez klienta.

3. Integracje ERP i finanse (Subiekt GT/nexo, Comarch ERP Optima, KSeF, JPK, biała lista VAT)

Moduły synchronizujące stany magazynowe, pobierające zamówienia do systemów Comarch ERP Optima czy Subiekt nexo, a także wtyczki do automatycznego fakturowania i wysyłki faktur do KSeF (Krajowego Systemu e-Faktur) są w 100% modułami backendowymi. Nie dotykają one warstwy view/frontend. Działają w procesach CLI, kolejkach RabbitMQ lub przez REST/GraphQL API. Dla nich zmiana motywu na Hyvä jest całkowicie przezroczysta – przechodzą bin/magento setup:di:compile bez żadnych konfliktów na Magento 2.4.7 i PHP 8.3.

Vendorzy modułów: kto wspiera Hyvä, a kto każe płacić ekstra?

Podejście producentów modułów do ekosystemu Hyvä jest zróżnicowane. Zanim kupisz rozszerzenie, sprawdź model dystrybucji kompatybilności:

Wskazówka: Zawsze upewnij się, że kupowana wersja modułu wspiera aktualny stack technologiczny: Magento 2.4.7, PHP 8.3 oraz OpenSearch 2.x. Moduł kompatybilny z Hyvä, ale niekompatybilny z PHP 8.3 unieruchomi proces kompilacji całego sklepu.

Checklist: Jak technicznie prześwietlić kod modułu przed wdrożeniem produkcyjnym?

Jeśli kupujesz moduł od mniejszego vendora lub zlecasz audyt kodu przed instalacją w środowisku stagingowym, wykonaj poniższą procedurę weryfikacyjną:

1. Przeszukaj katalog view/frontend/web – jeśli znajdziesz tam pliki requirejs-config.js, widgety jQuery czy szablony .html dla Knockout.js (np. web/template/...), wiesz, że moduł w obecnej formie nie zadziała w warstwie wizualnej Hyvä.
2. Przejrzyj layout XML w view/frontend/layout/ – obecność węzłów <uiComponent name="..."/> oznacza twardą zależność od stosu Lumy. Hyvä opiera się na standardowych blokach Magento\Framework\View\Element\Template.
3. Sprawdź pliki .phtml – kompatybilny szablon zawiera klasy narzędziowe Tailwind CSS (np. class="flex items-center gap-4 bg-white p-6 shadow-sm") oraz dyrektywy Alpine (np. x-data="initModule()", x-on:click="...", x-show="open").
4. Przetestuj proces budowania aplikacji – po instalacji paczki wykonaj sekwencję:

   bin/magento module:enable Vendor_ModuleName
   bin/magento setup:upgrade
   bin/magento setup:di:compile
   bin/magento cache:flush

   Brak błędów w kompilacji DI potwierdza poprawność backendu; brak błędów w konsoli przeglądarki potwierdza poprawność frontendu.

Ile kosztuje dostosowanie modułu, jeśli brak gotowej kompatybilności?

Brak gotowej paczki na GitLabie Hyvä nie oznacza, że musisz rezygnować z wybranego rozwiązania biznesowego. Oznacza to jedynie konieczność stworzenia adaptera frontendowego.

• Prosty moduł frontendowy (4–8 roboczogodzin | 1 000–2 200 PLN netto): Moduły typu informacja o darmowej dostawie, niestandardowy kalkulator rat, prosty popup marketingowy czy dodatkowa zakładka na karcie produktu. Praca polega na stworzeniu nowego pliku .phtml i oprogramowaniu logiki w Alpine.js.
• Średnio skomplikowany moduł (12–24 roboczogodziny | 3 000–6 500 PLN netto): Filtry produktów w katalogu (Layered Navigation), niestandardowa galeria zdjęć z obsługą wideo i zoomu, konfigurator prostych atrybutów.
• Zaawansowany moduł transactionalny (30–60+ roboczogodzin | 8 000–16 000+ PLN netto): Niestandardowy One Step Checkout, zaawansowane konfiguratory mebli/odzieży oparte na drzewach decyzyjnych, moduły aukcyjne lub rozbudowane programy lojalnościowe z dynamicznym przeliczaniem punktów w koszyku.

Często zamiast przepisywać stary, ociężały moduł sprzed pięciu lat, znacznie taniej i bezpieczniej jest wybrać nowoczesną alternatywę posiadającą oficjalne repozytorium na GitLabie Hyvä. Jeśli planujesz migrację swojego sklepu lub weryfikujesz listę rozszerzeń przed wdrożeniem, napisz do nas – przeanalizujemy Twój plik composer.json pod kątem zgodności z Hyvä Theme i wyeliminujemy ryzyko kosztownych niespodzianek na etapie produkcji.