Czym jest PrestaShop demo i do czego realnie służy

Słowo „demo” w rozmowach o PrestaShop oznacza trzy różne rzeczy. Pomylenie ich kosztuje: jedna osoba traci pół dnia pracy, która za chwilę przepadnie, inna wpisuje dane klientów tam, gdzie nie wolno.

• Publiczne demo PrestaShop — otwarta instalacja udostępniona przez PrestaShop SA. Bez rejestracji, bez umowy, dostępna dla każdego. O niej jest ten tekst.
• Środowisko testowe (staging) — Twoja kopia sklepu: ta sama wersja PrestaShop, PHP, motyw i moduły co produkcja, ale na osobnym adresie i bez ruchu. Tu testujesz aktualizacje i włączasz płatności w trybie testowym.
• Sklep produkcyjny — realny ruch, realne zamówienia, realne dane osobowe.

Publiczne demo daje dostęp do dwóch warstw: front office (katalog, karta produktu, koszyk, checkout) i back office (panel pod adresem z prefiksem /admin…, z produktami, zamówieniami, modułami i ustawieniami). To wystarczy, żeby ocenić ergonomię panelu. Nie wystarczy do niczego więcej.

Dlaczego nie wolno tam wpisywać realnych danych? Bo demo nie jest Twoje. Administruje nim inny podmiot, nie masz z nim umowy powierzenia przetwarzania (art. 28 RODO), nie kontrolujesz kopii zapasowych ani listy osób z dostępem. Wpisany adres e-mail, numer telefonu czy numer zamówienia klienta są widoczne dla pozostałych odwiedzających do najbliższego resetu. Do testów używaj danych wymyślonych: „Jan Testowy”, adres w domenie example.com, kwota 1,00 zł.

Demo to także nie miejsce pracy. Nie ma tam wersjonowania, nie ma cofnięcia, a brak kopii zapasowej oznacza, że żmudna konfiguracja zniknie bez ostrzeżenia.

Wersja ma znaczenie. Linia 1.7 i nowsze 8.x/9.x to inne zaplecze, inny motyw i inne wymagania PHP — panel wygląda podobnie, ale szczegóły się różnią. Sprawdź, którą wersję hostuje demo, i porównaj z tym, co planujesz wdrożyć; zmiany między wydaniami opisujemy w przeglądzie wydań PrestaShop. Aktualne wymagania techniczne trzyma dokumentacja deweloperska PrestaShop — tam sprawdzisz, czy Twoja wersja PHP w ogóle wystartuje.

Oficjalne demo PrestaShop: jak wejść i co obejrzysz w 15 minut

Demo ma dwa wejścia. Front office to zwykły sklep — katalog, koszyk, checkout. Back office to panel administracyjny, do którego logujesz się danymi podanymi obok linku do demo.

Ważne: login i hasło publikowane są na bieżącej stronie demo PrestaShop, a nie w poradnikach i na blogach. Powód jest prosty — dane rotują się razem z resetem. Jeśli wpisujesz login z artykułu sprzed roku i nie działa, to nie awaria, tylko nieaktualny poradnik.

Reset jest cykliczny i obejmuje całą bazę: produkty, zamówienia, klientów, konfigurację. Praktyczna konsekwencja: nie buduj na demo katalogu, nie ustawiaj stawek VAT, nie konfiguruj szablonów maili. Wszystko przepadnie. Jeśli chcesz coś pokazać zespołowi, rób zrzuty ekranu, nie linki do demo.

Na demo można doinstalować moduł (z katalogu lub z pliku ZIP) oraz motyw. Po resecie znikną razem z bazą — a przy okazji potrafią zniknąć moduły, które były tam wcześniej. Demo nie odtwarza Twojej konfiguracji, traktuj je jak poligon na jedną sesję, nie jak miejsce na próbę wdrożenia.

Pięć ekranów, które warto zobaczyć:

