Instalacja i konfiguracja

Zrozumienie uprawnień plików w systemie Linux

Każdy plik i katalog na serwerze Linux ma trzy zestawy uprawnień: jeden dla właściciela (owner), jeden dla grupy (group) i jeden dla pozostałych (others — wszyscy inni). Każdy zestaw kontroluje trzy akcje: odczyt (r), zapis (w) i wykonywanie (x). Uprawnienia te są reprezentowane numerycznie za pomocą notacji ósemkowej (octal), gdzie odczyt równa się 4, zapis równa się 2, a wykonywanie równa się 1. Wartości są sumowane dla każdego zestawu, tworząc trzycyfrową liczbę, taką jak 755 lub 644.

Na przykład uprawnienie 755 oznacza, że właściciel może czytać, zapisywać i wykonywać (7 = 4+2+1), podczas gdy grupa i pozostali mogą tylko czytać i wykonywać (5 = 4+0+1). Uprawnienie 644 oznacza, że właściciel może czytać i zapisywać (6 = 4+2+0), podczas gdy grupa i pozostali mogą tylko czytać (4 = 4+0+0). Zrozumienie tego systemu jest fundamentalne dla prowadzenia bezpiecznego i funkcjonalnego sklepu PrestaShop.

Oprócz numerycznych uprawnień, każdy plik ma przypisanego właściciela i grupę. Na serwerze WWW proces serwera (Apache lub Nginx) działa jako konkretny użytkownik, zazwyczaj www-data na Debian/Ubuntu lub apache/nobody na CentOS/RHEL. Serwer WWW musi mieć możliwość odczytu Twoich plików PrestaShop, aby je serwować, oraz potrzebuje dostępu do zapisu w określonych katalogach na potrzeby przesyłania plików, cachowania i konfiguracji.

Prawidłowe uprawnienia dla katalogów i plików PrestaShop

Ogólna zasada dla PrestaShop jest prosta: katalogi powinny mieć uprawnienia 755, a pliki powinny mieć uprawnienia 644. Daje to właścicielowi pełną kontrolę, podczas gdy grupa i pozostali mogą czytać (oraz wykonywać/przechodzić w przypadku katalogów), ale nie mogą niczego modyfikować. Użytkownik serwera WWW powinien być właścicielem wszystkich plików PrestaShop lub co najmniej należeć do grupy, która je posiada.

Aby ustawić te uprawnienia w całej instalacji PrestaShop, połącz się z serwerem przez SSH i uruchom:

find /var/www/html/prestashop -type d -exec chmod 755 {} \\;\nfind /var/www/html/prestashop -type f -exec chmod 644 {} \\;

Zastąp /var/www/html/prestashop rzeczywistą ścieżką do Twojej instalacji PrestaShop. Pierwsze polecenie znajduje wszystkie katalogi i ustawia im uprawnienia 755. Drugie znajduje wszystkie pliki i ustawia im uprawnienia 644.

Jednakże pewne katalogi wymagają dostępu do zapisu przez serwer WWW. Te katalogi wymagają szczególnej uwagi, ponieważ PrestaShop zapisuje w nich dane podczas normalnej pracy:

/var/cache/ — Skompilowane szablony Smarty i cache Symfony
/var/logs/ — Pliki logów aplikacji
/upload/ — Pliki przesłane przez klientów
/download/ — Pliki produktów wirtualnych
/img/ — Zdjęcia produktów, kategorii, stron CMS
/modules/ — Instalacja i aktualizacje modułów
/themes/ — Pliki cache motywu
/translations/ — Pliki eksportu tłumaczeń
/config/ — Pliki konfiguracyjne (parameters.php)
/app/config/ — Konfiguracja Symfony
/app/Resources/translations/ — Tłumaczenia Symfony

Jeśli użytkownik serwera WWW jest właścicielem tych plików (co jest zalecaną konfiguracją), to uprawnienia 755/644 są wystarczające. Jeśli serwer WWW działa jako inny użytkownik, może być konieczna zmiana uprawnień grupowych lub właścicielstwa.

Ustawianie prawidłowego właścicielstwa za pomocą chown

Właścicielstwo jest równie ważne jak uprawnienia. Polecenie chown zmienia właściciela i grupę plików. Dla typowego serwera Debian/Ubuntu z Apache lub Nginx, użytkownikiem serwera WWW jest www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

Flaga -R stosuje zmianę rekurencyjnie do wszystkich plików i podkatalogów. Na systemach CentOS lub RHEL zastąp www-data wartością apache lub nginx w zależności od Twojego serwera WWW.

Powszechnym alternatywnym podejściem jest ustawienie właściciela na Twojego użytkownika SSH/FTP, a grupy na użytkownika serwera WWW. Pozwala to edytować pliki przez FTP lub SSH, jednocześnie umożliwiając serwerowi WWW ich odczyt:

sudo chown -R twojuzytkownik:www-data /var/www/html/prestashop

W takim przypadku katalogi wymagające dostępu do zapisu przez serwer WWW powinny mieć uprawnienia 775 (zapis dla grupy), a pliki do zapisu powinny mieć 664:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \\;\nfind /var/www/html/prestashop/var -type f -exec chmod 664 {} \\;\nfind /var/www/html/prestashop/img -type d -exec chmod 775 {} \\;\nfind /var/www/html/prestashop/img -type f -exec chmod 664 {} \\;

Hosting współdzielony vs VPS vs serwer dedykowany

Środowisko hostingowe drastycznie wpływa na to, jak uprawnienia plików działają w praktyce. Zrozumienie różnic jest kluczowe dla prawidłowej konfiguracji uprawnień.

Hosting współdzielony (Shared Hosting)

Na hostingu współdzielonym dostęp do plików uzyskujesz zazwyczaj przez FTP lub menedżer plików w cPanelu/Plesku. Model wykonywania PHP różni się w zależności od dostawcy, ale większość nowoczesnych hostów współdzielonych korzysta z PHP-FPM lub suPHP, co oznacza, że PHP działa jako Twoje konto użytkownika, a nie jako globalny użytkownik serwera WWW. To znacząco upraszcza kwestię uprawnień: ponieważ PHP działa jako Twój użytkownik, może już czytać i zapisywać Twoje pliki ze standardowymi uprawnieniami 755/644. Rzadko musisz zmieniać właścicielstwo na hostingu współdzielonym, ponieważ wszystko już należy do Twojego konta.

Jeśli napotkasz błędy uprawnień na hostingu współdzielonym, sprawdź u dostawcy, czy używa suPHP lub PHP-FPM. Jeśli stosuje starszy model mod_php, może być konieczne tymczasowe ustawienie niektórych katalogów na 777 (choć nie jest to zalecane ze względów bezpieczeństwa). Większość renomowanych dostawców odeszła od mod_php właśnie z powodu tych komplikacji z uprawnieniami.

VPS (Virtual Private Server — Wirtualny Serwer Prywatny)

Na VPS masz pełną kontrolę. Jest to najczęstsza konfiguracja dla poważnych sklepów PrestaShop. Powinieneś upewnić się, że użytkownik serwera WWW jest właścicielem plików PrestaShop lub co najmniej należy do grupy mającej dostęp do odczytu. Zalecana konfiguracja to:

Ustaw właściciela na www-data:www-data (lub Twojego użytkownika serwera WWW)
Użyj 755 dla katalogów i 644 dla plików
Używaj SSH z sudo do wprowadzania zmian lub dodaj swojego użytkownika SSH do grupy www-data

Aby dodać swojego użytkownika SSH do grupy serwera WWW:

sudo usermod -a -G www-data twojuzytkownik

Następnie ustaw bit zapisu dla grupy na katalogach, które chcesz edytować:

chmod g+w /var/www/html/prestashop/themes/twoj-motyw/

Serwer dedykowany

Serwery dedykowane działają na tych samych zasadach co konfiguracje VPS. Główna różnica to wydajność: masz więcej zasobów, więc możesz uruchomić PHP-FPM z dedykowanymi pulami na stronę. Każda pula może działać jako inny użytkownik, zapewniając lepszą izolację, jeśli hostujesz wiele sklepów PrestaShop na tym samym serwerze.

Modele wykonywania PHP: suPHP vs mod_php vs PHP-FPM

Sposób, w jaki PHP jest wykonywane na Twoim serwerze, bezpośrednio determinuje, który użytkownik tworzy pliki i tym samym jakie uprawnienia są potrzebne.

mod_php (moduł Apache)

To najstarszy i najprostszy model. PHP działa jako część procesu Apache, co oznacza, że cały kod PHP jest wykonywany jako użytkownik Apache (zazwyczaj www-data lub apache). Problem polega na tym, że pliki tworzone przez PHP (cache, uploady itp.) są własnością użytkownika serwera WWW, a nie Twojego konta. Może to utrudniać zarządzanie przez FTP i stwarza zagrożenia bezpieczeństwa na hostach współdzielonych, ponieważ wszystkie strony działają jako ten sam użytkownik.

Z mod_php pliki PrestaShop powinny być własnością użytkownika Apache, a uprawnienia 755/644 działają prawidłowo. Jednakże ten model jest w dużej mierze przestarzały na nowoczesnych serwerach.

suPHP

suPHP uruchamia PHP jako właściciel pliku, a nie jako użytkownik serwera WWW. Oznacza to, że jeśli Twoje pliki są własnością twojuzytkownik, PHP również działa jako twojuzytkownik. Jest to bezpieczniejsze na hostingu współdzielonym, ponieważ każde konto jest izolowane. Standardowe uprawnienia 755/644 działają idealnie z suPHP, ponieważ proces PHP i właściciel pliku to ten sam użytkownik.

