---
type: "blog"
id: 23
url: "https://prestadev.pl/pl/blog/baza-wiedzy/aktualizacja-prestashop-przygotowanie-do-wyceny"
markdown_url: "https://prestadev.pl/pl/markdown/blog/23.md"
title: "Aktualizacja PrestaShop: co sprawdzić przed wyceną?"
description: "Co przygotować do wyceny aktualizacji PrestaShop? Wersje, motyw, moduły, integracje, kopia testowa i plan powrotu. Praktyczna tabela inwentaryzacji."
language: "pl"
published: "2026-09-13 20:06:03"
updated: "2026-09-26 20:07:36"
author: "Patryk Marek"
category: "Baza wiedzy"
---

# Aktualizacja PrestaShop: co sprawdzić przed wyceną?

Numer wersji sklepu to początek. Spisz motyw, integracje i własne zmiany, aby uzgodnić zakres aktualizacji, kryteria odbioru oraz plan przełączenia.

**Do rzetelnej wyceny aktualizacji PrestaShop potrzebne są pełna wersja sklepu, środowisko serwera, motyw, kluczowe moduły i opis własnych zmian.** Sam numer wersji nie określa zakresu pracy. Dwa sklepy na tej samej wersji mogą wymagać zupełnie innego przygotowania, jeśli jeden korzysta ze standardowych funkcji, a drugi ma zmodyfikowany checkout, integrację magazynową i własne reguły cen.

 ![Plan aktualizacji sklepu PrestaShop, inwentaryzacja i nośnik kopii zapasowej](https://prestadev.pl/modules/ph_simpleblog/featured/23.jpg) Ten poradnik pomaga przygotować zapytanie o aktualizację oraz uzgodnić kryteria odbioru. Nie jest instrukcją uruchomienia aktualizatora bez wcześniejszej kopii i sprawdzenia zależności.

 ## Wersja PrestaShop i PHP muszą tworzyć wspierany zestaw

 Zapisz pełne oznaczenie obecnej i planowanej wersji sklepu. Sprawdź PHP obsługujące witrynę oraz PHP używane przez CRON i polecenia konsolowe. Hosting może udostępniać różne wersje dla tych sposobów uruchamiania. Zmiana ustawienia w panelu domeny nie musi zmienić interpretera używanego przez zadania cykliczne.

 W dokumentacji sprawdzonej 13 września 2026 PrestaShop 9.0 obsługuje PHP 8.1–8.4, a PrestaShop 9.1 — PHP 8.1–8.5. Zalecane wersje PHP również różnią się między tymi gałęziami. To przykład, dlaczego informacja „obsługuje PrestaShop 9” jest niewystarczająca przy doborze środowiska. Źródło: [oficjalne wymagania PrestaShop 9](https://devdocs.prestashop-project.org/9/basics/installation/system-requirements/).

 Wspierane środowisko samego silnika sklepu nie potwierdza jeszcze zgodności motywu ani modułów. Przed podniesieniem PHP sprawdź także ich wymagania, rozszerzenia serwera, limity pamięci i sposób wykonywania integracji. Nie zaczynaj od zmiany PHP na produkcji tylko dlatego, że nowszy numer wygląda korzystniej.

 ## Inwentaryzacja: zacznij od funkcji krytycznych

 Lista wszystkich modułów jest przydatna, ale wykonawca powinien przede wszystkim wiedzieć, które funkcje utrzymują codzienną sprzedaż. Wskaż płatności, dostawy, punkty odbioru, fakturowanie, magazyn, importy cen i stanów, rezerwacje oraz specjalne reguły B2B. Dodaj informację, kto utrzymuje każdą integrację.

 | Obszar | Co podać | Dlaczego wpływa na zakres |
| --- | --- | --- |
| Sklep | Obecna wersja, planowana wersja, liczba sklepów i języków. | Określa ścieżkę aktualizacji i zakres kontroli danych. |
| Hosting | PHP strony i CRON, baza danych, dostępna przestrzeń, możliwość utworzenia kopii. | Pozwala zaplanować środowisko i operacje na plikach. |
| Motyw | Nazwa, wersja, motyw potomny, własne szablony i skrypty. | Zmiany wyglądu mogą wymagać przeniesienia lub odtworzenia. |
| Zakup | Checkout, płatności, dostawy, punkty odbioru, pola firmowe. | Wyznacza scenariusze wymagające odbioru przed przełączeniem. |
| Integracje | Systemy zewnętrzne, kierunki wymiany, częstotliwość i właściciele połączeń. | Ujawnia zależności wykraczające poza sam sklep. |
| Własny kod | Override, zmiany w plikach silnika, moduły dedykowane, dokumentacja. | Pozwala ocenić, co należy dostosować lub zastąpić. |
| Operacje sklepu | Godziny sprzedaży, dopuszczalne okno prac, osoby do odbioru. | Wpływa na plan przełączenia i dostępność zespołu. |

 Na etapie pierwszego kontaktu wystarczą informacje techniczne i opis procesu. Haseł, kluczy API ani danych klientów nie wpisuj do ogólnodostępnego dokumentu. Jeśli potrzebny będzie dostęp do kopii, uzgodnij sposób jego przekazania i zakres uprawnień.

 ## Co zostaje, co aktualizujemy, a co wymieniamy?

 Każdy ważny element powinien dostać decyzję oraz jej uzasadnienie. „Zostaje” oznacza potwierdzoną przydatność w planowanej konfiguracji. „Do sprawdzenia” jest poprawnym statusem przed analizą; udawana pewność utrudnia wycenę i późniejszy odbiór.

 | Element przykładowego sklepu | Decyzja robocza | Warunek potwierdzenia |
| --- | --- | --- |
| Motyw z dostępną wersją dla nowego sklepu | Aktualizujemy. | Sprawdzenie licencji i przeniesienia własnych szablonów. |
| Moduł płatności z deklarowanym wsparciem | Aktualizujemy i testujemy. | Zamówienie, potwierdzenie operatora, anulowanie i ponowienie. |
| Własna reguła cen w override | Do sprawdzenia. | Odnalezienie kodu i odtworzenie przykładów obliczeń. |
| Porzucony moduł bez aktualizacji | Rozważamy wymianę. | Ustalenie potrzebnej funkcji i przeniesienia jej danych. |
| Zewnętrzny system magazynowy | Zostaje jako system, połączenie do sprawdzenia. | Weryfikacja API, mapowania identyfikatorów i obsługi kolejki. |

 Nie oceniaj modułu wyłącznie po tym, czy daje się zainstalować. Instalacja nie potwierdza obliczania rabatu, zapisu punktu odbioru ani zakończenia komunikacji z magazynem. Podobnie poprawna strona główna nie jest dowodem poprawnej aktualizacji sklepu.

 ## Własne zmiany: największe ryzyko bywa niewidoczne w panelu

 Zapytaj osoby utrzymujące sklep o modyfikacje, które powstały przez lata: dodatkowe pola, nietypowe statusy zamówień, zmiany ceny, wyłączenia przewoźników czy specjalne eksporty. Część może istnieć poza modułami widocznymi w panelu.

 Przydatny jest krótki opis zachowania: „dla tej grupy klientów cena liczy się tak”, „te produkty wykluczają tego przewoźnika”, „po tym statusie wysyłamy dokument do systemu”. Z takiego opisu da się przygotować próbę odbiorczą. Sama nazwa pliku override nie wyjaśnia jego znaczenia biznesowego.

 Odtworzenie brakującej funkcji może wymagać osobnej pracy. Powinno być rozpoznane w zakresie lub jawnie oznaczone jako zależność do wyjaśnienia, zamiast pojawiać się dopiero po przełączeniu sklepu.

 ## Kopia testowa i kryteria odbioru

 Aktualizację najpierw przeprowadza się na kopii z kontrolowanymi integracjami. Przygotowanie kopii obejmuje również ochronę dostępu, zatrzymanie produkcyjnych wysyłek oraz rozdzielenie konfiguracji zewnętrznych usług. Kopia ma umożliwić próbę procesu, a nie nieświadomie powielać działanie sklepu produkcyjnego.

 Oficjalny [przewodnik aktualizacji z panelu](https://devdocs.prestashop-project.org/9/basics/keeping-up-to-date/update/update-from-the-back-office/) opisuje obsługę narzędzia aktualizującego. Zakres odbioru powinien dodatkowo odzwierciedlać funkcje sklepu; punktem odniesienia jest [lista kontroli po aktualizacji](https://devdocs.prestashop-project.org/9/basics/keeping-up-to-date/update/post-update-checklist/).

 - Porównaj wybrane produkty, kombinacje, ceny i stany.
- Sprawdź konto klienta, koszyk, adresy oraz ważne metody dostawy i płatności.
- Skontroluj wynik zamówienia w panelu i w systemach, do których powinno trafić.
- Uruchom kontrolowane próby importów, eksportów i zadań CRON.
- Porównaj istotne adresy, canonicale, przekierowania, wersje językowe i mapy witryny.
- Zapisz błędy, decyzje i warunki akceptacji, a nie tylko ogólne „testy zakończone”.

 Dokładniejszą kartę kontroli zakupu znajdziesz w poradniku [o zmianie checkoutu](https://prestadev.pl/pl/blog/baza-wiedzy/one-page-checkout-prestashop-co-sprawdzic). Przy pracach nad adresami wykorzystaj również istniejący tekst [o zachowaniu starych linków i przekierowaniach](https://prestadev.pl/pl/blog/baza-wiedzy/czyste-url-prestashop-usuwanie-id-przekierowania).

 ## Plan przełączenia i powrotu musi uwzględniać nowe zamówienia

 Przed pracami ustal moment wykonania końcowej kopii plików i bazy, sposób ograniczenia zmian danych oraz kolejność zatrzymania i wznowienia integracji. Wyznacz osobę podejmującą decyzję o uruchomieniu sklepu i warunki, przy których wracacie do poprzedniej wersji.

 Powrót do kopii sprzed aktualizacji może usunąć z bieżącej bazy zamówienia lub zmiany zapisane później. Dlatego backup bez ustalonego punktu odtworzenia nie jest kompletnym planem awaryjnym. Trzeba uwzględnić również płatności, które mogą zostać potwierdzone z opóźnieniem, i dane wysłane do systemów zewnętrznych.

 Zasady przygotowania kopii omawia [dokumentacja kopii zapasowej PrestaShop](https://devdocs.prestashop-project.org/9/basics/keeping-up-to-date/backup/). Dla konkretnego sklepu określ dodatkowo, kto sprawdził możliwość odtworzenia i jak będą uzgadniane zmiany powstałe podczas prac. Nie zakładaj z góry aktualizacji bez przestoju.

 ## Z czego składa się wycena?

 Wycena może obejmować analizę i inwentaryzację, przygotowanie kopii, właściwą aktualizację, dostosowanie kodu i motywu, testy, przełączenie oraz wsparcie po uruchomieniu. Osobno należy wskazać licencje, płatne aktualizacje zewnętrznych modułów i funkcje wymagające odtworzenia.

 Poproś o jasny zakres, zależności i kryteria zakończenia. Stała cena ma sens dla rozpoznanej pracy; przy nieznanych modyfikacjach przydatny może być najpierw etap analizy. Nie ma jednej uczciwej kwoty dla każdego sklepu oznaczonego „PrestaShop 1.7” lub „PrestaShop 8”.

 **Przygotuj wersję sklepu, nazwę motywu i listę kluczowych integracji.** Na tej podstawie można zacząć planować [aktualizację sklepu PrestaShop](https://prestadev.pl/pl/content/10-aktualizacja-sklepu-prestashop), określić potrzebne sprawdzenia i przygotować zakres, który da się rozliczyć.

 Weryfikacja merytoryczna: 13 września 2026. Wymagania wersji sprawdzono w dokumentacji PrestaShop. Macierz decyzji jest przykładowa; docelową ścieżkę i zgodność integracji ustala się dla konkretnego sklepu.

  ## Edytowalny arkusz przygotowania aktualizacji

 Do przygotowania wyceny i odbioru możesz wykorzystać [pakiet czterech arkuszy CSV z wypełnionym przykładem](https://prestadev.pl/themes/warehouse/assets/img/pdseo-20260926-aktualizacja-prestashop-arkusze.zip). Pliki otworzysz w Excelu lub LibreOffice; zawierają nagłówki UTF-8 i separator średnika. W ZIP są osobne szablony oraz osobne przykłady, więc nie trzeba usuwać demonstracyjnych danych z własnej inwentaryzacji.

 - **Środowisko:** wersje, motyw, multistore i własne zmiany.
- **Funkcje krytyczne:** właściciel, wersja, źródło informacji, zależność i decyzja.
- **Odbiór:** scenariusz, oczekiwany wynik, rezultat próby oraz dowód.
- **Przełączenie i powrót:** kopia, odpowiedzialność, warunki decyzji i sposób zabezpieczenia danych powstałych po przełączeniu.

 Przykład pokazuje zależność: zmiana szablonu koszyka wymaga sprawdzenia wyboru przewoźnika, zapisu punktu odbioru i widoczności tych danych w zamówieniu. Jest to demonstracja organizacji testu, a nie deklaracja zgodności konkretnego zestawu modułów. Stan „do sprawdzenia” pozostaje taki do czasu testu danej wersji.

 Przy planowaniu powrotu nie wystarczy wpisać „przywrócić backup”. Ustal, co stanie się z nowymi zamówieniami, płatnościami i zmianami stanów, które pojawiły się po przełączeniu. Arkusz zawiera osobne miejsce na tę decyzję.