Przejęcie Magento po agencji: jak zrobić audyt sklepu?

Od czego zacząć przejęcie kodu i dostępów do instancji Magento 2?

Przejęcie sklepu na Magento 2 zaczyna się od odcięcia dostępu starej agencji i zabezpieczenia snapshotu produkcyjnego: bazy danych, plików app/etc/env.php, katalogu pub/media oraz repozytorium Git. Zanim jakikolwiek programista uruchomi lokalne środowisko, Twoim pierwszym krokiem musi być rzetelny audyt techniczny Magento, który wykaże, czy sklep stoi na stabilnym fundamencie, czy na prowizorycznych łatkach wstrzykiwanych bezpośrednio na serwerze produkcyjnym. Bez tej wiedzy podpisujesz umowę SLA na tykającą bombę zegarową.

Przekazanie projektu rzadko przebiega w atmosferze serdeczności. Zazwyczaj poprzedni wykonawca oddaje kod z opóźnieniem, dokumentacja nie istnieje, a wdrożona wersja Magento 2.4.6 lub 2.4.7 okazuje się zlepkiem niespójnych modułów instalowanych ręcznie z pominięciem Composera. Aby nie tracić czasu, proces przejęcia dzielimy na trzy natychmiastowe kroki administracyjne:

1. Rewizja uprawnień i kluczy: Zmiana haseł do bazy MySQL/MariaDB, paneli Cloudflare, kont SSH/SFTP, Redis, OpenSearch oraz rotacja kluczy publicznych i prywatnych do repozytorium GitHub/GitLab.
2. Weryfikacja repozytorium vs serwer produkcyjny: Porównanie sum kontrolnych (md5/diff) plików z repozytorium z zawartością katalogu app/code oraz vendor na serwerze produkcyjnym. Standardem w porzuconych projektach są modyfikacje robione w locie przez SSH bez commita w Git.
3. Zabezpieczenie logów błędów: Pobranie ostatnich 30 dni z var/log/exception.log, var/log/system.log oraz logów serwera Nginx/Apache. Liczba wpisów przekraczająca kilkaset megabajtów dziennie to pierwszy sygnał krytycznych problemów z pluginami.

Co kryje się w repozytorium: jak sprawdzić jakość kodu i nadpisania core?

Wielu właścicieli sklepów e-commerce sądzi, że jeśli front-end działa i koszyk przyjmuje zamówienia, kod jest w porządku. W Magento 2 rzeczywistość weryfikuje polecenie bin/magento setup:di:compile. Jeśli kompilacja wstrzykiwania zależności (Dependency Injection) rzuca błędami składniowymi lub konfliktami interfejsów, oznacza to, że sklep utrzymywał się wyłącznie na wygenerowanych wcześniej plikach w generated/code, a jakakolwiek aktualizacja wyłoży całą platformę.

Drugi grzech główny to modyfikacja plików bazowych Magento (tzw. core hacks) w katalogu vendor/magento lub bezmyślne nadpisywanie klas przez <preference> zamiast użycia pluginów (around, before, after) czy observerów. Jeśli poprzedni programista użył <preference> dla klasy Magento\Catalog\Model\Product, zablokował możliwość bezkonfliktowej instalacji jakiegokolwiek zewnętrznego modułu zarządzania asortymentem.

W SISL audyt kodu zaczynamy od automatycznej i manualnej inspekcji:

• Statyczna analiza kodu: Uruchomienie PHPStan na poziomie 6 lub wyższym oraz PHP Code Sniffer z regułami Magento MEQP (Magento Extension Quality Program).
• Analiza katalogu app/code: Sprawdzenie, ile modułów zostało napisanych na zamówienie, a ile to pirackie lub ręcznie wrzucone komercyjne wtyczki od dostawców takich jak Amasty, Mirasvit czy MageWorx, które powinny być zarządzane przez prywatne repozytorium Composer.
• Zgodność z Hyvä Themes lub Luma: Jeśli sklep korzysta z Hyvä Themes, sprawdzamy, czy wszystkie moduły firm trzecich posiadają dedykowane moduły kompatybilności (np. hyva-themes/magento2-amasty-shipping-table-rates), czy ktoś wstrzyknął biblioteki RequireJS i Knockout.js do czystego stosu opartego na Alpine.js i Tailwind CSS.

Skrajny przypadek z naszej praktyki: sklep generujący 40 tys. zamówień miesięcznie miał wyłączony mechanizm walidacji formularza zamówienia w checkout, ponieważ poprzednia agencja nie potrafiła rozwiązać konfliktu między modułem One Step Checkout a niestandardową bramką płatności. Rezultat? Błędy zapisu zamówień w bazie danych i brakujące numery transakcji w 3% koszyków.

Dlaczego polskie integracje (Comarch, Subiekt, InPost, P24) psują się najczęściej po przejęciu?

Magento 2 na polskim rynku nie istnieje w próżni. W przeciwieństwie do rynków zachodnich, gdzie dominuje Shopify Plus spięty z prostym Stripe i ShipBobem, w Polsce sklep musi radzić sobie ze skomplikowaną architekturą: systemami ERP (Comarch ERP Optima, InsERT Subiekt GT/nexo), automatyzacją wysyłek (InPost ShipX API, Baselinker) oraz rygorystycznymi wymogami fiskalnymi.

Podczas audytu integracji weryfikujemy następujące punkty zapalne:

