18 spraw, opisanych tak, jak są zapisane

Sytuacja

Ruch obsługiwany przez moduł płatności InPost Pay przeciążył serwer w szczycie sprzedażowym. Sklep nie działał od godziny do dwóch.

Co zrobiłem

Analiza logów, identyfikacja źródła ruchu, tymczasowe wyłączenie modułu, reguły w Cloudflare. Źródło problemu leżało po stronie modułu dostawcy. Po telekonferencji z InPost dostawca wprowadził zmiany po swojej stronie, a ja włączyłem moduł z dodatkowymi zabezpieczeniami.

Sytuacja

Zgłoszenie w sobotę: strona się nie otwiera. Pamięć serwera podwyższona, ale nieprzekroczona, do bazy szło więcej połączeń i zapytań niż zwykle, a ich źródła nie było widać.

Co zrobiłem

Przeszedłem po kolei każdy element. Przeniosłem domenę do Cloudflare, żeby mieć kontrolę nad źródłami ruchu, włączyłem zabezpieczenia przed botami po stronie hostingu, wyczyściłem cache i zbędne pliki. Wyłączyłem wszystko poza dwoma sklepami klienta, żeby w ogóle się otwierały, a zebrane dane przekazałem hostingowi. Jeszcze tego samego dnia przeniosłem oba sklepy na serwer, na którym mogłem pracować: bazy, pliki, konfigurację i SSL. W poniedziałek ponownie uruchomiłem integrację z BaseLinkerem.

Czego nie wiem

Co dokładnie położyło stronę, nie zostało ustalone. Dlatego nie podaję przyczyny.

Sytuacja

Strona przestała działać. Diagnoza wskazała przepełniony dysk serwera.

Co zrobiłem

Najpierw porządki na szybko, żeby uruchomić stronę. Potem dokładna analiza zawartości serwera i usunięcie zbędnych danych. Przy okazji sprawdziłem, które rozmiary zdjęć generuje szablon, i wyłączyłem nieużywane, żeby zajmowały mniej miejsca.

Problem

Dobór filtra czy oleju do konkretnego auta wymaga przecięcia kilku cech naraz: marki, modelu, silnika. Przy 4800 produktach i prawie 25 000 kategorii dopasowań liczenie tego na żądanie jest wolne.

Rozwiązanie

Wynik nie jest liczony przy wejściu użytkownika - moduł materializuje go cyklicznie przez crona, partiami po 200 rekordów, i aktualizuje tylko różnicę zamiast przebudowywać wszystko od nowa.

Problem

Sklep ładował się wolno. Zadanie: skrócić czas wykonywania operacji po stronie serwera.

Co zrobiłem

Zmierzyłem czasy profilerem PrestaShop i w logach serwera. Największe opóźnienie dawał moduł MailChimp. Razem z tym wyłączyłem zbędne moduły, dodałem indeksy w bazie, ustawiłem cache plików statycznych i zoptymalizowałem zdjęcia produktów. Wynik w testach szybkości Google się poprawił.

Problem

Sklep obsługiwał ok. 200 000 zapytań na dobę, z czego 130 000 pochodziło od botów. Jeden crawler, Meta-ExternalAgent, odpowiadał za ponad 100 000 z nich.

Co zrobiłem

Celem nie była blokada, tylko kontrola: kto przychodzi i po co. Podzieliłem ruch w Cloudflare na kategorie: crawlery AI, asystenci AI, wyszukiwarki AI i klasyczne wyszukiwarki. Ustawiłem reguły WAF i ograniczenie częstotliwości w robots.txt. Na końcu porównałem ruch sprzed wdrożenia i po nim w raporcie dla klienta.

Problem

Stany magazynowe zestawów się nie zgadzały. Po wyłączeniu modyfikacji i porównaniu plików z czystym rdzeniem wyszło, że błąd leży w silniku PrestaShop: Pack::getQuantity ignorował typ „Decrement pack only”, bo empty(0) zwraca prawdę.

Co zrobiłem

Zgłosiłem błąd na GitHubie razem z poprawką. Opiekun projektu włączył ją do gałęzi 9.2.x - możesz to sprawdzić sam, bez pytania mnie o referencje. W sklepie klienta obejście przeniosłem z modyfikacji rdzenia do override.

Problem

Lista produktów miała być sortowana po dostępności do sprzedaży. Żeby kolejność zgadzała się na każdej stronie listy, sortowanie musi się odbyć przed paginacją, w rdzeniu.

Co zrobiłem

Przeanalizowałem listowanie w rdzeniu: providery, hooki, paginację, stany i backorders. Przetestowałem koncepcję i wdrożyłem sortowanie po available_for_order. Przy ograniczonym budżecie klienta część zmiany zostawiłem w klasie Category zamiast w override. To świadomy wyjątek, nie reguła: przy aktualizacji tę zmianę trzeba przenieść.

Sytuacja

Od 19 czerwca 2026 każdy sklep sprzedający konsumentom w Unii musi udostępnić cyfrową funkcję odstąpienia od umowy, niezależnie od tego, na której wersji PrestaShop stoi.

Co zrobiłem

Napisałem moduł samilreturns: formularz odstąpienia dla klienta bez konta, wielojęzyczny, zgodny z multistore, na PrestaShop 1.6, 1.7 i 8. Różnice między 1.6 a nowszymi wersjami trzyma jedna warstwa zgodności, a nie warunki rozsypane po kodzie. Kod działa jednocześnie na PHP 5.6 i 8.x, testuję go na trzech wersjach PrestaShop w Dockerze. Pisałem go z pomocą AI, na środowisku pracy zbudowanym pod ten projekt.

Zastane