Jedno ważne zastrzeżenie: suPHP faktycznie odrzuca pliki z uprawnieniami 777 lub pliki należące do innych użytkowników. Jeśli ustawisz 777 na serwerze z suPHP, PHP odmówi wykonania tych plików, wyświetlając zamiast tego błąd 500 Internal Server Error.

PHP-FPM (FastCGI Process Manager)

PHP-FPM to nowoczesny standard. Uruchamia PHP jako oddzielny proces od serwera WWW, z konfigurowalnym użytkownikiem i grupą per pula. Na VPS, PHP-FPM zazwyczaj działa jako www-data. Na hostingu współdzielonym z CloudLinux lub podobnym rozwiązaniem, każde konto otrzymuje własną pulę PHP-FPM działającą jako użytkownik tego konta.

PHP-FPM w połączeniu z Nginx to zalecana konfiguracja dla wydajności PrestaShop. Standardowy schemat uprawnień 755/644 sprawdza się dobrze. Upewnij się, że użytkownik puli PHP-FPM odpowiada właścicielowi plików lub ma odpowiedni dostęp grupowy.

Dlaczego uprawnienia 777 są niebezpieczne

Ustawienie uprawnień na 777 oznacza, że każdy użytkownik w systemie może czytać, zapisywać i wykonywać plik. Na hostingu współdzielonym oznacza to, że inne konta na tym samym serwerze mogłyby potencjalnie odczytać Twoje dane logowania do bazy danych z parameters.php lub wstrzyknąć złośliwy kod do Twoich plików PHP.

Nawet na VPS, gdzie jesteś jedynym użytkownikiem, 777 jest niepotrzebne i wskazuje na błędną konfigurację. Jeśli serwer WWW nie może zapisywać w katalogu z uprawnieniami 755, rozwiązaniem jest naprawienie właścicielstwa, a nie otwieranie uprawnień dla całego świata. Oto co powinieneś zrobić zamiast używania 777:

Sprawdź, jako kto działa serwer WWW: ps aux | grep -E \"apache|nginx|httpd\"
Sprawdź właścicielstwo plików: ls -la /var/www/html/prestashop/
Napraw właścicielstwo: sudo chown -R www-data:www-data /sciezka/do/katalogu
Ustaw prawidłowe uprawnienia: chmod 755 /sciezka/do/katalogu

Jeśli znajdziesz poradnik lub post na forum zalecający 777 dla PrestaShop, to przestarzała i niebezpieczna rada. Jedyne uzasadnione zastosowanie 777 dotyczy katalogów /tmp, które mają ustawiony bit sticky (wyświetlany jako 1777), co jest konfiguracją na poziomie systemowym, a nie czymś, co stosuje się do plików PrestaShop.

Kwestie Dockera w kontekście PrestaShop

Uruchamianie PrestaShop w Dockerze wprowadza dodatkową złożoność do uprawnień plików. Wewnątrz kontenera serwer WWW działa jako www-data z konkretnym UID (często 33 na obrazach opartych na Debianie). Na systemie hosta Twój użytkownik ma inny UID. Gdy używasz bind mountów Dockera do montowania plików PrestaShop do kontenera, właścicielstwo plików jest określane przez numeryczny UID, a nie nazwę użytkownika.

Oznacza to, że pliki utworzone na hoście jako Twój użytkownik (np. UID 1000) będą widoczne wewnątrz kontenera jako UID 1000, który nie jest www-data (UID 33). Serwer WWW wewnątrz kontenera może nie być w stanie zapisywać do tych plików.

Rozwiązania problemów z uprawnieniami w Dockerze obejmują:

Dopasowanie UID: Stwórz użytkownika wewnątrz kontenera z tym samym UID co Twój użytkownik na hoście lub zmień serwer WWW, aby działał z Twoim UID.
Użycie chown w entrypoincie: Dodaj polecenie startowe, które uruchamia chown -R www-data:www-data /var/www/html przy starcie kontenera. Jest to proste, ale może być wolne dla dużych instalacji.
Ustawienie uprawnień grupowych: Dodaj swojego użytkownika hosta i www-data do tej samej grupy (po GID), a następnie użyj uprawnień 775/664.
Named volumes: Użyj named volumes Dockera zamiast bind mountów. Docker automatycznie zarządza uprawnieniami, ale tracisz bezpośredni dostęp do systemu plików z hosta.

Dla środowisk deweloperskich z bind mountami, najbardziej praktycznym podejściem jest uruchomienie polecenia chown po synchronizacji lub wdrożeniu plików:

docker exec twoj-kontener chown -R www-data:www-data /var/www/html/modules/twoj-modul/

Miej na uwadze, że operacje wewnątrz kontenera (jak instalacja modułu) mogą tworzyć pliki jako www-data, podczas gdy operacje na hoście tworzą pliki jako Twój użytkownik hosta. Ta ciągła niezgodność UID jest najczęstszym źródłem problemów z uprawnieniami w zdockeryzowanych konfiguracjach PrestaShop.

Rozwiązywanie typowych błędów uprawnień

\"Failed to open stream: Permission denied\"

Ten błąd oznacza, że PHP nie może odczytać lub zapisać pliku. Sprawdź właścicielstwo i uprawnienia pliku wskazanego w komunikacie błędu. Najczęstszą przyczyną jest to, że użytkownik serwera WWW nie jest właścicielem pliku lub katalogu. Napraw to za pomocą:

sudo chown www-data:www-data /sciezka/do/pliku\nsudo chmod 644 /sciezka/do/pliku

\"Unable to write to cache directory\"

Silnik szablonów Smarty i framework Symfony w PrestaShop oba zapisują pliki cache. Jeśli katalog var/cache/ nie jest zapisywalny, zobaczysz ten błąd. Katalog cache musi być własnością użytkownika serwera WWW:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/\nsudo chmod -R 755 /var/www/html/prestashop/var/cache/

Po naprawieniu uprawnień wyczyść istniejący cache, usuwając zawartość katalogów cache:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*\nsudo rm -rf /var/www/html/prestashop/var/cache/dev/*

\"Cannot upload image\" lub \"Cannot install module\"

Przesyłanie obrazów trafia do katalogu img/, a instalacje modułów zapisują do katalogu modules/. Oba muszą być zapisywalne przez użytkownika serwera WWW. Dodatkowo sprawdź, czy ustawienia PHP upload_max_filesize i post_max_size są wystarczająco duże dla Twoich plików, ponieważ mogą one powodować podobnie brzmiące błędy.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/\nsudo chown -R www-data:www-data /var/www/html/prestashop/modules/

\"index.php is not writable\" podczas aktualizacji

Auto-aktualizator PrestaShop potrzebuje dostępu do zapisu praktycznie każdego pliku w instalacji. Przed uruchomieniem aktualizacji ustaw właścicielstwo całej instalacji na użytkownika serwera WWW. Po zakończeniu aktualizacji możesz przywrócić bardziej restrykcyjne właścicielstwo, jeśli chcesz.

Biała strona po zmianie uprawnień

Jeśli widzisz pustą białą stronę po zmianie uprawnień, mogłeś przypadkowo usunąć uprawnienie do wykonywania z katalogów. Katalogi potrzebują bitu wykonywania, aby można je było przeglądać. Katalog z uprawnieniami 644 (bez wykonywania) jest praktycznie niedostępny. Zawsze używaj 755 dla katalogów, nigdy 644.

Możesz również sprawdzić log błędów PHP po więcej szczegółów:

sudo tail -50 /var/log/apache2/error.log\n# lub dla Nginx:\nsudo tail -50 /var/log/nginx/error.log

Uprawnienia resetują się po przesłaniu przez FTP

Niektóre klienty FTP ustawiają własne domyślne uprawnienia podczas przesyłania plików. Sprawdź ustawienia swojego klienta FTP w poszukiwaniu opcji „domyślne uprawnienia" lub „umask". Ustaw tworzenie plików z uprawnieniami 644, a katalogów z 755. Alternatywnie, uruchom polecenia naprawy uprawnień po każdym przesłaniu przez FTP.

Najlepsze praktyki bezpieczeństwa wykraczające poza uprawnienia

Prawidłowe uprawnienia plików to tylko jedna warstwa bezpieczeństwa. Rozważ te dodatkowe środki:

Ogranicz dostęp do plików konfiguracyjnych: Plik app/config/parameters.php zawiera Twoje dane logowania do bazy danych. Upewnij się, że jest czytelny tylko dla użytkownika serwera WWW (uprawnienia 640), a nie dla wszystkich.
Wyłącz listowanie katalogów: Dodaj Options -Indexes do konfiguracji Apache lub autoindex off; do Nginx, aby uniemożliwić odwiedzającym przeglądanie zawartości katalogów.
Chroń pliki .htaccess: PrestaShop umieszcza pliki .htaccess w wrażliwych katalogach. Nie usuwaj ich.
Usuń katalog instalacyjny: Po instalacji całkowicie usuń katalog /install/. PrestaShop ostrzega o tym, ale warto to podkreślić.
Ustaw prawidłowy umask: Skonfiguruj serwer WWW i PHP-FPM z umaską 0022, aby nowe pliki były tworzone z uprawnieniami 644/755 domyślnie.

Rozumiejąc uprawnienia Linuxa, dopasowując je do swojego środowiska hostingowego i stosując wytyczne z tego artykułu, unikniesz najczęstszych problemów z uprawnieniami w PrestaShop, jednocześnie utrzymując bezpieczną konfigurację serwera.

Przeczytaj pełną odpowiedź

Gdy aktualizacja modułu poszła nie tak

Zaktualizowałeś moduł PrestaShop i teraz coś nie działa. Może checkout przestał działać, strona główna wyrzuca błędy, lub panel administracyjny przestał odpowiadać. Aktualizacje modułów mogą się nie powieść z wielu powodów - niezgodne wersje PHP, konflikty z innymi modułami, błędy migracji bazy danych lub po prostu bugi w nowej wersji. Niezależnie od przyczyny, musisz szybko cofnąć zmiany, aby przywrócić funkcjonalność swojego sklepu.

Niestety, PrestaShop nie zawiera wbudowanego przycisku "cofnij" dla aktualizacji modułów. Nie ma natywnej historii wersji ani automatycznego mechanizmu rollbacku dla poszczególnych modułów. Oznacza to, że musisz przeprowadzić downgrade ręcznie.

Zanim zaczniesz - bezpieczeństwo przede wszystkim

Włącz tryb konserwacji - Parametry sklepu > Ogólne > Konserwacja
Utwórz kopię zapasową bazy danych
Udokumentuj obecny błąd

Metoda 1 - Ponowna instalacja poprzedniej wersji przez Back Office

Przejdź do Moduły > Menedżer modułów
Znajdź problematyczny moduł i kliknij Odinstaluj (NIE "Usuń" - odinstalowanie zachowuje dane modułu w bazie)
Kliknij Prześlij moduł
Prześlij plik ZIP poprzedniej działającej wersji
Zainstaluj i skonfiguruj moduł

Gdzie zdobyć poprzednią wersję

Twój email - Większość sprzedawców modułów wysyła linki do pobrania z każdym zakupem
Konto na marketplace - Na PrestaShop Addons i w marketplace'ach firm trzecich jak mypresta.rocks możesz pobrać poprzednie wersje z historii zamówień
Twoje kopie zapasowe - Wyodrębnij folder modułu z archiwum kopii zapasowej
Skontaktuj się z deweloperem - Deweloperzy modułów zazwyczaj mogą udostępnić starsze wersje

Metoda 2 - Podmiana plików przez FTP/SFTP

Połącz się z serwerem przez FTP/SFTP za pomocą klienta jak FileZilla
Przejdź do /modules/ w katalogu instalacji PrestaShop
Znajdź folder modułu
Zmień nazwę obecnego folderu - np. mymodule na mymodule_zepsuty
Prześlij pliki poprzedniej wersji do nowego folderu mymodule
Ustaw prawidłowe uprawnienia - katalogi na 755, pliki na 644
Wyczyść cache PrestaShop

Metoda 3 - Z linii poleceń

# Połącz się przez SSH
ssh user@twojserwer.com

# Przejdź do katalogu głównego PrestaShop
cd /var/www/html/prestashop

# Zabezpiecz zepsuty moduł
mv modules/mymodule modules/mymodule_zepsuty_$(date +%Y%m%d)

# Rozpakuj poprzednią wersję
unzip /sciezka/do/mymodule_v1.2.3.zip -d modules/

# Ustaw prawidłowe uprawnienia
find modules/mymodule -type d -exec chmod 755 {} \;
find modules/mymodule -type f -exec chmod 644 {} \;
chown -R www-data:www-data modules/mymodule

# Wyczyść cache
rm -rf var/cache/prod/* var/cache/dev/*

Metoda 4 - Pełny rollback bazy danych

Jeśli aktualizacja modułu zawierała migracje bazy danych, musisz przywrócić kopię zapasową bazy danych sprzed aktualizacji.

Kiedy potrzebujesz rollbacku bazy danych

Moduł utworzył nowe tabele bazy danych
Moduł zmienił istniejące struktury tabel
Moduł wstawił lub zmodyfikował wartości konfiguracyjne

Ostrzeżenie - Pełne przywrócenie bazy danych cofnie WSZYSTKIE zmiany od czasu kopii zapasowej, łącznie z nowymi zamówieniami i rejestracjami klientów.

Metoda 5 - Ręczne czyszczenie bazy danych

// Szukaj plików typu:
// modules/mymodule/upgrade/upgrade-2.0.0.php

public function upgrade($version)
{
    if (version_compare($version, '2.0.0', '<')) {
        Db::getInstance()->execute('ALTER TABLE `' . _DB_PREFIX_ . 'mymodule` 
            ADD COLUMN `new_field` VARCHAR(255)');
    }
}

Po downgrade - niezbędne porządki

Wyczyść wszystkie cache

Cache Smarty
OPcache - Restart PHP-FPM lub Apache
Cache CDN
Cache przeglądarki - Testuj w trybie incognito

Zweryfikuj wersję modułu

Po downgrade sprawdź, czy PrestaShop rozpoznaje prawidłową wersję.

Testuj dokładnie

Konkretną funkcjonalność modułu
Proces checkout od początku do końca
Strony administracyjne z treścią modułu
Widoki mobilne i desktopowe
Wydajność

Zapobieganie przyszłym problemom z aktualizacjami

Zawsze twórz kopię zapasową przed aktualizacją
Testuj aktualizacje na środowisku stagingowym
Czytaj changelog
Zachowuj poprzednie wersje
Sprawdzaj kompatybilność

Kiedy skontaktować się z deweloperem modułu

Jeśli żadna z powyższych metod nie rozwiąże problemu, skontaktuj się z deweloperem podając wersję PrestaShop, wersję PHP, wersje modułu i dokładne komunikaty błędów.

Przeczytaj pełną odpowiedź

Jak przetestować moduł PrestaShop na środowisku staging

Instalacja nieprzetestowanego modułu na działającym sklepie PrestaShop to jedna z najczęstszych przyczyn przestojów, uszkodzonych procesów płatności i utraty przychodów. Środowisko staging zapewnia bezpieczną piaskownicę do weryfikacji każdego modułu, zanim dotknie Twojego sklepu produkcyjnego. Ten przewodnik przeprowadzi Cię przez cały proces - od tworzenia kopii staging sklepu po dokładne testowanie modułów i bezpieczne wdrażanie na produkcji.

Dlaczego potrzebujesz środowiska staging

Środowisko staging to dokładna kopia Twojego sklepu, która nie jest dostępna publicznie. Odzwierciedla Twoją produkcyjną bazę danych, pliki, motyw, konfigurację i zainstalowane moduły. Testowanie na staging pozwala wychwycić problemy, które w przeciwnym razie dotknęłyby Twoich klientów.

Oto co może pójść nie tak, gdy pominiesz staging:

Konflikty modułów - Nowy moduł może wejść w konflikt z istniejącym modułem, powodując białe ekrany, błędy JavaScript lub uszkodzone funkcjonalności na poszczególnych stronach.
Niekompatybilność motywu - Szablony modułu mogą nie renderować się prawidłowo z Twoim motywem, szczególnie jeśli używasz niestandardowego lub mocno zmodyfikowanego motywu.
Degradacja wydajności - Niektóre moduły dodają ciężkie zapytania do bazy danych, dodatkowe pliki CSS/JS lub zewnętrzne wywołania API, które spowalniają czas ładowania stron.
Uszkodzenie bazy danych - Źle napisane moduły mogą modyfikować tabele rdzeniowe, dodawać kolumny bez właściwej obsługi migracji lub tworzyć triggery, które zakłócają istniejące dane.
Zakłócenie płatności - Jeśli moduł psuje proces zamówienia lub zakłóca bramkę płatności, tracisz sprzedaż od momentu instalacji do odkrycia i naprawienia problemu.

Opcja 1 - Ręczna konfiguracja staging (subdomena)

To najczęstsze podejście, które działa z każdym dostawcą hostingu. Tworzysz subdomenę jak staging.twojsklep.com i kopiujesz tam swoje pliki produkcyjne i bazę danych.

Krok 1 - Utwórz subdomenę

W panelu sterowania hostingu (cPanel, Plesk lub DirectAdmin) utwórz nową subdomenę. Skieruj ją na nowy katalog, na przykład /home/twojuser/staging.twojsklep.com.

Krok 2 - Skopiuj pliki produkcyjne

Połącz się z serwerem przez SSH lub FTP i skopiuj wszystkie pliki produkcyjne do katalogu staging:

# Przez SSH (najszybsza metoda)
cp -r /home/twojuser/public_html/* /home/twojuser/staging.twojsklep.com/

# Lub najpierw utwórz skompresowane archiwum
cd /home/twojuser/public_html
tar czf /tmp/prestashop-backup.tar.gz --exclude='var/cache' --exclude='var/logs' .
cd /home/twojuser/staging.twojsklep.com
tar xzf /tmp/prestashop-backup.tar.gz

Krok 3 - Eksportuj i importuj bazę danych

Utwórz nową bazę danych dla staging, a następnie skopiuj dane produkcyjne:

# Eksportuj produkcyjną bazę danych
mysqldump -u dbuser -p production_db > /tmp/production_dump.sql

# Utwórz bazę staging
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p -e "GRANT ALL ON staging_db.* TO 'dbuser'@'localhost';"

# Importuj do staging
mysql -u dbuser -p staging_db < /tmp/production_dump.sql

Krok 4 - Zaktualizuj konfigurację PrestaShop

Edytuj pliki konfiguracyjne, aby wskazywały na bazę danych i domenę staging:

# Edytuj app/config/parameters.php (PrestaShop 1.7+/8.x)
'database_name' => 'staging_db',

# Zaktualizuj URL sklepu w bazie danych
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url 
  SET domain = 'staging.twojsklep.com', 
      domain_ssl = 'staging.twojsklep.com' 
  WHERE id_shop_url = 1;"

# Zaktualizuj wartości konfiguracyjne
mysql -u dbuser -p staging_db -e "
  UPDATE ps_configuration 
  SET value = 'staging.twojsklep.com' 
  WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');"

Krok 5 - Wyczyść cache

rm -rf var/cache/prod/* var/cache/dev/*
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

Krok 6 - Ogranicz dostęp

Zablokuj dostęp wyszukiwarkom i nieuprawnionym użytkownikom do Twojej strony staging:

# Ochrona hasłem staging
AuthType Basic
AuthName "Dostep Staging"
AuthUserFile /home/twojuser/.htpasswd
Require valid-user

Header set X-Robots-Tag "noindex, nofollow"

Opcja 2 - Staging oparty na Docker (Zalecane dla deweloperów)

Docker zapewnia najbardziej niezawodne środowisko staging, ponieważ możesz dokładnie odwzorować swoją produkcyjną wersję PHP, wersję MySQL i konfigurację serwera.

# docker-compose.yml
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.1
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=prestashop
      - DB_PASSWD=twoje_haslo
    depends_on:
      - db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=haslo_root
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=twoje_haslo
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data:

Lista kontrolna testów dla nowych modułów

Faza 1 - Sprawdzenia przed instalacją

Przeczytaj dokumentację modułu - Zrozum, co robi moduł, jakich hooków używa i jakie ma wymagania.
Sprawdź zawartość plików - Przed instalacją rozpakuj moduł i przejrzyj kod. Szukaj podejrzanych wzorców jak eval(), base64_decode().
Utwórz kopię zapasową bazy - Nawet na staging utwórz backup przed instalacją.

mysqldump -u dbuser -p staging_db > /tmp/staging_przed_modulem.sql

Faza 2 - Testowanie instalacji

Zainstaluj moduł przez Back Office (Moduły > Menedżer modułów > Prześlij moduł).
Sprawdź błędy instalacji - Po instalacji sprawdź, czy moduł pojawia się na liście zainstalowanych modułów i czy nie ma komunikatów o błędach.
Zweryfikuj zmiany w bazie danych - Porównaj tabele bazy przed i po instalacji.

Faza 3 - Testy funkcjonalne

Strona konfiguracji - Czy możesz uzyskać dostęp i zapisać wszystkie ustawienia bez błędów?
Wyświetlanie front office - Czy moduł renderuje się prawidłowo na wszystkich odpowiednich stronach?
Responsywność mobilna - Testuj na viewportach mobilnych.
Obsługa wielu języków - Jeśli sklep używa wielu języków, zweryfikuj poprawne wyświetlanie w każdym.
Kompatybilność z multishop - Jeśli używasz funkcji multistore, przetestuj zachowanie modułu.

Faza 4 - Testy konfliktów

To najkrytyczniejsza faza. Testuj konflikty z istniejącą konfiguracją:

Sprawdź konsolę przeglądarki - Otwórz narzędzia deweloperskie (F12) i szukaj błędów JavaScript.
Przetestuj proces zakupowy - Dodaj produkt do koszyka, przejdź przez każdy krok checkout i złóż zamówienie testowe.
Przetestuj przetwarzanie płatności - Złóż zamówienia testowe z każdą metodą płatności.
Sprawdź funkcjonalność istniejących modułów - Upewnij się, że krytyczne moduły nadal działają.

Faza 5 - Testy wydajnościowe

# Przed instalacją modułu, zmierz baseline
curl -o /dev/null -s -w "Czas: %{time_total}s\n" https://staging.twojsklep.com/

# Po instalacji, zmierz ponownie i porównaj
curl -o /dev/null -s -w "Czas: %{time_total}s\n" https://staging.twojsklep.com/

Dobrze napisany moduł powinien dodać mniej niż 100ms do czasów ładowania stron. Jeśli widzisz wzrost o 500ms lub więcej, zbadaj zapytania do bazy danych i ładowanie zasobów modułu.

Faza 6 - Test dezinstalacji

Odinstaluj moduł z Back Office
Zweryfikuj usunięcie tabel specyficznych dla modułu
Sprawdź, czy nie pozostały osierocone hooki, pliki CSS lub JavaScript
Upewnij się, że front office wraca do stanu sprzed modułu

Przenoszenie przetestowanego modułu na produkcję

Krok 1 - Zaplanuj wdrożenie

Wybierz okres niskiego ruchu. Sprawdź Google Analytics, aby zidentyfikować, kiedy Twój sklep ma najmniej odwiedzających.

Krok 2 - Utwórz kopię zapasową produkcji

mysqldump -u dbuser -p production_db > /tmp/production_backup_$(date +%Y%m%d_%H%M%S).sql

Krok 3 - Zainstaluj na produkcji

Prześlij dokładnie ten sam plik ZIP modułu, który testowałeś na staging. Nie pobieraj nowej wersji.

Krok 4 - Zastosuj tę samą konfigurację

Skonfiguruj moduł z dokładnie tymi samymi ustawieniami jak na staging. Zrób zrzuty ekranu konfiguracji staging przed rozpoczęciem.

Krok 5 - Monitoruj przez 24-48 godzin

Po wdrożeniu aktywnie monitoruj logi błędów PHP, Google Analytics i wskaźnik konwersji zamówień.

Typowe pułapki staging

Zapomnienie o aktualizacji URL - Jeśli skopiujesz bazę, ale zapomnisz zaktualizować ps_shop_url, Twoja strona staging przekieruje na produkcję.
Bramki płatności w trybie live - Zawsze przełączaj bramki płatności na tryb sandbox/test na staging.
Powiadomienia email wysyłane do klientów - Wyłącz wysyłanie emaili na staging lub przekieruj wszystkie na adres testowy.
Indeksowanie przez wyszukiwarki - Zawsze blokuj staging dla wyszukiwarek.
Zadania cron działające na staging - Wyłącz wszystkie zadania cron skopiowane z produkcji.

Przeczytaj pełną odpowiedź

Cookie	Dostawca	Cel	Czas
PrestaShop-*	PrestaShop	Zarządzanie sesją i funkcjonalność koszyka	Sesja
PHPSESSID	PHP	Identyfikator sesji PHP	Sesja
mprcr_consent	MPR Cookies Revolution	Przechowuje preferencje zgody na pliki cookie	365 dzień/dni
mprcr_version	MPR Cookies Revolution	Śledzi wersję konfiguracji zgody	365 dzień/dni

Cookie	Dostawca	Cel	Czas
TawkConnectionTime	Tawk.to	Suivi du temps de connexion de la session de chat	Sesja
__tawkuuid	Tawk.to	Identifie les visiteurs de chat recurrents	6 miesiąc/e

Cookie	Dostawca	Cel	Czas
_ga	Google Analytics	Rozróżnia unikalnych użytkowników za pomocą losowo wygenerowanego numeru	2 rok/lata
_ga_*	Google Analytics	Używany do utrzymania stanu sesji między żądaniami stron	2 rok/lata
_gid	Google Analytics	Rozróżnia unikalnych użytkowników przez 24 godziny	24 godzina/y

Instalacja i konfiguracja

Zrozumienie uprawnień plików w systemie Linux

Prawidłowe uprawnienia dla katalogów i plików PrestaShop

Ustawianie prawidłowego właścicielstwa za pomocą chown

Hosting współdzielony vs VPS vs serwer dedykowany

Hosting współdzielony (Shared Hosting)

VPS (Virtual Private Server — Wirtualny Serwer Prywatny)

Serwer dedykowany

Modele wykonywania PHP: suPHP vs mod_php vs PHP-FPM

mod_php (moduł Apache)

suPHP

PHP-FPM (FastCGI Process Manager)

Dlaczego uprawnienia 777 są niebezpieczne

Kwestie Dockera w kontekście PrestaShop

Rozwiązywanie typowych błędów uprawnień

\"Failed to open stream: Permission denied\"

\"Unable to write to cache directory\"

\"Cannot upload image\" lub \"Cannot install module\"

\"index.php is not writable\" podczas aktualizacji

Biała strona po zmianie uprawnień

Uprawnienia resetują się po przesłaniu przez FTP

Najlepsze praktyki bezpieczeństwa wykraczające poza uprawnienia

Gdy aktualizacja modułu poszła nie tak

Zanim zaczniesz - bezpieczeństwo przede wszystkim

Metoda 1 - Ponowna instalacja poprzedniej wersji przez Back Office

Gdzie zdobyć poprzednią wersję

Metoda 2 - Podmiana plików przez FTP/SFTP

Metoda 3 - Z linii poleceń

Metoda 4 - Pełny rollback bazy danych

Kiedy potrzebujesz rollbacku bazy danych

Metoda 5 - Ręczne czyszczenie bazy danych

Po downgrade - niezbędne porządki

Wyczyść wszystkie cache

Zweryfikuj wersję modułu

Testuj dokładnie

Zapobieganie przyszłym problemom z aktualizacjami

Kiedy skontaktować się z deweloperem modułu

Jak przetestować moduł PrestaShop na środowisku staging

Dlaczego potrzebujesz środowiska staging

Opcja 1 - Ręczna konfiguracja staging (subdomena)

Krok 1 - Utwórz subdomenę

Krok 2 - Skopiuj pliki produkcyjne

Krok 3 - Eksportuj i importuj bazę danych

Krok 4 - Zaktualizuj konfigurację PrestaShop

Krok 5 - Wyczyść cache

Krok 6 - Ogranicz dostęp

Opcja 2 - Staging oparty na Docker (Zalecane dla deweloperów)

Lista kontrolna testów dla nowych modułów

Faza 1 - Sprawdzenia przed instalacją

Faza 2 - Testowanie instalacji

Faza 3 - Testy funkcjonalne

Faza 4 - Testy konfliktów

Faza 5 - Testy wydajnościowe

Faza 6 - Test dezinstalacji

Przenoszenie przetestowanego modułu na produkcję

Krok 1 - Zaplanuj wdrożenie

Krok 2 - Utwórz kopię zapasową produkcji

Krok 3 - Zainstaluj na produkcji

Krok 4 - Zastosuj tę samą konfigurację

Krok 5 - Monitoruj przez 24-48 godzin

Typowe pułapki staging

Inne kategorie

Masz jeszcze pytania?