Dla software house'ów i agencji e-commerce

PrestaShop to nie jest kolejny framework PHP.

Masz własnych programistów, ale projekt na PrestaShop utknął na czymś, czego nie widać w dokumentacji: multistore, stany magazynowe, różnice między wersjami. Wchodzę jako specjalista PrestaShop do konkretnego problemu: konsultacja, druga opinia, przegląd kodu albo najtrudniejszy fragment zadania.

Zakres

Po co zespołowi ktoś z zewnątrz

Przypadek, na którym zespół utknął

Błąd, który wraca po każdej poprawce, stany, które się rozjeżdżają, moduł, który po aktualizacji przestał działać. Schodzę do rdzenia PrestaShop i do bazy, aż znajdę miejsce, w którym to się dzieje.

Druga opinia przed decyzją

Override czy moduł, zmiana w rdzeniu czy obejście, aktualizacja wersji teraz czy później. Mówię, co bym zrobił i ile każda z dróg będzie kosztować w utrzymaniu.

Przegląd kodu pod kątem PrestaShop

Sprawdzam zmiany Twoich programistów przed produkcją: override zamiast edycji plików rdzenia, osobne tabele zamiast nowych kolumn w tabelach sklepu, natywne klasy zamiast ręcznego SQL.

Środowiska i wdrożenia

Dev, staging i produkcja z automatycznym wdrażaniem z GitHuba: webhook, hook post-merge czyszczący cache, zabezpieczone repozytorium i środowiska testowe. Tak pracuję m.in. przy mierzymy.pl i sklep.dayspashe.pl.

Granice

Czego nie robię

Specjalista to ktoś, kto czegoś nie robi. Tu kończy się moja część.

Backlog na godziny

Nie jestem dodatkowymi rękami do listy zadań. Wchodzę tam, gdzie potrzebna jest wiedza o PrestaShop, nie przepustowość.

Zastępowanie zespołu

Nie wypieram Twoich programistów. Pracuję obok nich, także pod Twoją marką, a projekt i klient zostają u Ciebie.

Administracja serwerami

Nie jestem administratorem. Pomagam w podstawowym zakresie i pośredniczę między właścicielem sklepu a adminem, żeby obie strony mówiły o tym samym.

Dowody, nie deklaracje

Cztery sprawy o tym, gdzie w PrestaShop powinna trafić zmiana

To nie są projekty dla software house'ów, tylko sprawy od klientów końcowych. Pokazują, jak pracuję w cudzym kodzie, a pierwszą sprawdzisz sam na GitHubie. Kolejne sprawy, od awarii produkcyjnych po rozjechane stany magazynowe, są w realizacjach.

sklep4x4.expedycja.pl publicznie weryfikowalne

Poprawka przyjęta do rdzenia PrestaShop

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 razem z poprawką. Opiekun projektu włączył ją do gałęzi 9.2.x. W sklepie klienta obejście przeniosłem z modyfikacji rdzenia do override.

PR #42123

poprawka włączona do gałęzi 9.2.x

#42079

zgłoszenie błędu, zamknięte jako zrealizowane

grupa kilku sklepów 2016-2017

Standard programowania dla zespołu, który nie miał żadnego

Sytuacja

Klient bez własnego działu IT, kilka sklepów na multistore i kilku zewnętrznych programistów. Jeden z nich wdrożył na produkcji moduł zmieniający stany zapytaniami SQL z pominięciem klas PrestaShop.

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.

ok. 10

osób koordynowanych wokół sklepów klienta

80+

produktów z rozjazdem sum poprawionych przy wdrożeniu kontroli spójności

karcher-apeks.pl styczeń 2026

Sortowanie przed paginacją i wyjątek od własnej reguły

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ść.

produkcja

rozwiązanie działa w sklepie klienta

core + moduł

zmiana w klasie Category i w module filtrowania

moduł własny dyrektywa (UE) 2023/2673

Jeden moduł na trzy generacje PrestaShop

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. Działa produkcyjnie w kilku sklepach.

1.6 → 8

wersje PrestaShop obsługiwane jednym modułem

produkcja

działa w kilku sklepach

Jak to wygląda

Współpraca krok po kroku

Tryby pracy i sposób wyceny opisuję osobno, na stronie Jak pracuję.

Krótka rozmowa

Opisujesz projekt i miejsce, w którym stoi. Sprawdzamy, czy jest dopasowanie, bez zobowiązań i bez kosztu.

Koszt wejścia, nazwany wprost

Zanim coś doradzę, muszę poznać Twój kod, konfigurację i dane. Ten czas jest płatny i kończy się raportem, który zostaje u Ciebie.

Zakres i limit godzin

Rozliczenie godzinowe z przybliżonym limitem, bez szczegółowego kosztorysu. Awarii nie szacuję z góry: tu liczy się czas reakcji, nie wycena.

Czas reakcji

Na awarię reaguję w ciągu 4 godzin w dni robocze 9-18. U stałych klientów bywa szybciej, nawet w ciągu godziny. Pilne wykonanie ma dopłatę, nazwaną wprost przed startem.

Następny krok

Opisz przypadek, na którym stoicie

Napisz, na jakiej wersji PrestaShop jest projekt i co nie działa. Zaczynamy od krótkiej rozmowy bez zobowiązań.

Przejdź do kontaktu