PROTOKÓŁ REM
Sklep z merchem fikcyjnego podcastu, zbudowany w PrestaShop od zera — z realną integracją płatności w trybie sandbox, żeby nauczyć się architektury prawdziwego e-commerce zamiast luźnych ćwiczeń.
PROBLEM
"Chciałem nauczyć się PrestaShop nie przez luźne ćwiczenia, tylko przez zbudowanie sklepu, który realnie działa — od katalogu po płatność."
ZAŁOŻENIE
Fikcyjny brief klienta: twórca podcastu potrzebuje klikalnego, wiarygodnie wyglądającego prototypu sklepu z merchem, żeby pokazać go partnerom — z płatnościami w trybie sandbox, zanim padnie decyzja o realnej sprzedaży.
CEL NAUKI
Architektura modułów i hooków PrestaShop, obsługa płatności, panel administracyjny — nie przez dokumentację, tylko przez realny projekt z ograniczeniami prawdziwego klienta.
PŁATNOŚCI
Klient wprost wymagał, żeby proces płatności wyglądał i działał jak produkcyjny, bez ryzyka prawdziwych transakcji. Stripe odpadł szybko — oficjalny moduł do PrestaShop martwy od 2023, integracja oznaczałaby pisanie bramki od zera tylko po to, żeby dostać działające demo. PayPal Sandbox miał natywne wsparcie, ale Tpay — polska bramka z aktywnie utrzymywanym modułem i jawnym wsparciem PS9 — okazał się trafniejszym wyborem.
Aktywnie rozwijany moduł plus w pełni self-service sandbox (żadnych dokumentów weryfikacyjnych, tylko dane firmy) pozwoliły uniknąć pisania integracji płatności od zera, a przy okazji dały bardziej realistyczny wybór dla sklepu po polsku niż Stripe czy PayPal.
Brak weryfikacji dokumentów w Tpay sandbox oznaczał, że cały proces integracji dało się przejść od razu, zamiast czekać na akceptację konta testowego.
CHECKOUT
Do przełożenia na kod był gotowy hi-fi mockup checkoutu — spłaszczony layout, jeden ciągły widok zamiast kroków. Ale checkout classic w PrestaShop działa w całości przez AJAX opięty o konkretne hooki i atrybuty data-* w istniejącym markupie. Przepisanie struktury pod mockup oznaczałoby odtworzenie tego mechanizmu od zera tylko dla zmiany wizualnej.
Zachowany natywny akordeon kroków (Adres → Dostawa → Płatność) — jedyny override to nowy plik Smarty dopisujący pasek ostrzegawczy sandbox, reszta to czysty CSS (np. podświetlanie wybranej metody przez :has(input:checked)).
Wygląd dostosowany do projektu, mechanika zostawiona nietknięta — zbyt duże ryzyko dla demo, żeby dla samej estetyki odtwarzać mechanizm AJAX od zera.
ARCHITEKTURA
Cały motyw wymagał głębokiego restylingu pod autorski kierunek wizualny "odtajnione akta sprawy" — ale sklep musiał zostać w pełni zarządzalny z panelu administracyjnego. To była realnie najtrudniejsza część całego projektu.
Zamiast edytować pliki rdzenia PrestaShop, konsekwentnie użyty motyw-dziecko nad classic, override'y Smarty (extends + block) i hooki własnego modułu. Żadna zmiana wizualna nie hardkodowała treści, która powinna zostać edytowalna.
Przy scalaniu dwóch pasków nagłówka w jeden rząd hooki menu, kontaktu i logo zostały nietknięte — pozycje menu i dane kontaktowe nadal edytowalne z Back Office.
WYZWANIA
Bez większych walk technicznych w sensie "coś nie działało" — realnym wyzwaniem było utrzymanie samoograniczenia: żeby każda zmiana wizualna była kompatybilna z istniejącymi mechanizmami PrestaShop i nie odbierała możliwości zarządzania sklepem z panelu administracyjnego.
REFLEKSJA
Największym zaskoczeniem było tempo pracy. Dotychczasowe doświadczenie to głównie budowanie rzeczy czysto w kodzie od zera — nieoczekiwane było, jak bardzo przyspiesza pracę gotowy, dojrzały panel zarządzania PrestaShop (katalog, zamówienia, konfiguracja). Zamiast budować to wszystko samemu, dało się skupić na integracji płatności i warstwie wizualnej.
Outcome
Sklep jest publiczny i można go realnie przejść od katalogu przez koszyk po checkout z płatnością w sandboksie — wdrożony przez CI/CD (GitHub Actions → Cyberfolks). To pole eksperymentalne, nie prawdziwy biznes, więc bez twardych liczb sprzedażowych — efekt mierzalny inaczej: działający prototyp e-commerce jako dowód zrozumienia architektury PrestaShop.