• Synchronizacja z ERP (Comarch / Subiekt): Czy integracja działa asynchronicznie przez Magento Message Queue (RabbitMQ / DB Queue), czy synchronicznie blokuje proces zamówienia? Widzieliśmy sklepy, w których klient po kliknięciu „Kupuję i płacę” czekał 18 sekund, ponieważ Magento w czasie rzeczywistym odpytywało serwer ERP w siedzibie klienta przez niestabilne łącze o stany magazynowe i rezerwację towaru.
• Płatności i BLIK (Przelewy24 / PayU): Poprawność konfiguracji webhooków powiadomień o statusie transakcji. Źle skonfigurowany Varnish potrafi zbuforować odpowiedź dla bramki płatności, przez co zamówienia opłacone przez BLIK wiszą w statusie Pending Payment aż do momentu ręcznego anulowania przez crona.
• Paczkomaty i integracja z InPost: Weryfikacja zapisu punktu odbioru w tabelach quote i sales_order. Częstym błędem jest zapisywanie ID Paczkomatu w polach street lub polach niestandardowych (extension attributes) bez walidacji formatu, co przy eksporcie do API ShipX generuje błędy i blokuje masowe drukowanie etykiet.
• Zgodność z KSeF, JPK i Białą Listą VAT: Sprawdzenie, jak moduły fakturowania obsługują numery NIP, podział na osoby prywatne i firmy oraz czy moduł generujący dokumenty sprzedaży pobiera aktualne statusy podatników z API Ministerstwa Finansów przed wystawieniem faktury zaliczkowej.

Jak ocenić infrastrukturę serwerową: OpenSearch, Redis, Varnish i PHP 8.3?

Zoptymalizowany kod na kiepskim serwerze będzie działał wolno. Źle skonfigurowany serwer z doskonałym kodem wygeneruje koszty rzędu tysięcy złotych za przewymiarowane instancje AWS lub Hetzner. W audycie infrastruktury nie oceniamy „czy strona się otwiera”, lecz jak zachowuje się pod obciążeniem 500 jednoczesnych użytkowników.

Kluczowe komponenty stosu technologicznego Magento 2.4.x:

1. Wersja PHP i parametry: Magento 2.4.7 wymaga PHP 8.2 lub 8.3. Sprawdzamy ustawienia opcache.memory_consumption (minimum 512MB dla Magento), memory_limit (minimum 2G dla procesów CLI/cron i 756M dla php-fpm) oraz konfigurację max_execution_time.
2. Varnish Cache i Full Page Cache (FPC): Sprawdzamy w nagłówkach HTTP wskaźnik X-Magento-Cache-Debug: HIT. Jeśli każda podstrona zwraca MISS, Varnish jest jedynie atrapą, a każda odsłona uderza bezpośrednio w PHP i bazę danych. Zazwyczaj winny jest niespójny blok w pliku default.xml z atrybutem cacheable="false", który unieważnia pamięć podręczną dla całego widoku.
3. OpenSearch / Elasticsearch: Magento 2.4 od wersji 2.4.4 nie posiada wbudowanego silnika wyszukiwania bazodanowego — wymaga zewnętrznej usługi OpenSearch (2.x) lub Elasticsearch (7.x/8.x). Weryfikujemy alokację pamięci heap (nie więcej niż 50% RAM instancji) oraz poprawność indeksacji atrybutów wyszukiwalnych.
4. Redis: podział instancji: Poważny błąd konfiguracyjny to używanie jednej instancji Redisa dla sesji (session) i pamięci podręcznej (cache). W przypadku zapełnienia pamięci podręcznej Redis usuwa losowe klucze (LRU eviction), co w skrajnych wypadkach wylogowuje klientów w trakcie finalizacji zakupu. Prawidłowa konfiguracja w app/etc/env.php rozdziela te usługi na dwa niezależne porty lub sockety.

Ile kosztuje audyt przejęcia i co musi zawierać raport końcowy?

Profesjonalny audyt techniczny Magento przed przejęciem sklepu to wydatek rzędu 4 500 PLN do 12 000 PLN netto, w zależności od liczby zainstalowanych modułów, stopnia skomplikowania integracji ERP i rozmiaru bazy danych. Czas realizacji wynosi zazwyczaj od 5 do 10 dni roboczych. Zlecenie audytu za 1 000 PLN kończy się najczęściej wygenerowaniem automatycznego raportu z darmowego narzędzia, który dla e-commerce managera ma zerową wartość decyzyjną.

U nas w projektach zamykamy audyt dokumentem, który dzieli wykryte problemy na trzy kategorie:

• Blokery (Critical): Podatności bezpieczeństwa (np. brakujące patche CVE), niespójność bazy danych uniemożliwiająca aktualizację do nowszych wersji Magento, błędy w obsłudze płatności i zamówień.
• Dług technologiczny (Major): Przestarzałe moduły bez wsparcia, brak testów, niepoprawna struktura szablonu zaniżająca wyniki Google PageSpeed / Core Web Vitals poniżej 40 punktów, brak separacji środowisk dev/stage/prod.
• Optymalizacje (Minor): Drobne poprawki w konfiguracji crona, optymalizacja zapytań SQL w raportach, czyszczenie starych tabel logów (np. customer_visitor, report_event).

Z takim dokumentem zyskujesz twardą podstawę do renegocjacji warunków ze starym wykonawcą, wyceny rzeczywistych kosztów utrzymania (SLA) lub podjęcia decyzji o refaktoryzacji kodu. Jeśli stoisz przed wyzwaniem przejęcia sklepu na Magento 2 i chcesz wiedzieć, na czym faktycznie stoisz — napisz do nas, a przeanalizujemy Twoje repozytorium i infrastrukturę.