• Katalog → Produkty — lista, filtry, akcje masowe, szybka edycja ceny i stanu.
• Edycja produktu z kombinacjami — zakładki Cena, Kombinacje, Stan, SEO. Sprawdź, czy zakładanie wariantu rozmiar/kolor jest dla Ciebie czytelne.
• Sprzedaż → Zamówienia → szczegóły — statusy, historia, faktura, powiązana płatność i wysyłka.
• Płatności i Dostawa — gdzie dodaje się metodę płatności i przedziały wagowe oraz cenowe dla kurierów.
• Parametry zaawansowane → Wydajność — cache, kompresja, Smarty. To ekran, który w realnym sklepie decyduje o szybkości, a na demo i tak działa na cudzym serwerze.

Jeśli po drodze chcesz sprawdzić element czysto wizualny, zobacz gdzie zmienić logo PrestaShop i jaki rozmiar wgrać.

Czego oficjalne demo nie sprawdzi – 6 rzeczy, które mylą

Demo działa na środowisku współdzielonym. To jedno zdanie wyjaśnia większość rozczarowań, jakie widzimy u klientów po wdrożeniu.

1. Wydajność i czas odpowiedzi serwera. TTFB zmierzony na demo nie mówi nic o Twoim hostingu. Realny sklep z 5 000 SKU, 30 modułami i ruchem kilkuset sesji dziennie zachowa się inaczej. Licz na własnym środowisku, celując w progi Core Web Vitals: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 (definicje Web Vitals).
2. Maile transakcyjne. Potwierdzenie zamówienia, zmiana statusu, informacja o wysyłce — na demo zwykle nie dochodzą albo wysyłka jest wyłączona. Nie sprawdzisz tam szablonów, kolejek, SPF/DKIM ani tego, czy wiadomość trafia do skrzynki, a nie do spamu.
3. Integracje płatności i kurierów. Bez kluczy produkcyjnych zostaje tryb testowy. Chcesz wiedzieć, jak wygląda powrót z bramki, co się dzieje po nieudanej płatności i czy status zamówienia zmienia się sam — to robisz na stagingu. Konfigurację konkretnych bramek opisujemy osobno, np. PayU w PrestaShop.
4. Import i struktura własnego katalogu. Na demo jest kilkadziesiąt przykładowych produktów. Różnica między 200 a 20 000 pozycji z eksportu ERP to nie skala, a inna klasa problemów: duplikaty, brakujące kategorie, atrybuty, warianty i czas samego importu.
5. Zachowanie po aktualizacji modułów. Na demo nie zobaczysz, czy motyw przetrwa aktualizację modułu ani czy nadpisania w plikach motywu zostaną zachowane. To najczęstsze źródło awarii dzień po wdrożeniu.
6. Cache, CDN i konfiguracja serwera. Full page cache, Varnish, Cloudflare, HTTP/2, OPcache, PHP-FPM — na demo są nieustawione albo domyślne. W realnym sklepie właśnie te elementy decydują o czasach ładowania.

Wniosek: demo służy do oceny panelu i procesu, nie do oceny sklepu. Zanim podejmiesz decyzję o wersji i hostingu, ustal, co i gdzie będziesz testować.

Demo publiczne czy własne środowisko testowe? Porównanie w 5 kryteriach

Publiczne demo i własne środowisko odpowiadają na dwa różne pytania. Demo mówi: „czy rozumiem ten panel”. Własna instalacja mówi: „czy ten sklep uniesie moje procesy”. Mylenie tych dwóch rzeczy to najczęstsza przyczyna rozczarowania po wdrożeniu.

Kryterium	Publiczne demo PrestaShop	Własne środowisko testowe
Czas do startu	0 minut — wchodzisz na adres i klikasz	30–60 minut (hosting + instalator), 2–3 h przy Dockerze
Koszt	0 zł	0 zł lokalnie, ok. 15–60 zł/mies. za subdomenę na hostingu
Instalacja modułów i motywów	Zwykle zablokowana, brak FTP i dostępu do bazy	Pełny dostęp do FTP, MySQL, menedżera modułów i plików motywu
Realność pomiaru wydajności	Brak — nieznana infrastruktura i obciążenie, wyniki nieprzenośne	Tak — mierzysz TTFB, LCP, liczbę zapytań SQL na własnym serwerze
Trwałość danych i logi	Reset co kilka godzin lub dni, brak logów PHP i MySQL	Dane zostają do Twojej decyzji, masz logi, Xdebug i profiler

