Wdrożenie PrestaShop i migracja na PrestaShop to dwie różne decyzje — pierwsza dotyczy sklepu, którego jeszcze nie ma, druga przeniesienia działającego biznesu na inną platformę. Zanim wybierzesz, sprawdź trzy liczby: liczbę SKU, liczbę integracji (ERP, kurierzy, płatności) i liczbę rynków językowych. Jeśli obecny sklep ma problemy z wydajnością i brakami w integracjach, ale katalog i logika biznesowa są zdrowe, tańsza bywa optymalizacja, nie migracja. Poniżej znajdziesz organizacyjną stronę procesu: etapy, podział odpowiedzialności, typowe błędy, listę kontrolną i realne widełki czasowe.
Decyzję najprościej oprzeć na trzech liczbach: liczba SKU, liczba integracji i liczba wersji językowych. Sklep B2C z 300 SKU, jedną walutą i jednym operatorem płatności to inny projekt niż hurtownia z 12 000 SKU, cennikami dla grup klientów i plikiem XML z ERP wysyłanym co 15 minut. Pierwszy zwykle zmieści się w standardowym wdrożeniu, drugi wymaga osobnego etapu integracji i dłuższego budżetu.
Sygnały, że obecny sklep zaczyna ograniczać rozwój — konkretne, nie „odczucia":
Jeśli katalog i logika biznesowa są zdrowe — produkty mają poprawne SKU, ceny i stany — tańsza bywa optymalizacja: PHP 8.x, włączony cache, konwersja zdjęć do WebP, przebudowa bazy i indeksów. Migracja przenosi te same problemy na nowy serwer, tylko z dodatkową fakturą za przenosiny. Zakres prac porównasz w opisie usługi wdrożenia PrestaShop.
Wdrożenie od zera ma sens, gdy sklepu jeszcze nie ma albo obecne rozwiązanie nie jest rozwijane i nie da się na nim uruchomić potrzebnych integracji. Migrację wybieraj wtedy, gdy platforma nie obsługuje modelu sprzedaży (np. cenników B2B, wielu magazynów) i nie da się tego nadrobić modułem.
| Typ firmy | Typowy katalog | Co przesądza o wyborze |
|---|---|---|
| B2C, detal | 200–2 000 SKU, 1 język | Zwykle wdrożenie standardowe; migracja tylko przy zmianie platformy |
| B2B / hurt | 2 000–50 000 SKU, cenniki grupowe | Integracja z ERP i logika cen — licz szersze wdrożenie |
| Sprzedaż wielorynkowa | 1 000+ SKU, 2–5 języków | Multistore albo osobne sklepy; migracja wielu katalogów |
Standardowe wdrożenie da się rozłożyć na siedem etapów. Każdy kończy się efektem do sprawdzenia, więc wiesz, za co płacisz w danym tygodniu.
Po stronie klienta zostają cztery rzeczy, których wykonawca nie zrobi za niego: decyzje (jedna osoba zatwierdzająca), treści i zdjęcia, dostępy do systemów oraz testy akceptacyjne. Opóźnienie w tych czterech punktach odpowiada za większość przesunięć terminów — dlatego organizację procesu w konkretnym mieście opisujemy osobno: wdrożenia i migracje PrestaShop w Toruniu. Realny czas: 2–6 tygodni dla standardu i 6–12 tygodni przy rozbudowanych integracjach.
| Etap | Typowy czas | Kto odpowiada |
|---|---|---|
| Audyt i cele | 3–5 dni | Wykonawca + decydent klienta |
| Staging | 1–2 dni | Wykonawca |
| Konfiguracja | 3–7 dni | Wykonawca, treści — klient |
| Integracje | 1–6 tygodni | Wykonawca, dostępy — klient |
| Migracja danych | 2–10 dni | Wykonawca, eksport z klienta |
| Testy akceptacyjne | 3–7 dni | Klient + wykonawca |
| Go-live i monitoring | 1–2 dni + 30 dni opieki | Wykonawca |
Migracja to nie kopiowanie bazy, tylko tłumaczenie jednego modelu danych na drugi. Część rzeczy przenosi się wprost, część trzeba zmapować, a część zostawić za sobą.
1:1 przenosisz: kategorie i produkty, kombinacje (rozmiar, kolor), zdjęcia, opisy, klientów, historię zamówień, grupy klientów, reguły rabatowe oraz strony CMS (regulamin, polityka prywatności, dostawa).
Wymaga mapowania: stare identyfikatory kategorii i produktów, statusy zamówień, metody płatności i dostawy („przelew" w starym sklepie ≠ ta sama metoda w nowym), waluty i podatki. Najważniejsze: każdy stary adres URL musi mieć odpowiednik. Listę przekierowań 301 robisz ze starych adresów na nowe i wdrażasz razem z go-live — bez tego tracisz pozycje i ruch z linków zewnętrznych.
Kolejność ma znaczenie: najpierw dane słownikowe (kraje, waluty, podatki, statusy, grupy klientów, kategorie), potem produkty ze zdjęciami i cenami, na końcu klienci i zamówienia. Odwrotna kolejność kończy się zamówieniami bez produktów i klientami bez grup.
Czego nie kopiować bezrefleksyjnie: starych meta title i description (jeśli są duplikatami albo zlepkiem słów kluczowych), nieużywanych modułów i ich tabel, pustych pól, starych logów i porzuconych koszyków. Nie przenosisz też haseł w formie jawnej — jeśli sklep nie pozwala przenieść hashy, zaplanuj reset hasła mailem.
Typowe pułapki: duplikaty SKU przy imporcie, znaki specjalne i średniki rozsypujące plik CSV, brakujące zdjęcia w wariantach. Punkt wyjścia do decyzji o platformie masz w sekcji PrestaShop. Warto też zadbać, by po migracji dane produktów były zgodne z wytycznymi Google dotyczącymi danych strukturalnych.
| Dane | Tryb przenoszenia | Na co uważać |
|---|---|---|
| Produkty i kombinacje | 1:1 | Duplikaty SKU, ceny netto/brutto, atrybuty |
| Zdjęcia | 1:1 | Nazwy plików, przypisanie do kombinacji |
| Kategorie | 1:1 + mapowanie ID | Drzewo kategorii, kolejność, meta |
| Klienci | 1:1 + mapowanie grup | Hasła (hash lub reset), zgody marketingowe |
| Zamówienia | 1:1 + mapowanie statusów | Historia płatności, faktury, daty |
| Adresy URL | Mapowanie + 301 | Pełna lista starych adresów, brak łańcuchów przekierowań |
Wycena bez audytu to zgadywanie. Różnica między cennikiem „z sufitu” a wyceną po audycie bywa dwukrotna — dotyczy tego samego sklepu, tylko w pierwszym przypadku nikt nie sprawdził katalogu, modułów ani integracji. Audyt to eksport produktów, lista wtyczek, wersja PrestaShop, stan bazy i konfiguracja płatności. Dopiero po nim liczysz godziny.
Realne widełki: wdrożenie nowego sklepu 40–120 godzin, migracja standardowa z innej platformy 30–80 godzin. Przykład: sklep z 300 SKU, jedną walutą, InPostem i Przelewy24 zamyka się w ok. 45 godzinach. Firma z 8000 SKU, Subiektem GT, trzema językami i cennikami grupowymi B2B — 110–120 godzin i to bez treści produktowych. Stawki za pracę nad PrestaShop na polskim rynku mieszczą się najczęściej w przedziale 90–200 zł netto/h; wyższa stawka wymaga uzasadnienia zakresem, nie „doświadczeniem zespołu”.
Do budżetu doliczasz koszty, które nie są godzinami programisty:
Pakiety porządkują rozmowę, ale nie zastępują audytu. Jeśli chcesz porównać zakresy, zobacz nasze wdrożenia PrestaShop i opis organizacji wdrożeń i migracji PrestaShop w Toruniu.
| Pakiet | Zakres | Orientacyjnie |
|---|---|---|
| Start | Nowy sklep, 1 język, 1 kurier, 1 bramka płatności, standardowy szablon | 40–60 h |
| Rozwój | Migracja lub rozbudowa, wiele kategorii, moduły, drugi język, optymalizacja | 60–100 h |
| Integracje niestandardowe | ERP, magazyn, B2B, cenniki grupowe, własne API | 80–120 h i więcej |
Najwięcej czasu nie zjadają szablony, tylko integracje. Każda ma własne API, własne limity i własne sposoby na błędy.
Kurierzy. InPost działa przez ShipX API: tworzenie przesyłek, etykiety PDF, wybór punktu odbioru (Geowidget lub Points API). DPD i DHL mają odrębne API — DPD przez WebAPI, DHL przez DHL24. Kluczowe nie jest samo generowanie etykiet, ale statusy: bez webhooków albo crona odpytywanego co 15–30 minut zamówienia zostają w stanie „wysłane” na zawsze, a klient dzwoni na infolinię. Wybór punktu odbioru w checkout musi być odporny na brak odpowiedzi API — inaczej blokuje całą płatność.
Płatności. Przelewy24, PayU, Stripe, BLIK (jako metoda w P24/PayU albo osobny konektor), płatności odroczone. Trzy typowe pułapki: brak obsługi webhooka, czyli zamówienia bez potwierdzenia wpłaty; brak testów w sandboxie na kwotach z groszami; brak obsługi zwrotów i zwrotów częściowych. Statusy zamówień w PrestaShop muszą odpowiadać temu, co zwraca operator — inaczej do ERP trafiają zamówienia, które nigdy nie zostały opłacone.
ERP i magazyn. Subiekt GT/nexo, Comarch Optima, WF-Mag, Baselinker — każdy ma inny model danych. Mapujesz SKU na indeks, stany, ceny, zamówienia i faktury. Synchronizacja co 5 minut wymaga kolejki i logu błędów, a przy dwóch kanałach sprzedaży dochodzą rezerwacje, żeby nie sprzedać tej samej sztuki dwa razy.
Własny moduł zamiast kolejnej płatnej wtyczki ma sens przy nietypowej logice — np. cenniku B2B liczonym od wielkości zamówienia. Licencja to zwykle 300–1500 zł/rok, ale dochodzi utrzymanie przy aktualizacjach. Ryzyko uzależnienia działa w obie strony: dostawca wtyczki może zniknąć, a własny moduł bez dokumentacji blokuje każdy upgrade. Punkt startowy to moduły i rozbudowa sklepu na PrestaShop oraz dokumentacja dla deweloperów PrestaShop.
| Obszar | Typowy czas pracy | Najczęstsza pułapka |
|---|---|---|
| Kurier i punkty odbioru | 8–20 h | Brak zwrotnych statusów przesyłek |
| Bramka płatności i BLIK | 6–16 h | Brak testu webhooka i zwrotów |
| ERP lub magazyn | 20–60 h | Duplikacja stanów przy dwóch kanałach |
| Własny moduł | 20–80 h | Brak dokumentacji, utrudnione aktualizacje |
Migracja bez mapy przekierowań to najczęstszy sposób na utratę ruchu. Zbierz adresy z Google Search Console (Wydajność → Strony), z logów serwera i z sitemap.xml starego sklepu. Potem zrób tabelę „stary URL → nowy URL”. Zasady: jedno przekierowanie 301, bez łańcuchów (A→B→C spowalnia i gubi sygnały), bez przekierowań kończących się na 404. Przy zmianie struktury kategorii przekieruj też stare kategorie, nie tylko produkty.
Canonicale muszą wskazywać na wersję bez parametrów filtrowania — PrestaShop generuje wiele adresów dla tego samego produktu i bez tego Google indeksuje duplikaty. W robots.txt zablokuj koszyk, wyszukiwarkę wewnętrzną i parametry fasetowe; sitemap XML zgłoś osobno dla każdej wersji językowej. Stronę 404 zrób użyteczną — z wyszukiwarką i linkami do kategorii. Przekierowanie 404 na stronę główną to soft 404 i Google raportuje to jako błąd.
Core Web Vitals mierzy się w 75. percentylu: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. W PrestaShop najwięcej daje cache Smarty, OPcache i Redis, obrazy w WebP lub AVIF z lazy loadingiem poza pierwszym ekranem oraz CDN. Atrybuty width i height przy obrazach to najprostszy sposób na uratowanie CLS. Kompresję Brotli lub gzip warto zweryfikować w konfiguracji serwera — nie każdy hosting ma ją włączoną domyślnie. Metryki i progi opisuje web.dev – Web Vitals.
Monitoring: przed migracją zapisz dane w GSC (pokrycie indeksu, CWV, najpopularniejsze zapytania). Po migracji zweryfikuj nową wersję, obserwuj raport 404 przez 4–6 tygodni i porównuj tydzień do tygodnia, pamiętając o sezonowości — spadek w lipcu nie musi oznaczać błędu. Sprawdź też dane strukturalne produktów (Product, Offer, BreadcrumbList); po migracji często znikają. Całość prac prowadzimy w ramach wdrożeń i optymalizacji PrestaShop.
Dzień startu sklepu to początek pracy, nie koniec projektu. W pierwszym roku najwięcej zgłoszeń generują rzeczy, których nie da się przewidzieć w harmonogramie: zmiana w API kuriera, nowsza wersja PHP na serwerze, poprawka w module płatności po aktualizacji PrestaShop. Dlatego zasady opieki ustalasz przed wdrożeniem, z konkretnymi liczbami w umowie.
Backupy. Baza i pliki codziennie, retencja minimum 30 dni, kopia offsite w innej lokalizacji niż serwer produkcyjny — nie na tym samym VPS i nie na tym samym koncie hostingowym. Sam zrzut nic nie daje bez testu odtworzenia: raz na kwartał odtwarzasz kopię na stagingu i mierzysz czas. Dla sklepu z 5 000 SKU realny powrót do pracy to zwykle 30–90 minut, jeśli kopie są wykonywane mysqldumpem lub narzędziem do backupów przyrostowych, a nie „ręcznie, jak ktoś pamięta”.
Aktualizacje. PrestaShop, PHP i moduły wchodzą etapowo: najpierw staging, potem produkcja, w oknie poza szczytem sprzedaży. Przejście z 1.7 na 8.x to nie klik w 1-Click Upgrade, a mały projekt. Po każdej aktualizacji robisz checklistę: koszyk, trzy metody płatności, etykiety kurierskie, feed Ceneo i Google, szablony e-mail. Informacje o zmianach w API i cyklu wydań znajdziesz w dokumentacji dla deweloperów PrestaShop.
Monitoring. Uptime sprawdzany co minutę z alertem po dwóch nieudanych próbach, logi błędów PHP (poziom E_WARNING i wyżej), wolne zapytania (MySQL slow_query_log, long_query_time = 1 s), kolejka e-mail — alert, gdy wiadomość czeka dłużej niż 15 minut. Bez tego o awarii dowiesz się od klienta, który nie dostał potwierdzenia zamówienia.
SLA zapisujesz rozdzielnie: czas reakcji (potwierdzenie i start diagnozy) oraz czas naprawy, osobno dla awarii krytycznej i zwykłego zgłoszenia. Do tego kanały przyjmowania zgłoszeń i limit godzin w abonamencie. Zakres takiej opieki opisujemy przy okazji wdrożeń PrestaShop.
| Element | Zalecenie | Po co |
|---|---|---|
| Backup bazy i plików | Codziennie, retencja 30 dni | Powrót do stanu sprzed zmiany treści lub modułu |
| Kopia offsite | Inny region/lokalizacja, szyfrowana | Awaria hostingu nie zabiera wszystkich kopii |
| Test odtworzenia | Raz na kwartał, na stagingu, z pomiarem czasu | Sprawdzasz, czy backup da się w ogóle podnieść |
| Aktualizacje | Raz w miesiącu, staging → produkcja | Mniej niespodzianek po automatycznej aktualizacji |
| Monitoring uptime | Co 1 min, alert po 2 nieudanych próbach | Reakcja przed pierwszą reklamacją klienta |
| Monitoring błędów PHP | Alert na nowy typ błędu | Wyłapujesz błędy z modułów, nie z ruchu |
| Kolejka e-mail | Alert powyżej 15 min oczekiwania | Zamówienia nie giną bez potwierdzenia |
| Czas reakcji P1 | Do 4 h w godzinach 8:00–16:00 | Sklep nie przyjmuje zamówień = strata w godzinach |
| Czas naprawy P1 | Do 8 h roboczych | Wiesz, kiedy eskalujesz i szukasz obejścia |
Pytania zadaj przed podpisaniem umowy i najlepiej w formie pisemnej — odpowiedzi w ofercie stają się punktem odniesienia, gdy pojawia się spór o zakres. Poniżej dziesięć, które najszybciej oddzielają partnera od pośrednika sprzedającego cudzą pracę.
Czerwone flagi: brak dostępu do repozytorium, brak stagingu, cena o 40% niższa od pozostałych ofert, brak jakiegokolwiek zapisu o czasie reakcji, faktura za „prace wdrożeniowe” bez rozbicia na etapy. Kontekst techniczny i zakres PrestaShop dla firm warto porównać z tym, co obiecuje wykonawca, a realia organizacyjne projektu w Toruniu opisujemy w osobnej sekcji.
| Model wyceny | Kiedy pasuje | Na co uważać |
|---|---|---|
| Stała cena za zamknięty zakres | Masz opisany zakres, znany katalog i integracje | Zmiany w trakcie zwykle płatne dodatkowo — ustal stawkę z góry |
| Rozliczenie godzinowe | Zakres jest ruchomy, np. migracja z nieudokumentowanego sklepu | Poproś o tygodniowy raport godzin i limit budżetu |
| Model mieszany: etapy stałe + godziny | Wdrożenie bazowe plus prace rozwojowe | Zapisz, które etapy są stałe, a które rozliczane godzinowo |
| Abonament na opiekę | Sklep działa i potrzebuje SLA oraz aktualizacji | Sprawdź, czy godziny przechodzą na kolejny miesiąc i jaki jest limit |
Start migracji bez pełnej kopii bazy i plików oraz bez planu wycofania (rollback) na wypadek nieudanego go-live.
Jak wykryć: Zapytaj wykonawcę, gdzie leży kopia, z jakiego dnia i w jakim czasie można wrócić do starej wersji sklepu. Brak konkretnej odpowiedzi to czerwona flaga.
Jak naprawić: Ustal przed startem: snapshot bazy i katalogu plików, punkt przywrócenia, osobny adres stagingu i procedurę przełączenia DNS z powrotem w ciągu maksymalnie kilkudziesięciu minut.
Migracja produktów przed danymi słownikowymi — kategoriami, producentami, atrybutami i grupami klientów.
Jak wykryć: Po imporcie produktów pojawiają się produkty bez kategorii, duplikaty atrybutów (np. „rozmiar” i „Rozmiar”) oraz puste przypisania producentów.
Jak naprawić: Zachowaj kolejność: najpierw dane słownikowe, potem produkty i zdjęcia, na końcu klienci i zamówienia. Po każdym etapie zrób kontrolę liczby rekordów i losową próbę 20–30 pozycji.
Brak mapy przekierowań 301 ze starych URL-i na nowe. Stare adresy kategorii i produktów zwracają 404 po go-live.
Jak wykryć: Weź listę 50 najczęściej odwiedzanych adresów z Google Search Console i sprawdź je po wdrożeniu — każdy powinien zwrócić 200 lub 301, nie 404.
Jak naprawić: Zrób eksport starych URL-i (z sitemap i z GSC), przypisz im nowe adresy i wgraj reguły 301 przed uruchomieniem nowej wersji. Przekierowania jednopoziomowe, bez łańcuchów.
Kopiowanie 1:1 tego, co w starym sklepie było śmieciem: nieaktualne meta, nieużywane moduły, puste pola, zdublowane opisy producentów.
Jak wykryć: W eksporcie widać setki produktów z identycznym meta description, kategoriami technicznymi albo modułami, których nikt nie umie wskazać palcem na froncie.
Jak naprawić: Zrób audyt treści przed migracją: wyłącz produkty nieaktywne z oferty, popraw meta dla TOP 100 fraz, nie przenoś modułów, które nie mają właściciela i celu biznesowego.
Go-live bez testów płatności, e-maili transakcyjnych i integracji kurierskich na realnych danych.
Jak wykryć: Po wdrożeniu pierwsze zamówienie nie generuje etykiety, potwierdzenie nie dochodzi na skrzynkę, a status w panelu płatności nie zmienia się na „opłacone”.
Jak naprawić: Zrób testowe zamówienie na każdą metodę płatności i każdego kuriera, sprawdź skrzynkę nadawczą (SPF, DKIM, DMARC) i przejście statusu zamówienia przez cały proces. Dopiero potem otwierasz sklep dla ruchu.
Brak właściciela decyzji po stronie firmy i brak dostępów — wdrożenie stoi tygodniami na pytaniach o treści i hasła.
Jak wykryć: Pytania do klienta wracają po 5–7 dniach, dostępy przekazywane są na prywatne skrzynki, a decyzje o zakresie podejmuje kilka osób jednocześnie.
Jak naprawić: Ustal jedną osobę decyzyjną po stronie klienta, jeden kanał komunikacji i jeden dokument z dostępami przekazanymi bezpiecznie przed startem prac.
Wdrożenie to budowa sklepu od podstaw, migracja to przeniesienie działającego biznesu — mieszanie tych dwóch decyzji prowadzi do przepłacenia albo do utraty ruchu. Kluczowe są trzy liczby: SKU, integracje i rynki, oraz uporządkowana kolejność przenoszenia danych. Bez mapy przekierowań 301, testów płatności i monitoring po go-live nawet dobrze wykonany projekt potrafi kosztować widoczność w Google. Realne widełki to 40–120 godzin na wdrożenie i 30–80 godzin na migrację standardową, a wycena zawsze powinna wynikać z audytu, nie z cennika z sufitu.
Wdrożenie ma sens, gdy sklepu jeszcze nie ma albo obecny nie spełnia podstawowych wymagań biznesowych — brak integracji z ERP, brak obsługi B2B, brak wielu języków. Migracja jest uzasadniona, gdy katalog i procesy są zdrowe, ale platforma ogranicza rozwój. Jeśli problemem jest tylko szybkość strony i kilka brakujących integracji, w pierwszej kolejności policz koszt optymalizacji obecnego sklepu — często jest niższy niż pełne przejście.
Standardowe wdrożenie, bez nietypowych integracji, zamyka się zwykle w 2–6 tygodniach. Projekty z rozbudowanymi integracjami (ERP, magazyn, wiele rynków językowych) trwają 6–12 tygodni. Na czas wpływa nie tylko praca wykonawcy, ale też tempo decyzji i przekazywania treści po stronie klienta.
Bez zmian przenoszą się zwykle produkty, kategorie, zdjęcia i treści CMS, o ile struktura docelowa je przewiduje. Mapowania wymagają: stany magazynowe i ceny z ERP, grupy klientów i rabaty, statusy zamówień oraz stare URL-e. Klienci i zamówienia trafiają na końcu, po produktach — inaczej historie zamówień nie mają do czego się podpiąć.
Podstawa to mapa przekierowań 301 przygotowana przed go-live, poprawne canonicale, nowa sitemap XML i wyłączone indeksowanie stagingu. Po uruchomieniu monitoruj Google Search Console przez pierwsze 2–4 tygodnie i reaguj na błędy 404. Równolegle zadbaj o wydajność — metryki LCP, INP i CLS opisuje dokumentacja web.dev oraz Google Search Central.
Realistyczne widełki to 40–120 godzin na wdrożenie i 30–80 godzin na standardową migrację. Do tego dochodzą koszty poza godzinami: hosting lub VPS, SSL, płatne moduły, integracje, treści i migracja skrzynki e-mail. Wycena po audycie różni się od cennika „z sufitu” tym, że ma zakres i założenia — dzięki temu wiadomo, co jest w cenie, a co jest zmianą zakresu.
Gdy sklep generuje zamówienia, katalog jest uporządkowany, a problemy dotyczą wydajności, kilku brakujących integracji albo konfiguracji SEO. Migracja zawsze oznacza ryzyko przejściowego spadku ruchu i zaangażowanie zespołu po obu stronach. Jeżeli obecna platforma nie blokuje kluczowych procesów, optymalizacja bywa lepszym krokiem na najbliższe 6–12 miesięcy.
Jedna osoba decyzyjna, która rozstrzyga sporne kwestie zakresu i treści, oraz osoba odpowiedzialna za dane produktowe. Do tego dostępy: hosting, DNS, panel płatności, ERP i skrzynka e-mail. Wykonawca odpowiada za proces, konfigurację i testy techniczne, ale testy akceptacyjne i decyzje biznesowe zostają po stronie firmy.
Jeśli chcesz wiedzieć, czy w Twoim przypadku lepsze będzie wdrożenie, migracja, czy najpierw optymalizacja obecnego sklepu, opisz krótko sytuację — liczbę SKU, integracje i platformę. Zakres wdrożeń i migracji PrestaShop znajdziesz na stronie wdrożeń PrestaShop oraz w dziale PrestaShop.