Dlaczego sklep Magento nie działa poprawnie w Polsce? Lista przyczyn i diagnostyka

Komunikat "Magento nie działa" może opisywać kilka różnych awarii, dlatego pierwszym krokiem jest zapisanie objawu i miejsca jego wystąpienia. Niedostępność całej witryny, brak zamówienia po płatności, pusta lista dostaw i błędna cena wymagają innych kontroli.

Przy zgłoszeniu warto rozróżnić błąd widoczny dla każdego użytkownika od problemu zależnego od sesji. Jeśli działa zalogowany administrator, ale klient widzi pusty checkout, zapisz to jako osobny warunek reprodukcji. Zbierz też informację, czy problem występuje w jednym widoku sklepu, na wszystkich urządzeniach i przy każdej metodzie płatności.

Nie zakładaj od razu, że polski rynek jest nieobsługiwany. Adobe Commerce i Magento Open Source mają ustawienia widoków sklepu, lokalizacji, walut i metod dostawy, które trzeba dopasować do konfiguracji wdrożenia. Sama dostępność opcji w platformie nie oznacza jednak, że konkretna bramka płatności, przewoźnik lub moduł został poprawnie skonfigurowany.

Zapisz czas lokalny wraz ze strefą, adres strony, identyfikator koszyka lub zamówienia oraz dokładny krok, po którym wystąpił błąd. Przy problemach przejściowych ta informacja pomaga skorelować zdarzenie z logiem aplikacji, serwera i operatora. Nie umieszczaj w publicznym zgłoszeniu danych kart płatniczych, haseł ani pełnych danych osobowych klienta.

Sam objaw nie wskazuje jeszcze komponentu, który go wywołał. Zestawiamy czas awarii z wdrożeniami, aktualizacjami modułów, zmianami konfiguracji i zdarzeniami po stronie usług zewnętrznych.

W instalacji Adobe Commerce logi aplikacji znajdują się zwykle w katalogu `var/log`, między innymi jako `system.log` i `exception.log`. W Adobe Commerce on cloud infrastruktura udostępnia również logi środowiska w `/var/log`; sposób ich odczytu zależy od środowiska i uprawnień. Logi należy analizować w przedziale obejmującym błąd, nie tylko na podstawie ostatniego wpisu.

Przed diagnozą zapisz ostatnią znaną dobrą godzinę działania i zmiany wykonane od tego momentu. Do zmian zaliczamy aktualizację Magento, modułu, PHP, konfiguracji serwera, certyfikatu, klucza API, reguł dostawy i importu katalogu. Jeśli kilka zmian wydarzyło się jednocześnie, odtwarzamy je w środowisku testowym pojedynczo, o ile dostępne są kopia danych i procedura wdrożenia.

Nie edytujemy produkcyjnych plików ani ustawień na ślepo. Najpierw ustalamy wersję platformy, tryb wdrożenia i zakres sklepu, którego dotyczy zmiana. Przy środowisku Adobe Commerce on cloud część ustawień jest zarządzana przez pliki konfiguracyjne i narzędzia wdrożeniowe, a ręczna zmiana może zostać nadpisana przy kolejnym wdrożeniu.

Jeżeli problem może wynikać z rozszerzenia, najbezpieczniej porównać działanie na kopii środowiska po odtworzeniu błędu. Wyłączenie modułu na produkcji może ukryć objaw, ale jednocześnie zatrzymać płatność, wysyłkę, fakturowanie albo proces magazynowy. Szczególnie ostrożnie traktujemy komponenty, które zapisują transakcje lub obsługują powiadomienia zwrotne.

Test zamówienia odtwarza drogę klienta od koszyka do potwierdzenia i pozwala ustalić, na którym etapie rozchodzą się dane sklepu oraz operatora. Testujemy na środowisku sandbox, jeżeli operator je udostępnia, i używamy danych testowych zgodnych z jego dokumentacją.

1. Zapisz produkt testowy, jego cenę, ilość, adres dostawy i wybraną metodę.
2. Przejdź checkout i zanotuj, czy zamówienie pojawia się w panelu przed przekierowaniem do bramki.
3. Wykonaj płatność testową i sprawdź ekran powrotu do sklepu.
4. Porównaj status transakcji u operatora ze stanem i statusem zamówienia w Magento.
5. Sprawdź fakturę, komentarze w historii zamówienia i wiadomość e-mail, jeśli sklep ma ją wysyłać.
6. Przetestuj anulowanie lub zwrot w trybie testowym i sprawdź, czy sklep oraz operator pokazują zgodny wynik.