Rekomendacja: publiczne demo traktuj jako 15–30 minut rekonesansu przed rozmową z wykonawcą. Sprawdzasz układ menu, edycję produktu z kombinacjami, ogólną logikę panelu. Jeśli po tym czasie nie wiesz, gdzie ustawia się strefę dostawy, to nie znaczy, że platforma jest zła — znaczy, że potrzebujesz pokazu od człowieka.

Własne środowisko uruchamiasz, gdy podejmujesz decyzję o platformie i chcesz mieć dane, a nie wrażenia. Tam robisz próbę migracji 200–500 produktów z CSV, testujesz moduł płatności w trybie sandbox i sprawdzasz, czy import z ERP nie sypie się na polskich znakach.

Własne demo jest obowiązkowe w trzech sytuacjach:

• sklep B2B — ceny grupowe, indywidualne rabaty, płatność z odroczonym terminem, limity kredytowe;
• katalog wielojęzyczny — 2–3 języki, osobne tłumaczenia atrybutów i meta, rosnąca liczba kombinacji;
• integracja z ERP lub WMS — na publicznym demo nie podłączysz kluczy ani nie sprawdzisz mapowania pól.

Pomiar wydajności zostaw na własne środowisko — na współdzielonym demo wynik nie przenosi się na Twoją infrastrukturę. Co mierzyć i jakie progi mają sens, opisuje dokumentacja Web Vitals. Zakres typowego wdrożenia znajdziesz w naszym dziale PrestaShop.

Jak postawić własne demo PrestaShop w 30–60 minut (3 warianty)

Trzy warianty różnią się tym, jak szybko startujesz i ile kontroli dostajesz. Wybierz jeden, nie wszystkie.

Wariant A — subdomena testowa na hostingu (realnie ~30 minut). Kroki: w panelu hostingu (cPanel, DirectAdmin) dodaj subdomenę, np. test.twojadomena.pl, z osobnym katalogiem i certyfikatem SSL. Utwórz bazę MySQL i użytkownika z pełnymi prawami tylko do tej bazy. Pobierz paczkę PrestaShop ze strony projektu, wgraj przez FTP lub rozpakuj w menedżerze plików. Wejdź na adres subdomeny i przejdź kreator: język, dane sklepu, dane bazy, konto administratora. Po instalacji usuń katalog /install, zmień nazwę katalogu admina na własną i wymuś HTTPS. Sprawdź wersję PHP w panelu przed startem — niezgodna wersja to najczęstszy powód błędu 500 w pierwszym kroku.

Wariant B — lokalnie: Docker albo XAMPP. Ma sens, gdy pracujesz bez internetu, chcesz klonować środowisko, testować moduły albo debugować kod. W Dockerze stawiasz osobne kontenery dla MySQL i PrestaShop, w XAMPP wystarczy Apache + MySQL. Na co uważać: lokalny adres nie ma publicznego IP, więc nie przetestujesz webhooków płatności ani zwrotnych URL-i bramek. Nie oceniaj tu też wydajności — dysk i pamięć laptopa rządzą się innymi prawami niż serwer.

Wariant C — staging u dostawcy hostingu jednym klikiem. Wygodne, bo dostajesz kopię sklepu z bazą w kilka minut. Ograniczenia: nie zmienisz wersji PHP ani konfiguracji serwera, środowisko bywa resetowane, a część dostawców pozwala tylko przenosić zmiany w jedną stronę.

Wspólne kroki po instalacji:

• SSL włączony i wymuszony, inaczej koszyk i płatności będą się dziwnie zachowywać;
• kopia zapasowa bazy i plików przed każdym testem — 5 minut, które ratuje dzień;
• konto testowe klienta z prawdziwym adresem e-mail, którego używasz do sprawdzania maili;
• usunięcie danych przykładowych (produkty, klienci, zamówienia) przed importem własnych, żeby nie mieszać statystyk.

Wymagania wersji PHP i MySQL sprawdzaj w PrestaShop Developer Documentation — zmieniają się przy każdym wydaniu. Pomocne bywa też śledzenie wydań: zobacz, jak czytać PrestaShop news.

