PrestaShop to system sklepowy open source rozwijany przez PrestaShop SA z Francji — pierwsza wersja pojawiła się w 2007 roku, a kod platformy wydawany jest na licencji Open Software License 3.0 (OSL-3.0). W praktyce możesz pobrać, uruchomić i modyfikować rdzeń bez opłat licencyjnych, ale nie znaczy to, że całe wdrożenie jest darmowe. Moduły, szablony, hosting i godziny deweloperskie są zwykle płatne — licencja open source dotyczy kodu platformy, nie dodatków firm trzecich. Poniżej znajdziesz najczęstsze błędy przy wdrożeniach, checklistę przed startem i odpowiedzi na pytania, które słyszymy od właścicieli sklepów najczęściej. Więcej kontekstu o samej platformie zebraliśmy w sekcji PrestaShop.
PrestaShop to oprogramowanie sklepu internetowego rozwijane przez PrestaShop SA, spółkę z siedzibą we Francji. Pierwsza publiczna wersja pojawiła się w 2007 roku. Dziś projekt utrzymuje równolegle dwie główne linie: 1.7 (starsze wdrożenia, aktualizowane coraz rzadziej) oraz 8.x, rekomendowaną dla nowych sklepów. Wersja 9 jest zapowiadana w roadmapie projektu — przed startem warto sprawdzić, na której gałęzi budujesz, bo wpływa to na dostępność modułów i szablonów.
Rdzeń wydawany jest na licencji Open Software License 3.0 (OSL-3.0). W praktyce oznacza to jedno: nie płacisz PrestaShop SA za prawo do uruchomienia, modyfikowania i hostowania platformy — niezależnie od liczby instalacji i sklepów.
I tu pojawia się najczęstsze nieporozumienie. „Open source” dotyczy kodu platformy, a nie całego ekosystemu wokół niej. Moduły i szablony z Marketplace mają własne licencje — zwykle komercyjne, często w modelu subskrypcji rocznej. Hosting, domena, certyfikat SSL, backupy, wsparcie techniczne i godziny deweloperskie także nie wynikają z licencji.
Co to znaczy dla właściciela sklepu w Polsce:
Jeśli chcesz zobaczyć, jak wygląda to w praktyce, od pobrania rdzenia po konfigurację serwera, zajrzyj do naszych wdrożeń PrestaShop.
OSL-3.0 to licencja zatwierdzona przez Open Source Initiative, ale nie jest kopią GPL. Różnice mają konkretne skutki, jeśli modyfikujesz rdzeń albo sprzedajesz własne moduły.
Co wolno:
Warunek: jeśli rozpowszechniasz zmodyfikowany kod, musisz zachować licencję OSL-3.0 i udostępnić źródła. Nie zamkniesz zmodyfikowanego rdzenia w proprietary binarium i nie przedstawisz go jako własnego produktu.
Klauzula „external deployment” to najważniejsza różnica wobec GPL-2. W OSL udostępnianie zmodyfikowanego kodu jako usługi przez sieć — np. kilku sklepów hostowanych na Twojej infrastrukturze dla klientów — traktowane jest jak dystrybucja. W praktyce użytkownicy wchodzący w interakcję z takim sklepem powinni mieć możliwość otrzymania jego kodu źródłowego. Zwykłego sklepu prowadzonego pod własną marką to zwykle nie dotyczy, ale ma znaczenie dla agencji, white-labeli i modeli „sklep jako usługa”.
Twoje moduły, szablon i tłumaczenia: prawa majątkowe do kodu pisanego na zamówienie należą domyślnie do autora, nie do zlecającego — zmienia to dopiero umowa. Dlatego w każdej umowie z deweloperem zapisz punkt o przeniesieniu praw autorskich i o tym, na jakiej licencji możesz ten kod dalej sprzedawać. Moduł korzystający z hooków i API jest zwykle odrębnym utworem, ale gdy kopiujesz klasy rdzenia, sprawa się komplikuje — to pytanie do prawnika, nie do programisty.
Pułapka przy aktualizacji: bezpośrednie zmiany w plikach rdzenia (klasy w katalogu /classes/, kontrolery w /controllers/) przepadają przy przejściu na kolejne wydanie 8.x i potrafią wyłożyć sklep po upgrade. Zamiast tego używaj hooków (hookDisplayHeader, hookActionCartSave i pozostałych), mechanizmu /override/ albo własnego modułu, który dokłada funkcję bez dotykania rdzenia. Trzymaj też listę wszystkich modyfikacji — bez niej migracja z 1.7 na 8.x zamienia się w śledztwo. Pełną listę hooków i opis override znajdziesz w dokumentacji dla deweloperów PrestaShop.
Krótka odpowiedź: nie. Open source usuwa jedną pozycję z budżetu — licencję — a nie całe TCO. Poniżej kategorie kosztów, które faktycznie płacisz przy sklepie MŚP.
Hosting. PrestaShop to PHP i MySQL. Przy katalogu kilku tysięcy produktów i imporcie CSV na hostingu współdzielonym za 120 zł miesięcznie limity procesora i liczby zapytań potrafią wyłożyć koszyk w poniedziałek rano. Widełki i sens poszczególnych wariantów:
| Wariant | Widełki netto / mies. | Kiedy ma sens |
|---|---|---|
| Hosting współdzielony | 100–300 zł | Start i mały katalog (do ok. 500–1000 produktów), niski ruch, brak własnych cronów |
| VPS (zarządzany lub nie) | 200–700 zł | Stały ruch, importy CSV, moduły z zadaniami w tle, potrzeba własnej konfiguracji PHP i MySQL |
| Serwer dedykowany | 700–2500 zł | Duży katalog, wysoki ruch, integracje z ERP, konieczność strojenia serwera pod siebie |
Decyzję o platformie najłatwiej podjąć, rozpisując sześć kryteriów dla własnego sklepu, a nie porównując ogólne opinie z forum. Tabela poniżej pokazuje, gdzie kończy się wygoda SaaS, a zaczyna koszt elastyczności open source.
W praktyce wybór sprowadza się do dwóch pytań. Pierwsze: czy którykolwiek proces sprzedaży działa u ciebie inaczej niż standardowo — indywidualne cenniki B2B, ceny zależne od grup klientów, konfigurator produktu, sprzedaż wielojęzyczna, rabaty liczone własnym wzorem. Drugie: czy masz kogoś, kto utrzyma serwer, zrobi kopię zapasową i wdroży aktualizację w oknie serwisowym.
Jeśli na oba pytania odpowiadasz „nie”, SaaS zwykle wygrywa czasem startu — sklep uruchamiasz w dniach, nie tygodniach, a płatności i kurierzy są podłączone z gotowych integracji. Jeśli odpowiadasz „tak” choć na jedno, open source daje kontrolę: kod leży na twoim serwerze, możesz go zmienić, a dostawcę hostingu albo agencji wymienić bez przepisywania sklepu.
Zanim wybierzesz, policz realny wymiar pracy po stronie open source. Punkt wyjścia znajdziesz w tekście o rolach, stawkach i godzinach utrzymania sklepu PrestaShop, a zasady wdrożenia zbieramy w sekcji PrestaShop.
| Kryterium | PrestaShop open source | SaaS (Shoper, Shopify) |
|---|---|---|
| Koszt startu | Brak opłaty licencyjnej; koszt to wdrożenie, szablon/moduły i pierwsze miesiące hostingu | Abonament od pierwszego dnia; sklep działa bez prac wdrożeniowych |
| Koszt w skali 3 lat | Stały hosting, aktualizacje, godziny pracy przy rozwoju; koszt rośnie z niestandardowymi wymaganiami | Stały abonament, dodatki i limity planu; koszt rośnie z liczbą funkcji i zamówień |
| Kontrola nad kodem | Pełna — pliki i baza na twoim serwerze, własne moduły i nadpisania | Brak — konfiguracja i API w ramach platformy |
| Czas wdrożenia | Od kilku dni (prosty sklep na gotowym szablonie) do kilku tygodni (integracje, B2B) | Zwykle kilka dni; konfiguracja zamiast programowania |
| Integracja z ERP/WMS | Dowolna: API, pliki wymiany albo własny moduł | Ograniczona do integracji wspieranych przez platformę i jej partnerów |
| Kiedy wygrywa | Niestandardowa logika, własne B2B, wielojęzyczność, brak uzależnienia od dostawcy, WMS/ERP | Mały sklep, brak zaplecza IT, szybki start, gotowe integracje kurierskie i płatnicze |
PrestaShop to aplikacja PHP z bazą MySQL/MariaDB — nie wgra się na „byle co”. Zanim wybierzesz hosting, sprawdź sześć elementów z tabeli poniżej. Ich brak nie wyjdzie na testach strony głównej, ale wyjdzie przy imporcie produktów, wysyłce maili i zamówieniach.
Platforma nie utrzymuje zgodności ze wszystkimi wersjami PHP naraz: starsze gałęzie nie działają na najnowszym PHP, a nowsze mają własne minimum. Matrycę wersji i pełną listę wymaganych rozszerzeń trzyma dokumentacja deweloperska PrestaShop — sprawdzaj ją dla konkretnej wersji, którą wdrażasz. Paczkę pobieraj z oficjalnego źródła; jak nie zepsuć instalacji na starcie, opisujemy w tekście PrestaShop download: skąd pobrać i jak nie zepsuć sklepu.
Hosting współdzielony czy VPS? Współdzielony wystarcza na start małego sklepu: niższy koszt, obsługa po stronie dostawcy. Jego granice poznasz szybko — limity inodes (często 100–250 tys. plików), współdzielone CPU, cron uruchamiany raz na godzinę, dzienne limity wysyłki maili, brak Redis. VPS daje PHP-FPM, Redis, cron co minutę i własne logi, ale dokłada administrację: aktualizacje systemu, firewall, monitoring, kopie zapasowe. Sklep z tysiącami SKU i ruchem w sezonie niemal zawsze kończy na VPS.
Sygnały, że hosting jest problemem:
Kopie zapasowe. Trzymaj je poza serwerem, najlepiej u innego dostawcy. Baza codziennie, pliki codziennie, retencja minimum 30 dni, kopia przed każdą aktualizacją i przed każdą większą zmianą w szablonie. Snapshot u dostawcy hostingu nie jest backupem — znika razem z kontem. Raz na kwartał odtwórz kopię na stagingu i zmierz czas: 30 minut to plan, 8 godzin to panika w środku dnia.
| Element | Minimum | Komfort pracy |
|---|---|---|
| PHP | Wersja wspierana przez twoją gałąź PrestaShop — zgodność sprawdzasz przed wdrożeniem | PHP 8.x z włączonym OPcache |
| Baza danych | MySQL 5.7+ albo MariaDB 10.3+, kodowanie utf8mb4 | Dedykowane zasoby i szybkie IOPS, osobne konto bazy |
| Rozszerzenia PHP | intl, mbstring, curl, gd lub imagick, zip, openssl, fileinfo, simplexml | Dodatkowo Redis lub Memcached na cache |
| Serwer WWW | Apache z mod_rewrite albo nginx z regułami przepisywania | nginx + PHP-FPM skonfigurowany pod sklep |
| Limity PHP | memory_limit 256M, max_execution_time pozwalający na import i eksport | Możliwość podniesienia limitów bez proszenia supportu |
| Dostęp | SSH, Composer, cron, dostęp do logów | Osobne środowisko staging obok produkcji |
W open source nie ma dostawcy, który „zrobi aktualizację za ciebie”. Bezpieczeństwo to proces z rytmem: trzy typy wydań i trzy różne reakcje.
Procedura, która się nie zmienia: kopia bazy i plików → staging z danymi produkcyjnymi → testy funkcjonalne → wdrożenie na produkcję → plan rollbacku. Testy funkcjonalne to nie kliknięcie po stronie głównej. Złóż zamówienie od początku do końca: dodaj produkt jako gość i jako zalogowany klient, przejdź płatność w trybie testowym, sprawdź mail potwierdzający, status zamówienia, fakturę i zmianę stanu magazynowego. Osobno sprawdź rabaty, koszyk porzucony i logowanie do panelu. Rollback plan to konkret: wiesz, z której kopii przywracasz pliki, z której bazę i ile to zajmie. Jeśli nie wiesz — nie masz planu.
Moduł porzucony to najczęstsza dziura. Sprawdź trzy rzeczy: datę ostatniej aktualizacji, deklarowaną zgodność z twoją wersją PrestaShop i to, czy autor odpowiada na zgłoszenia. Moduł, który nie był ruszany od dwóch lat i nie wspiera aktualnej gałęzi, traktuj jak dług techniczny — zablokuje ci najbliższą aktualizację. Jeśli nadpisuje pliki rdzenia (overrides), ryzyko rośnie. Jak oceniać, czy projekt żyje, opisujemy w tekstach o wyborze i wdrożeniu modułów PrestaShop oraz o czytaniu repozytoriów PrestaShop.
Monitoring: error_log PHP i logi serwera przeglądane co tydzień, alerty na nieudane logowania do panelu admina, 2FA, ograniczenie dostępu do katalogu admina po IP, powiadomienie o każdej zmianie plików na produkcji, okresowy skan podatności i porównanie plików rdzenia z wersją z repozytorium.
| Typ wydania | Kiedy wdrażać | Gdzie testować |
|---|---|---|
| Patch bezpieczeństwa | Natychmiast, 24–72 h od publikacji | Na produkcji, po kopii, z gotowym rollbackiem |
| Minor (np. 8.x) | Raz na kwartał, w oknie serwisowym | Staging z kopią danych produkcyjnych |
| Major (nowa gałąź) | Raz w roku, po testach kompatybilności | Staging, testy modułów i szablonu przez 1–2 tygodnie |
Moduł do PrestaShop to często większy wydatek niż sam sklep. Zanim klikniesz „Kup”, przejdź checklistę — zajmuje pięć minut, a potem oszczędza tygodnie konfliktów i zleceń serwisowych.
| Co sprawdzić | Jak to zrobić w 5 minut | Czerwona flaga |
|---|---|---|
| Autor | Karta modułu, liczba innych wydanych modułów, historia konta | Konto bez historii, brak danych firmy |
| Historia aktualizacji | Changelog i daty wersji | Ostatnia wersja starsza niż 12 miesięcy |
| Kompatybilność z Twoim PS | Zakres wersji z karty vs. Twoja wersja (1.7.x / 8.x) | „Działa na wszystkich wersjach” |
| Jakość kodu | Zajrzyj do struktury plików: kontrolery, /src, brak zapytań SQL w .tpl | Pliki zakodowane base64, brak repozytorium |
| Opinie | Addons, fora branżowe, zgłoszenia na GitHubie | Zamknięte issues bez odpowiedzi |
| Warunki supportu | Czy dostajesz aktualizacje, przez jaki okres, jakim kanałem | Support tylko przez formularz, bez terminu |
Pułapka „kolejnej płatnej wtyczki” polega na doklejaniu gotowców do każdego nietypowego procesu. Po pięciu modułach masz stos nakładających się hooków, dwa przeładowania tego samego kontrolera i trzy miejsca, w których liczona jest cena. Reguła jest prosta: proces standardowy — płatności, kurierzy, faktury, feedy — kupuj gotowy. Proces, który jest Twoją przewagą — konfigurator wyceny, nietypowe reguły rabatowe, integracja z ERP — pisz jako jeden własny moduł, w oparciu o oficjalne API i strukturę z dokumentacji dla deweloperów PrestaShop.
Wsparcie działa w trzech modelach: forum społeczności (darmowe, bez terminu reakcji), zgłoszenia na GitHubie (skuteczne, gdy maintainer jest aktywny — patrz data ostatniej odpowiedzi) oraz płatne SLA od agencji wdrożeniowej. Każdy pośrednik w łańcuchu zgłoszenia dodaje 24–48 godzin. Bezpośredni kontakt z deweloperem modułu skraca czas reakcji i obniża koszt utrzymania, bo nie płacisz za przekazywanie informacji tam i z powrotem.
Nie każdemu sklepowi open source się opłaca. Są trzy sygnały, po których warto się zatrzymać i policzyć koszt utrzymania, zamiast elastyczności.
Drugie ryzyko to zespół jednego dewelopera. Bus factor 1: gdy ta osoba zniknie lub zmieni pracę, nie ma kto wdrożyć poprawki bezpieczeństwa, a nikt inny nie zna sklepu. Trzecie — brak dokumentacji wdrożenia: repozytorium bez README, brak opisu cronów, kolejek mailowych i nadpisań w szablonie. Dokument wdrożenia musi po odbiorze zostać u Ciebie, razem z dostępami.
| Pytanie do wykonawcy | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Staging i proces wdrożenia | Osobne środowisko testowe i opisana procedura publikacji na produkcję | „Wgrywamy od razu na produkcję” |
| SLA i czas reakcji | Konkretny czas, np. 4 h w godzinach pracy przy błędzie krytycznym, zapisany w umowie | „Reagujemy na bieżąco” |
| Definicja „gotowe” | Kryteria odbioru, lista testów, określona liczba rund poprawek w cenie | „Dogadamy się” |
| Koszt godzin po wdrożeniu | Stawka, minimum rozliczeniowe i zakres prac | Stawka podana dopiero przy pierwszej awarii |
| Własność dostępów | Repozytorium, hosting, domena i konta na Twoją firmę | Wszystko na konto wykonawcy |
Jeśli na te pytania nie ma zapisanych odpowiedzi, nie podpisuj umowy. Sprawdź też, jak wygląda realne utrzymanie sklepu i ile kosztują role techniczne.
Traktowanie „open source” jako „darmowe wszystko” i planowanie budżetu tylko na hosting.
Jak wykryć: W arkuszu kosztów nie ma żadnej pozycji na płatne moduły, szablon, pracę deweloperską ani aktualizacje. Jedyny koszt to abonament hostingowy.
Jak naprawić: Rozpisz TCO na 3 lata w czterech pozycjach: hosting, moduły (licencja jednorazowa vs subskrypcja), godziny deweloperskie, czas na aktualizacje i testy po nich.
Modyfikowanie plików rdzenia zamiast używania override, hooków i własnego modułu.
Jak wykryć: W repozytorium widać zmiany w plikach core, brak katalogu /override, a po aktualizacji sklep przestaje działać lub gubi funkcje.
Jak naprawić: Przenieś logikę do własnego modułu, korzystaj z hooków i mechanizmu override. Każdą ingerencję w rdzeń opisuj w changelogu i testuj na kopii sklepu.
Wybór hostingu współdzielonego pod sklep z dużym katalogiem, integracjami i ruchem.
Jak wykryć: Wysoki TTFB, przekroczone limity inodes, brak dostępu do logów, brak SSH, zadania cron odpalane nieregularnie lub wcale.
Jak naprawić: Przenieś sklep na VPS lub serwer dedykowany z kontrolą nad wersją PHP, cache, cronem i kolejkami maili. Zostaw hosting współdzielony tylko dla małych, spokojnych sklepów.
Brak zapisów o prawach do kodu w umowie na moduł lub szablon pisany na zamówienie.
Jak wykryć: W umowie nie ma przeniesienia praw majątkowych, dostępu do repozytorium ani zasad aktualizacji i wsparcia po odbiorze.
Jak naprawić: Ustal przed startem: kto ma prawa do kodu, gdzie leży repozytorium, kto i na jakich zasadach robi aktualizacje po wdrożeniu.
Aktualizacja PrestaShop bez kopii zapasowej i bez środowiska testowego.
Jak wykryć: Aktualizacja puszczana wprost na produkcji, brak snapshotu bazy i plików, brak testu ścieżki zakupu, płatności, maili i faktur.
Jak naprawić: Zrób kopię bazy i plików, postaw staging, przejdź pełną ścieżkę zamówienia razem z płatnością i wysyłką, a dopiero potem wdrażaj na produkcję.
Pomijanie klauzuli „external deployment”, gdy udostępniasz zmodyfikowany kod jako usługę.
Jak wykryć: Udostępniasz zmodyfikowaną wersję PrestaShop klientom jako usługę (hosting, SaaS) i nie publikujesz odpowiadającego jej kodu źródłowego.
Jak naprawić: Jeśli planujesz udostępniać zmodyfikowany rdzeń jako usługę, przeanalizuj zapisy OSL-3.0 z prawnikiem przed startem, a nie po pierwszej reklamacji.
PrestaShop open source nie kosztuje Cię na poziomie licencji, ale kosztuje na poziomie hostingu, modułów, pracy deweloperskiej i czasu na aktualizacje. Kluczowe rozstrzygnięcia zapadają przed startem: wersja platformy, środowisko hostingowe, sposób wprowadzania zmian w kodzie i budżet na 3 lata. Jeśli nie policzysz tych pozycji wcześniej, różnica między open source a SaaS okaże się odwrotna do oczekiwań. Open source wygrywa tam, gdzie liczy się kontrola nad kodem i integracje — i przegrywa tam, gdzie brakuje zaplecza technicznego.
Kod platformy tak — licencja OSL-3.0 nie przewiduje opłat licencyjnych ani tantiem, więc możesz go pobrać i uruchomić bez płacenia PrestaShop SA. Darmowe nie jest natomiast wdrożenie: hosting, płatne moduły, szablon, praca deweloperska i utrzymanie generują realne koszty. Dlatego pytanie „ile kosztuje PrestaShop” warto zamienić na „ile kosztuje mój sklep na PrestaShop w horyzoncie 3 lat”.
Tak. OSL-3.0 pozwala uruchamiać, modyfikować i redystrybuować kod, również komercyjnie. Własne moduły, szablony i tłumaczenia, które napisałeś sam lub zamówiłeś, podlegają Twojej umowie z wykonawcą — licencja platformy ich nie przejmuje. Jeden wyjątek wymaga uwagi: klauzula „external deployment”, czyli sytuacja, gdy udostępniasz zmodyfikowany kod jako usługę.
Mogą i zwykle psują. Każda aktualizacja nadpisuje pliki rdzenia, więc Twoje zmiany przepadają albo powodują błędy. Pracuj na override, hookach i własnym module — wtedy aktualizacja dotyka tylko rdzenia, a Twoja logika zostaje nietknięta.
Gałęzią, w którą inwestuje PrestaShop SA, jest 8.x, natomiast wersja 9 pozostaje w roadmapie. Gałąź 1.7 to starsze rozwiązanie — ma sens głównie przy istniejących sklepach z modułami, które nie zostały jeszcze przepisane. Konkretnych dat premiery i końca wsparcia nie podajemy, bo zmieniają się w czasie: sprawdź aktualny stan w dokumentacji deweloperskiej PrestaShop.
Dla małego sklepu bez integracji i przy niewielkim ruchu często wystarczy. Problem pojawia się wraz z katalogiem, liczbą modułów i ruchem: rośnie TTFB, kończą się limity inodes i zaczyna brakować kontroli nad cronem i logami. Zanim zostaniesz na hostingu współdzielonym, zmierz czas odpowiedzi serwera i porównaj go z progami opisanymi w wytycznych Web Vitals.
Łatwo przenoszą się dane katalogowe: produkty, kategorie, zdjęcia, opisy i dane klientów. Trudniej z historią zamówień, treściami CMS, linkami i całym SEO — część trzeba odtworzyć ręcznie lub za pomocą przekierowań. Najwięcej pracy kosztuje zwykle odbudowa integracji płatności, kurierów i magazynu, bo te w SaaS działały „z pudełka”.
Ty jako właściciel — open source nie ma dostawcy, który zrobi to za Ciebie w ramach abonamentu. W praktyce oznacza to umowę z agencją lub deweloperem na utrzymanie, z jasnym zakresem: aktualizacje, monitoring, kopie zapasowe i czas reakcji na incydent. Role i stawki w takich umowach opisujemy w materiale o pracy przy PrestaShop.
Zacznij od wypisania realnych potrzeb: płatności, kurierzy, faktury, ERP i magazyn. Dla każdej sprawdź model licencji — jednorazowa czy miesięczny abonament — i koszt odnowienia po roku. Część modułów na liście „must have” da się zastąpić funkcjami rdzenia albo prostym własnym modułem; kryteria wyboru rozpisaliśmy w tekście o modułach PrestaShop.
Jeśli chcesz policzyć TCO sklepu na PrestaShop albo sprawdzić, czy Twój hosting udźwignie planowany katalog i ruch, napisz do nas — zajmiemy się audytem wdrożenia i środowiska. Odpowiemy konkretami, a nie ogólnym „to zależy”.