W panelu Magento zamówienia znajdziesz w ścieżce `Sales > Operations > Orders`. Otwórz zamówienie i porównaj jego stan, status, metodę płatności, sumy oraz historię komentarzy. Adobe rozróżnia stan zamówienia, który steruje przebiegiem procesu, od statusu używanego do informowania administratora i klienta. Dlatego sam widoczny status nie zawsze wyjaśnia, czy płatność została zaksięgowana.

Jeśli klient wrócił z bramki, ale zamówienie nadal ma `Pending Payment`, sprawdź, czy operator wysłał potwierdzenie do sklepu i czy endpoint callbacku był osiągalny. Jeżeli operator widzi transakcję jako opłaconą, a Magento nie zmieniło stanu, zbierz identyfikator transakcji, czas, metodę płatności i wpisy z logów rozszerzenia. Nie wykonuj ponownego obciążenia karty tylko po to, by powtórzyć test.

Jeśli zamówienia nie ma w panelu, mimo że operator potwierdza obciążenie, sprawdź logi checkoutu i modułu bramki z dokładnego czasu transakcji. Możliwy jest błąd przed zapisaniem zamówienia, nieudane powiadomienie zwrotne albo odrzucenie żądania przez serwer. Zanim skorygujesz dane ręcznie, uzgodnij z operatorem, czy transakcja jest autoryzowana, pobrana, anulowana czy tylko oczekująca.

Adobe zaleca sprawdzanie pełnego cyklu płatności w środowisku testowym przed udostępnieniem metody klientom. Test powinien obejmować nie tylko udany checkout, ale także operacje zależne od konfiguracji, takie jak autoryzacja, pobranie środków, anulowanie i zwrot. Dokładny zakres zależy od operatora oraz ustawionego trybu działania.

Brak metody dostawy często wynika z danych koszyka albo reguły, a nie z awarii całego Magento. Porównaj adres, wagę, wartość produktów, źródło wysyłki i odpowiedź integracji dla tego samego koszyka.

Zacznij od jednego testowego koszyka i zmieniaj tylko jeden parametr. Porównaj adres, wagę, produkt i wartość z koszykiem, dla którego metoda dostawy jest widoczna. Jeżeli zmiana samego kodu pocztowego przywraca metodę, sprawdź reguły obszaru obsługi i walidację adresu u przewoźnika.

Magento konfiguruje punkt pochodzenia przesyłek w `Stores > Settings > Configuration > Sales > Shipping Settings > Origin`. Adobe wskazuje, że punkt pochodzenia służy do kalkulacji kosztu wysyłki, a także wpływa na określenie stawki podatkowej w odpowiednich konfiguracjach. Po zmianie ustawień testuj koszyk z różnymi adresami, bo ta sama reguła może działać inaczej zależnie od kraju i zakresu witryny.

Przy ERP i magazynie sprawdź, czy eksport obejmuje właściwy stan zamówienia. Niektóre procesy wysyłają rekord dopiero po opłaceniu, inne po utworzeniu zamówienia. Ustal, czy kolejka wiadomości przetworzyła zdarzenie, czy system docelowy zwrócił błąd i czy mechanizm ponawiania nie utworzył duplikatu.

Zadania cron obsługują w Magento między innymi indeksowanie, aktualizację kursów oraz wysyłkę wiadomości. Adobe dokumentuje log cron w `var/log/cron.log`, a historię zaplanowanych zadań w tabeli `cron_schedule`. Jeżeli potwierdzenia e-maili, importy lub aktualizacje indeksów przestają działać w określonych odstępach, sprawdź stan tych zadań wraz z logami integracji.

Zgłoszenie do dostawcy integracji powinno zawierać identyfikator zamówienia testowego, czas zdarzenia, nazwę operacji i kod odpowiedzi, jeśli jest dostępny. Nie wysyłaj sekretów API ani pełnych danych klienta. W razie potrzeby przygotuj zanonimizowany przykład, który zachowuje te same pola techniczne.

Ustawienia lokalizacji trzeba sprawdzić w każdym widoku sklepu, który sprzedaje na polskim rynku. Różne zakresy konfiguracji mogą powodować, że sklep pokazuje poprawną walutę na stronie produktu, ale używa innego ustawienia w checkout lub e-mailu transakcyjnym.

W panelu wybierz `Stores > Settings > Configuration`, a następnie sprawdź zakres konfiguracji widoczny w górnej części ekranu. W sekcji `General > General > Locale Options` zweryfikuj język, strefę czasową, jednostkę wagi i początek tygodnia. Dokumentacja Adobe opisuje ustawienia lokalizacji jako konfigurację wpływającą między innymi na język, format liczb i strefę czasową sklepu.

Walutę sprawdzisz w `General > Currency Setup`. Porównaj `Base Currency`, `Default Display Currency` i `Allowed Currencies` dla właściwego zakresu. Pierwsza z nich dotyczy podstawowej waluty transakcji, druga waluty wyświetlanej, a trzecia walut akceptowanych przez sklep. Jeżeli kwota jest poprawna na karcie produktu, ale różna po przejściu do płatności, sprawdź też walutę wysyłaną do operatora i ustawienia modułu płatności.

Podatki wymagają kontroli wraz z księgowością, ponieważ konfiguracja musi odpowiadać zasadom sprzedaży firmy. W panelu przejrzyj klasy podatkowe produktów, reguły stawek, sposób prezentacji cen oraz punkt pochodzenia wysyłki. Nie zmieniaj stawek na podstawie samego komunikatu klienta, dopóki nie potwierdzisz, czy problem dotyczy obliczenia, wyświetlania czy danych przekazanych do faktury.

Sprawdź również adresy i pola wymagane w checkout. Reguły walidacji dla kraju mogą oczekiwać kodu pocztowego, województwa lub określonego formatu numeru telefonu. Jeżeli sklep sprzedaje także poza Polskę, testuj co najmniej jeden polski adres i jeden adres z każdego rynku, dla którego konfiguracja ma być aktywna.

Po zmianie lokalizacji wykonaj test zamówienia i sprawdź produkt, koszyk, checkout, e-mail oraz dokument sprzedaży. Dla widoków wielojęzycznych kontroluj także treści transakcyjne i komunikaty walidacji. Ustawienie języka sklepu nie gwarantuje, że rozszerzenie płatnicze lub kurierskie ma przetłumaczone własne etykiety.

Najpierw ustal, czy spowolnienie dotyczy całego sklepu, czy jednej funkcji. Strona główna, karta produktu, koszyk i panel administracyjny mogą korzystać z różnych zapytań i warstw cache, więc porównanie tych punktów zawęża obszar awarii.

Zapisz godzinę testu, adres URL i czas odpowiedzi, a następnie sprawdź, czy pojawiają się błędy 5xx, timeouty lub odpowiedzi 4xx. Jeśli problem dotyczy tylko checkoutu, porównaj go z logiem płatności i dostawy. Jeżeli wolno działa każda strona, poproś administratora hostingu o dane CPU, pamięci, połączeń do bazy i limitów PHP z tego samego okresu.

W logach aplikacji szukaj wyjątków związanych z konkretnym żądaniem. W środowisku Adobe Commerce on cloud dostępne są logi aplikacji i środowiska, a ich rozmieszczenie może zależeć od typu środowiska i węzła. Wdrożenia wielowęzłowe wymagają sprawdzenia każdego węzła, jeśli problem występuje tylko części użytkowników.

Magento używa warstw cache, w tym cache aplikacji i cache pełnych stron. Adobe zaleca Varnish dla instalacji on-premises, natomiast infrastruktura Adobe Commerce on cloud używa Fastly na warstwie brzegowej i cache pełnych stron. Sprawdź, czy test obejmuje cache właściwy dla danego hostingu, ponieważ zmiana cache aplikacji nie konfiguruje automatycznie reverse proxy ani CDN.

Nie czyść wszystkich cache jako domyślnej reakcji na każdy błąd. Usunięcie cache może tymczasowo zwiększyć obciążenie, a ponowne indeksowanie lub generowanie danych może potrwać. Zapisz, jakie typy cache odświeżono, o której godzinie i jaki objaw zmienił się po tej czynności.

Jeżeli problem pojawia się po określonych zadaniach, sprawdź cron i kolejki. Dokumentacja Adobe opisuje zależności funkcji od poprawnie skonfigurowanego cron, w tym indeksowanie i e-maile transakcyjne. Dla podejrzenia kolejki potwierdź, czy wiadomość została opublikowana, odebrana przez konsumenta i zakończona bez błędu.

Decyzję opieramy na zakresie awarii, zależnościach biznesowych i możliwości bezpiecznego testowania zmian. Pojedynczy problem z modułem płatniczym nie uzasadnia migracji całej platformy, ale powtarzające się awarie bez wsparcia i dokumentacji mogą zmieniać rachunek ryzyka.

Koszt naprawy należy porównać z kosztem utrzymania obecnego rozwiązania w kolejnych okresach. W analizie uwzględnij czas niedostępności, ręczne obejścia, liczbę awarii, koszt testów regresji i ryzyko utraty danych. Migracja niesie własne zadania: przeniesienie katalogu, klientów i zamówień, mapowanie adresów, odtworzenie integracji oraz kontrolę widoczności organicznej.

Przed wyborem przygotuj inwentaryzację rozszerzeń. Zapisz, które moduły obsługują płatność, dostawę, faktury, promocje, wyszukiwarkę i synchronizację stanów. Oznacz, czy są utrzymywane przez dostawcę, zmodyfikowane przez zespół czy zastąpione kodem własnym. Taka mapa pokazuje, czy problem dotyczy platformy, czy zależności, które trzeba będzie odtworzyć niezależnie od wyboru nowego systemu.

Przy małej usterce zacznij od odtworzenia problemu na kopii środowiska i naprawy komponentu. Przy wielu powiązanych awariach najpierw odzyskaj powtarzalne wdrożenie, kopię zapasową oraz test zamówienia. Gdy nie ma bezpiecznego sposobu testowania, nawet niewielka zmiana może przerwać sprzedaż.

Wybór między platformami wymaga porównania kosztu obsługi, potrzeb funkcjonalnych i zależności integracyjnych. Wstępne różnice opisujemy w materiale WooCommerce vs Shopify: koszty, obsługa i integracje. Jeśli sklep potrzebuje stałej diagnostyki i aktualizacji po naprawie, opieka nad sklepem internetowym obejmuje usługę utrzymania sklepu.

Dobre zgłoszenie pozwala odtworzyć błąd bez zgadywania, co klient zrobił przed jego wystąpieniem. Zapisz konkretną ścieżkę, czas i identyfikator testowego zamówienia, a dane dostępowe przekaż bezpiecznym kanałem uzgodnionym z zespołem technicznym.

W zgłoszeniu podaj:

• adres strony i nazwę widoku sklepu;
• datę oraz godzinę wraz ze strefą czasową;
• kroki prowadzące do błędu, od wejścia na stronę do komunikatu;
• oczekiwany wynik i to, co wydarzyło się faktycznie;
• identyfikator koszyka, zamówienia testowego lub transakcji;
• metodę płatności i dostawy, bez danych karty;
• informację o urządzeniu, przeglądarce i stanie zalogowania;
• zrzut komunikatu oraz wpis z logu, jeśli masz do niego dostęp;
• ostatnie wdrożenia, aktualizacje lub zmiany konfiguracji.

Podaj, czy błąd jest powtarzalny i czy dotyczy wszystkich klientów. Jeżeli objaw wystąpił raz, zapisz także, czy po odświeżeniu strony zniknął i czy system utworzył zamówienie. W przypadku płatności rozróżnij nieudane przekierowanie od sytuacji, w której operator pobrał środki, ale sklep nie otrzymał potwierdzenia.

Nie wysyłaj publicznie zrzutów z danymi osobowymi, tokenami, kluczami API ani pełnymi adresami klientów. Zanonimizuj przykład, zostawiając pola potrzebne do odtworzenia problemu. Jeżeli zgłoszenie dotyczy konkretnej transakcji, uprawniony administrator może przekazać identyfikator bezpośrednio osobie diagnozującej.

Po naprawie powtórz test, który wcześniej wywoływał problem. Następnie sprawdź powiązane działania: zapis zamówienia, status, fakturę, e-mail, wysyłkę i ewentualny zwrot. Zapisz wersję wdrożonej poprawki, wynik testu oraz czas obserwacji po wdrożeniu, aby kolejne zgłoszenie można było porównać z konkretnym stanem sklepu.

• Obsługa sklepu Magento: co obejmuje stała opieka techniczna
• Dlaczego budowa sklepu na Shopify nie działa i jak znaleźć przyczynę
• Magento 1 w firmie: jak ocenić ryzyko i zaplanować dalsze działanie
• Wtyczki do Magento: jak dobrać rozszerzenie do potrzeb sklepu?