Co przetestować w demo przed decyzją – checklista 12 punktów

Poniższe 12 punktów odróżnia „ładnie wygląda” od „nadaje się do prowadzenia sklepu”. Każdy test wykonaj na obu ścieżkach: desktop i telefon (ekran ok. 390 px).

Test	Co dokładnie sprawdzić
1. Ścieżka zakupu — desktop	Dodanie do koszyka, zmiana ilości, dane klienta, płatność, ekran potwierdzenia
2. Ścieżka zakupu — telefon	Klawiatury pól, autouzupełnianie adresu, czy koszt dostawy widać przed płatnością
3. Koszt dostawy	Reguły wg wagi, ceny, kraju; czy próg darmowej wysyłki liczy się po rabatach i z VAT
4. Podatki i ceny	Czy cena brutto zmienia się poprawnie dla kraju dostawy, stawki 23/8/5%, cena z VAT w podsumowaniu
5. Płatności online	Konfiguracja modułu w trybie testowym, obsłużone scenariusze: sukces, anulowanie, brak odpowiedzi
6. Automatyczny status po opłaceniu	Czy zamówienie samo przechodzi na „Płatność zaakceptowana”, czy mail do klienta faktycznie wychodzi
7. Etykieta kuriera	Generowanie etykiety InPost, DPD, DHL z karty zamówienia; czy waga i wymiary się przenoszą
8. Faktura i dane B2B	Pole NIP, walidacja, faktura PDF, numeracja, dane firmy i nabywcy na dokumencie
9. Warianty i stany magazynowe	Kombinacje rozmiar/kolor, wpływ na stan, rezerwacja towaru przy złożeniu zamówienia
10. Rabaty i kody	Czy kupon łączy się z darmową dostawą i czy reguła nie dubluje się z promocją katalogową
11. Edycja zamówienia	Dodanie produktu do istniejącego zamówienia, zmiana adresu, ponowne wysłanie maila
12. Dodanie produktu od zera	Ile minut zajmuje Ci wystawienie 1 produktu z opisem, zdjęciami, ceną i stanem

Sposób zapisu wyniku: prowadź arkusz z trzema kolumnami — „przeszło”, „nie działa”, „wymaga sprawdzenia na stagingu”. Trzecia kolumna jest najważniejsza. Na publicznym demo nie sprawdzisz maili transakcyjnych ani integracji z kluczami produkcyjnymi, więc wszystko, co dotyczy płatności i kurierów, i tak wróci na własne środowisko. Konfigurację bramki przećwiczysz według naszego materiału o PrestaShop PayU: konfiguracja, statusy i błędy.

Wydajność i SEO na demo: co zmierzysz, a co Cię zmyli

Na publicznym demo ocenisz strukturę SEO, ale nie szybkość. To dwa różne pytania i mieszanie ich prowadzi do błędnych wniosków.

Co ma sens na demo:

• Struktura URL — zakładka SEO i URL (Parametry sklepu → Ruch i SEO). Sprawdź przepisywanie, wzorzec {id}-{rewrite}, adresy kategorii i produktów oraz to, czy ten sam produkt nie odpowiada pod dwoma adresami: z parametrem id_product i po przepisaniu.
• Breadcrumbs i linkowanie wewnętrzne — czy okruszki generują się na karcie produktu, w kategorii i w wynikach wyszukiwania.
• Meta — tytuł i opis na demo pochodzą z szablonu. Sprawdź, czy da się je nadpisać ręcznie dla konkretnej kategorii i pojedynczego produktu.
• Dane strukturalne — czy motyw wstawia JSON-LD typu Product, Offer i BreadcrumbList, czy to tylko fragment kodu bez pokrycia w wymaganiach Google.
• Waga obrazków — Preferencje → Obrazy: rozmiary miniatur, format (WebP czy tylko JPG) i ile kilobajtów waży zdjęcie na karcie produktu.
• Sygnały Core Web Vitals — LCP, INP i CLS zmierzone w Lighthouse to wskazówka, że coś jest ciężkie. Definicje i progi opisuje dokumentacja Core Web Vitals na web.dev.