Inny wykonawca wdrożył na produkcji moduł zmieniający stany magazynowe zapytaniami SQL z pominięciem klas PrestaShop. Ruch magazynowy przestał się zgadzać na grupie sklepów na wspólnej instalacji.

Co zrobiłem

Zlokalizowałem błąd, naprawiłem dane na podstawie informacji z bazy i zmieniłem wdrożony moduł. Dostęp do produkcji dla poprzedniego wykonawcy został zablokowany.

Sytuacja

Ten sam klient: bez własnego działu IT, kilka sklepów na multistore i kilku zewnętrznych programistów.

Co zrobiłem

Spisałem kilkanaście zasad: osobne tabele zamiast zmian w rdzeniu, natywne funkcje do komunikacji z bazą, testy na własnym środowisku, weryfikacja u mnie przed produkcją. Egzekwowałem je przez kontrolę kodu i koordynowałem ok. 10 osób: programistów, grafika, hosting i magazyn. Osobno, w 2017 roku, wdrożyłem dwa mechanizmy kontroli spójności stanów uruchamiane cronem.

Problem

Po złożeniu drugiego zamówienia w pierwszym zmienił się klient oraz oba adresy: dostawy i faktury.

Co zrobiłem

Odtworzyłem oś czasu ze znaczników w bazie. Drugie zamówienie zrobiło update pierwszego zamiast nowego wpisu, a oba koszyki odwoływały się do tego samego klienta. Potem usunąłem moduł zmieniający numery zamówień i uprościłem ich generowanie, żeby wykluczyć moduły, które mogły wpływać na błąd. Sprawa nie zamknęła się jednym wnioskiem, dalej była obserwowana.

Co zrobiłem

Osobne bazy i konfiguracja dla dev i staging, konta FTP dla każdego środowiska, basic auth na środowiskach testowych, zabezpieczenie .htpasswd i repozytorium przed dostępem z zewnątrz. Webhook z GitHuba aktualizuje gałęzie na serwerze, a hook post-merge czyści cache po wdrożeniu zmian.

Utrzymanie

To nie jest jednorazowa konfiguracja. W listopadzie 2025 naprawiłem webhook, który przestał się uruchamiać na dev i staging.

Zastane

Cron ustawiony błędnie, więc nie odświeżały się sitemapa, wyniki wyszukiwania, filtrowanie ani ceny do Omnibusa. Ponad 40 nieaktualnych modułów. Dostęp SSH otwarty, hasła do FTP i bazy do wymiany, brak CDN.

Co zrobiłem

Zacząłem od audytu serwera i sklepu. Podpiąłem pod crona indeksy, sitemapę i Omnibus, zaktualizowałem moduły, poprawiłem sitemapę i robots.txt. Wymiana haseł, wyłączenie SSH i Cloudflare zostały wdrożone po audycie. Przy aktualizacjach znalazłem zmiany wprowadzone bezpośrednio w źródłach modułu wFirma, które utrudnią jego kolejne aktualizacje.

Sytuacja

Agencja wdrożyła pomiar przez GTM i moduł w sklepie. Potrzebowała odpowiedzi, czy dane z zamówień docierają do GA4 w całości i co dokładnie zbiera moduł.

Co zrobiłem

Przeanalizowałem moduł, bazę, crona i statusy zamówień pod kątem miejsc, w których dane mogą zginąć. Sprawdziłem, jakie dane zbiera moduł, w tym identyfikatory łączące zdarzenie z użytkownikiem. Zdarzenia purchase dosyłane cronem weryfikowałem w GA4 z raportów, bo w tym module nie dało się włączyć debugu. Przepływ przetestowałem na zamówieniach na produkcji, a na końcu sprawdziłem, czy cron jest rzeczywiście podpięty.

Problem

Bez zgód transakcja trafiała do GA4 jako „not set”, bez sesji i użytkownika. Jedna z testowych transakcji była w bazie oznaczona jako wysłana, a w GA4 w ogóle jej nie było. Zgody ustawiały się za późno i w złej kolejności. Po zmianie konfiguracji GTM dane w GA4 przestały się zapisywać, choć w czasie rzeczywistym ruch było widać.

Co zrobiłem

Przetestowałem zamówienia bez zgód i ze zgodami, sprawdziłem kolejność uruchamiania hooków modułów oraz konfigurację tagu, zgód i filtrów w GA4. Wskazałem błędy w GTM, a po aktywacji poprawnej wersji dane zaczęły się zapisywać. Zaleciłem też cron dosyłający brakujące zamówienia co 10 minut.

Problem

Liczba i kwoty zamówień w GA4 nie zgadzały się ze sklepem. Agencja podejmowała decyzje na danych, których nie mogła zweryfikować.

Co zrobiłem

Porównałem zamówienia z bazy sklepu z GA4 i z tym, co przekazał CRM. Wskazałem pierwszy błąd po stronie CRM, wypisałem brakujące zamówienia i opisałem pięć wzorców naliczania kwot. Prawidłowy był tylko jeden. W pozostałych kwota nie uwzględniała rabatu, była naliczona podwójnie albo liczona brutto zamiast netto. Rozbieżność kwot została naprawiona.

Problem

Serwer aktualizował plik feedu co 3 godziny, a Merchant Center pobierał go raz na 24 godziny. Platforma sklepu, oparta na modelu SaaS, udostępniała tylko jeden plik i nie miała Merchant API.

Co zrobiłem

Przeanalizowałem cztery warianty, od Merchant API po pliki uzupełniające, i przetestowałem odczyt przez API na koncie klienta. Zaproponowałem podział pracy: co ma zbudować wykonawca po stronie platformy, a co przekazuje marketing. To była analiza i rekomendacja. Wdrożenie mechanizmu leżało po stronie innego wykonawcy.