French Disorder. Wsparcie sklepu internetowego

French Disorder to francuska marka odzieżowa ze sklepem na PrestaShop. Sklep sprzedaje codziennie, więc każda awaria w zamówieniu, płatności czy mailach do klientów od razu odbija się na przychodach.

Klient potrzebował stałego zespołu technicznego na cały łańcuch: witryna, składanie zamówienia, płatności, magazyn i dostawa, zwroty i dokumenty księgowe. Kodu nie pisaliśmy my - przejęliśmy go takim, jaki był: PrestaShop z niestandardowymi modułami, integracjami płatności i połączeniem z magazynem. Pracujemy od listopada 2025 roku.

Najważniejsze w tym projekcie jest naprawianie błędów. Sklep trafił do nas z dużym nagromadzonym bagażem: przez dziewięć miesięcy wyczyściliśmy ogromną liczbę bugów, od błędnej matematyki na fakturach po niedochodzące maile, i co tydzień rozbieramy kolejne, żeby system działał poprawnie.

74% kart przychodzi z oznaczeniem critical lub urgent. Taki jest profil wsparcia działającego sklepu: większość zgłoszeń dotyczy tego, co nie działa właśnie teraz - u klienta albo w rozliczeniach.

Kilka przykładów: cena w prywatnej wyprzedaży liczyła się według starych reguł, ApplePay pobierał opłatę dwukrotnie, część kupujących przestała dostawać maile o zamówieniu.

Około połowa zadań dotyczy pieniędzy. Część płatnicza to PayPal, Payplug z ApplePay, karty podarunkowe Edenred i Kadéos, płatność w czterech ratach. Tu też rozbieraliśmy incydenty, na przykład podwójne pobranie przez ApplePay.

Druga część to księgowa operacyjka: noty kredytowe, faktury i korekty podatkowe dla dziesiątek klientów. Te zadania powtarzają się co tydzień i przechodzą przez nas.

Sklep jest połączony z fizycznym magazynem: integracja z MWS, synchronizacja stanów, generowanie etykiet wysyłkowych dla zamówień do USA, reguły wyliczania kosztów dostawy.

Osobny kierunek to eksporty danych. Gdy standardowe raporty PrestaShop nie wystarczają, piszemy zapytania SQL do bazy: zwroty, sprzedaż, uzgodnienia za okresy.

Gdy przejmowaliśmy projekt, sklep żył na drogiej infrastrukturze, a rachunki za nią wyraźnie przewyższały realne potrzeby strony. Przeprowadziliśmy audyt: zmierzyliśmy obciążenie, policzyliśmy, ile zasobów sklep naprawdę zużywa, i dobraliśmy platformę, na której ta sama moc starcza z zapasem - za odczuwalnie mniejsze pieniądze. Na wydajności klient nie stracił nic.

Przeprowadzkę zrobiliśmy od zera i do końca: postawiliśmy i skonfigurowaliśmy serwer, środowisko webowe i bazę, przenieśliśmy sklep, przeszliśmy testy i przełączyliśmy ruch tak, że kupujący niczego nie zauważyli.

Osobna praca to szybkość. PrestaShop tej generacji to żarłoczna platforma: ciężkie zapytania do bazy, fasetowe filtry, które uwielbiają crawlery, generowanie strony przy każdej okazji. Zbudowaliśmy cache w kilku warstwach, od skompilowanych szablonów po gotowe strony na serwerze WWW, odcięliśmy śmieciowy ruch botów i doprowadziliśmy czas odpowiedzi do stabilnie szybkiego. Sklep lata, choć w środku wciąż ta sama Presta.

Działający sklep ciągle ktoś próbuje złamać. W lipcu formularz zapisu do newslettera dostał się pod list bombing: boty tysiącami zapisywały cudze adresy, a serwis mailingowy zagroził odcięciem konta za zepsutą reputację nadawcy. Przegląd kodu pokazał przyczynę: captcha w module zapisu była po cichu zepsuta, jeden znak w warunku zamieniał weryfikację w atrapę.

Zamknęliśmy lukę i przenieśliśmy wszystkie cztery formularze strony - rejestrację, oba zapisy do newslettera i formularz kontaktowy - na Cloudflare Turnstile z weryfikacją tokena po stronie serwera. W Cloudflare stanęły reguły przeciwko sieciom botnetów i limity częstotliwości zapytań, a na serwerze działa filtr krajów: razem odcinają około 22 tysięcy śmieciowych żądań na godzinę. Z bazy wyczyściliśmy 448 fałszywych subskrybentów i reputacja wysyłek się odbudowała.

Przy okazji ustaliliśmy, dlaczego duża kategoria katalogu przez półtora miesiąca nie otwierała się z wyszukiwarki i zakładek: zahaczył ją zbyt ostry filtr serwerowy po poprzedniej fali botów. Nie mieliśmy dostępu do konfiguracji serwera, więc obeszliśmy ograniczenie regułą Cloudflare - sekcja znów działa i wróciła do wyników Google.

Zadania idą przez tablicę Trello z priorytetami: klient zakłada kartę, my oceniamy pilność i bierzemy do pracy. Przez dziewięć miesięcy w kartach zebrało się 281 komentarzy z ustaleniami i akceptacjami.

Szczyt przypadł na start - 88 zadań w pierwsze trzy miesiące, póki sklep doprowadzaliśmy do stabilnego stanu. Potem strumień zmalał i trzyma się poziomu planowego wsparcia.

Współpraca trwa: zadania przychodzą i są zamykane co tydzień. Format bez zmian - Trello z priorytetami, pilne zgłoszenia bierzemy poza kolejką.