Czego nie mierzyć na demo: TTFB i czasu odpowiedzi serwera. Demo stoi na współdzielonej infrastrukturze, z jedną bazą dla wszystkich testerów, bez CDN i bez Twojego cache. Wynik 900 ms TTFB nie mówi nic o Twoim sklepie.

Uczciwy benchmark wymaga czterech rzeczy: tego samego katalogu (import Twojego CSV, ta sama liczba kombinacji), hostingu, na którym sklep ma realnie działać, testów z wyłączonym i włączonym cache oraz minimum trzech pomiarów — patrz na medianę, nie na pierwszy wynik.

Motyw zaniża ocenę platformy. Domyślny szablon demo ze sliderem, dwoma zewnętrznymi fontami i sześcioma modułami na stronie głównej potrafi podnieść LCP o sekundę. Testuj docelowy motyw z docelową liczbą modułów, inaczej ocenisz szablon, a nie PrestaShop.

7 pułapek, które kosztują czas i pieniądze

Większość problemów zgłaszanych po „testach na demo” nie wynika z PrestaShopu, tylko z kolejności działań. Siedem pułapek, które widzimy najczęściej:

• Praca na publicznym demo jak na produkcji. Publiczne instancje resetują się co kilka godzin lub raz na dobę. Jeśli wgrasz tam logo, opisy 200 produktów i klucze API płatności, rano ich nie będzie. Demo służy do klikania, nie do konfiguracji.
• Brak kopii bazy i plików przed testem modułu. Zanim wyłączysz moduł albo wgrasz nowy, zrób zrzut: mysqldump całej bazy plus archiwum katalogu /modules i motywu. Bez tego „zepsułem sklep” oznacza odtwarzanie konfiguracji z pamięci.
• Moduły z nieznanych źródeł. Wtyczka pisana pod PHP 5.6 wrzucona na PrestaShop 8 z PHP 8.1 to najczęstsza przyczyna białej strony. Sprawdź w pliku modułu deklarowane wersje PHP i PS oraz datę ostatniej aktualizacji. Wymagania i strukturę modułu opisuje dokumentacja PrestaShop dla deweloperów.
• Brak cronów i kolejek maili. Zamówienie powstaje, ale potwierdzenie nie wychodzi — status zmieniasz ręcznie, klient dzwoni. Ustaw SMTP, uruchom crony (przypomnienia o koszyku, aktualizacje statusów) i sprawdź logi. Testuj na MailHog lub Mailtrap, nie na skrzynce klienta.
• Testy wyłącznie na danych przykładowych. Domyślny katalog to kilkanaście produktów bez kombinacji. Twoje 40 wariantów rozmiaru i koloru, rabaty ilościowe, ceny grupowe B2B i strefy podatkowe zachowują się inaczej.
• Mieszanie kluczy sandbox i produkcyjnych. Klucz produkcyjny obok sandboxowego w jednym pliku konfiguracyjnym to gotowy scenariusz na prawdziwe zamówienie w trakcie testów.
• Wdrożenie prosto na produkcji. Zmiana w motywie albo .htaccess bez środowiska staging nie ma jak się wycofać. Nawet w małym sklepie staging to 1–2 godziny pracy, które ratują weekend. Warto wcześniej przeczytać, co realnie chwalą i krytykują użytkownicy — nasze zestawienie opinii o PrestaShopie zbiera najczęstsze zarzuty.

Kiedy demo nie wystarczy – od testu do wdrożenia

Są momenty, w których demo przestaje wystarczać — i zwykle widać je po liście zadań, nie po liczbie produktów.

Sygnały, że czas na wsparcie:

• Migracja ze starej platformy: trzeba przenieść produkty, klientów i zamówienia, ustawić przekierowania 301 i pilnować, żeby przy kilku tysiącach zaindeksowanych adresów nie pojawiły się 404.
• Integracja z ERP: stany magazynowe, ceny i faktury muszą się zgadzać, a samo mapowanie pól to praca na kilkanaście godzin, nie na jedno popołudnie.
• Niestandardowy moduł płatności lub kuriera: gdy API wymaga podpisów, webhooków i własnych statusów zamówienia, gotowy moduł zwykle nie wystarczy.
• Sytuacja, w której nie ma kto utrzymać aktualizacji, backupów i monitoringu.

Jak pracuje DropDigital: wycenę podajemy w widełkach na podstawie liczby godzin — po krótkim audycie wiemy, co jest gotowe, a co trzeba napisać od zera. Rozmawiasz bezpośrednio z deweloperem, który robi wdrożenie, bez pośredników. Po starcie zostaje opieka: aktualizacje, backupy, monitoring i SLA z podziałem na awarie krytyczne oraz drobne zmiany.

Najczęściej zaczynamy od płatności i dostaw, bo tam wychodzi większość problemów po starcie — zobacz organizację wdrożenia Przelewy24 krok po kroku oraz konfigurację PayU, statusy i typowe błędy. Przy sklepie na istniejącej domenie dochodzą drobiazgi: gdzie zmienić logo PrestaShop i jaki rozmiar wgrać, a przy aktualizacjach — jak czytać wydania PrestaShop i kiedy aktualizować.

Punkt wyjścia do dalszej lektury to nasze wdrożenia PrestaShop — zakres usług, typowe projekty i to, czego po drodze pilnujemy.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Ustal cel wejścia na demo — Przed klikaniem zapisz, czy to 15–30 minut rekonesansu przed rozmową z wykonawcą, czy coś więcej. Demo nie udźwignie drugiego scenariusza.
• Sprawdź wersję instalacji demo — Zapisz numer wersji (1.7 vs 8.x/9.x) i porównaj z wersją planowaną dla sklepu — inny motyw, inne moduły, inne wymagania PHP.
• Zweryfikuj wymagania docelowej wersji — Zajrzyj do dokumentacji dla deweloperów i sprawdź wymagane wersje PHP i MySQL, zanim porównasz je z ofertą hostingu.
• Wejdź do back office — Dane logowania publikowane są na bieżącej stronie oficjalnego demo. Nie korzystaj z loginów z poradników i postów — najczęściej są nieaktualne.
• Obejrzyj listę produktów — Sprawdź filtry, sortowanie, akcje masowe i to, jak dużo kolumn da się pokazać bez przewijania w poziomie.
• Obejrzyj edycję produktu z kombinacjami — Najwięcej czasu w panelu spędzisz na kartach produktów z wariantami — sprawdź, czy logika rozmiarów, kolorów i cen jest dla Ciebie czytelna.
• Wejdź w szczegóły zamówienia — Zobacz, gdzie zmienia się status, gdzie są faktury i historia wiadomości. To ekran, który będzie codziennie używany przy obsłudze zamówień.
• Sprawdź metody płatności i dostawy — Obejrzyj samą konfigurację i liczbę pól do wypełnienia. Nie oceniaj integracji na podstawie demo — brak kluczy produkcyjnych.
• Zajrzyj w ustawienia wydajności i cache — Zobacz, jakie opcje są dostępne, i zapisz je jako listę do omówienia z wykonawcą przy konfiguracji własnego środowiska.
• Nie wpisuj żadnych danych osobowych — Ani przy zakładaniu konta, ani w zamówieniu, ani w formularzu kontaktowym. Demo to środowisko publiczne.
• Nie buduj katalogu na demo — Dane są cyklicznie resetowane. Jeśli po resecie zniknęły Twoje produkty, to nie błąd platformy, tylko sposób działania demo.
• Przetestuj zamówienie z otwartymi oczami — Sprawdź ścieżkę od koszyka do potwierdzenia, ale nie licz na maile transakcyjne — na demo są zwykle wyłączone lub nie dochodzą.
• Zapisz pytania do wykonawcy — Zamknij rekonesans listą konkretów: import katalogu, integracje, wielojęzyczność, dostęp do logów. To materiał na rozmowę, nie na decyzję.
• Zdecyduj o własnym środowisku — Wybierz wariant: subdomena testowa na hostingu, lokalnie na Dockerze/XAMPP albo staging u wykonawcy. Ustal, kto ma dostęp i gdzie leży kopia bazy.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów