DataFirefly Staging Pro: kompletny przewodnik

Staging Pro tworzy kompletną kopię Twojego sklepu (pliki i baza danych) w chronionym podkatalogu obecnego hostingu, bez żadnych timeoutów, dzięki silnikowi kopiowania partiami. Testujesz moduły, szablony i aktualizacje w pełni bezpiecznie, a następnie przenosisz zmiany na produkcję tabela po tabeli, z automatycznym backupem i rollbackiem jednym kliknięciem. Ten przewodnik obejmuje instalację, tworzenie stagingu, opcje ochrony, push do produkcji i rollback.

Instalacja

1. Pobierz archiwum dfstagingpro.zip ze swojego konta DataFirefly.
2. Panel administracyjny PrestaShop → Moduły → Wgraj moduł → wyślij plik ZIP.
3. Przy instalacji moduł tworzy tabele df_staging_env i df_staging_log, rejestruje swoje hooki i dodaje zakładkę Parametry zaawansowane → Staging Pro.

Jak działa staging

Środowisko stagingowe powstaje w podkatalogu w katalogu głównym Twojego sklepu (na przykład /staging-v2/) i korzysta z dedykowanego prefiksu tabel (na przykład dfs1_) w tej samej bazie danych co produkcja. Nie potrzebujesz zatem ani drugiego serwera, ani nowego dostępu MySQL, ani konfiguracji DNS.

Silnik kopiowania pracuje w kilkusekundowych partiach, po czym oddaje sterowanie i wznawia dokładnie w miejscu, w którym przerwał: kopiowanie plików przez trwałą kolejkę, klonowanie bazy pakietami wierszy. Sklep ważący kilka gigabajtów klonuje się w ten sposób bez błędów, nawet na hostingu współdzielonym z niskim max_execution_time.

Tworzenie stagingu

Przejdź do Parametry zaawansowane → Staging Pro, a następnie do panelu tworzenia:

1. Wpisz nazwę (wyłącznie małe litery, cyfry i myślniki, na przykład v2). Adresem stagingu będzie twoj-sklep.pl/staging-v2/.
2. Wybierz opcje ochrony i kopiowania (opisane niżej).
3. Kliknij Utwórz. Postęp wyświetla się na żywo wraz z paskiem postępu.

Po zakończeniu procesu adres stagingu oraz ewentualne dane logowania htpasswd wyświetlają się w wierszu środowiska.

Opcje ochrony i kopiowania

• Chroń przez .htpasswd: dodaje uwierzytelnianie HTTP (użytkownik staging). Hasło możesz wpisać albo wygenerować automatycznie, po czym wyświetli się na pulpicie.
• Wyłącz e-maile: odcina wychodzące wiadomości ze stagingu (PS_MAIL_METHOD = 3). Zero ryzyka napisania do prawdziwego klienta.
• Wyłącz płatności: dezaktywuje i odpina od hooków znane moduły płatności na stagingu.
• Pomiń statystyki: wyklucza z kopii duże i nieistotne tabele (logowania, logi, porzucone koszyki), co znacznie przyspiesza kopiowanie.
• Bez danych klientów: tworzy na stagingu puste tabele klientów, adresów klientów, zamówień, koszyków, wiadomości, gości, newslettera i logów RODO. Adresy dostawców, producentów i magazynów są zachowane, podobnie jak tabele konfiguracyjne zamówień (statusy, szablony wiadomości, statusy zwrotów, reguły koszyka). Zobacz osobną sekcję poniżej.
• Symlink katalogu img/: tworzy dowiązanie symboliczne do obrazów zamiast ich kopiowania, co daje ogromną oszczędność miejsca na dysku.
• Tryb konserwacji: przełącza staging w tryb konserwacji z Twoim adresem IP administratora na białej liście.

Silnik kopiowania partiami

Tworzenie stagingu przebiega w kilku etapach, każdy z własnym budżetem czasu i automatycznym wznawianiem: przygotowanie, kopiowanie plików, klonowanie bazy danych, przepisywanie adresów URL, konfiguracja i ochrona, a na końcu finalizacja. Przepisywanie adresów obejmuje shop_url, konfigurację (w tym wartości serializowane i JSON, obsługiwane bez uszkodzeń), a także treści CMS, produkty, kategorie, marki, dostawców i sklepy.

Odświeżanie, wiele środowisk i usuwanie

• Refresh: odbudowuje istniejący staging z aktualnego stanu produkcji (usunięcie, a następnie ponowne utworzenie katalogu i prefiksu), jednym kliknięciem.
• Wiele środowisk: utwórz tyle stagingów, ile potrzebujesz (v2, hotfix, test modułu), każdy niezależny.
• Usuwanie: kasuje katalog i tabele środowiska w sposób budżetowany, bez timeoutu.

Push do produkcji

Gdy testy zakończą się powodzeniem, przycisk Push pozwala przenieść zmiany na produkcję tabela po tabeli:

1. Kliknij Push w wierszu środowiska: wyświetli się lista tabel wraz z liczbą wierszy każdej z nich.
2. Zaznacz dokładnie tabele do przeniesienia.
3. Potwierdź. Przed każdą podmianą odpowiadająca tabela produkcyjna jest automatycznie zapisywana przez zmianę nazwy ze znacznikiem czasu na prefiks dfbak{znacznik_czasu}_.

Adresy URL są przepisywane w kierunku ze stagingu na produkcję podczas transferu. Tabele krytyczne (shop_url, configuration, shop, sesje i tabele modułu) są chronione i nigdy nie mogą zostać wypchnięte.

Rollback

Przycisk Rollback przywraca produkcję z ostatniego backupu pusha, jednym kliknięciem. Moduł zmienia nazwy tabel zapasowych dfbak…_, aby wróciły na swoje pierwotne miejsce.

Zabezpieczenia i dziennik

• Wszystkie działania są zablokowane, jeśli bieżący sklep sam jest stagingiem, co zapobiega operacjom kaskadowym.
• Szczegółowy dziennik jest dostępny dla każdego środowiska przez przycisk Logi.
• Ponieważ robots.txt w podkatalogu nie jest respektowany przez wyszukiwarki, rzeczywista ochrona przed indeksacją opiera się na nagłówku X-Robots-Tag i meta noindex; opcja .htpasswd pozostaje najpewniejszym zabezpieczeniem.

Zgodność i uwagi techniczne

• PrestaShop 8.0 do 9.x, zgodny z hostingiem współdzielonym i trybem wielojęzycznym.
• Kontroler administracyjny w trybie legacy (bez kontrolera Symfony) dla zgodności z PS8 i PS9.
• Endpointy AJAX w panelu administracyjnym przez czwarty argument getAdminLink(); odpowiedź JSON zwracana przez dedykowaną metodę.
• Staging to podkatalog w katalogu głównym oraz prefiks tabel dfs{id}_ w tej samej bazie MySQL.
• Backupy pusha są oznaczane znacznikiem czasu w prefiksie dfbak{YmdHis}_ i należy je usuwać po zatwierdzeniu.

Staging bez danych klientów

Opcja Bez danych klientów, dostępna od wersji 1.1.0, tworzy staging bez żadnych danych osobowych. Odpowiednie tabele powstają z dokładnie taką samą strukturą, ale pozostają puste. To zalecany wybór, gdy przekazujesz staging zewnętrznemu wykonawcy, przy testach szablonu lub modułu, które nie dotyczą procesu zakupowego, oraz aby ograniczyć powierzchnię RODO Twoich środowisk testowych.

Czego nie kopiujemy

• Klienci, grupy klientów, wątki i wiadomości obsługi klienta, sesje klientów, goście i statystyki logowań.
• Zamówienia i cała powiązana rodzina tabel: szczegóły, historia, faktury, płatności, przewoźnicy, zastosowane reguły koszyka, korekty i zwroty.
• Koszyki, produkty w koszykach, listy życzeń, wiadomości, zapisy na newsletter, logi RODO i logi wysyłki e-maili.
• Adresy klientów: tabela address jest kopiowana z filtrem, pomijane są wyłącznie wiersze powiązane z klientem.

Co zostaje zachowane

• Adresy dostawców, producentów, magazynów i punktów sprzedaży.
• Tabele konfiguracyjne zamówień: statusy zamówień i ich tłumaczenia, szablony wiadomości, statusy zwrotów, typy korekt.
• Reguły koszyka, kupony, przewoźnicy, podatki i cały katalog.
• Pracownicy panelu administracyjnego: logujesz się do stagingu swoimi zwykłymi danymi.

Uwierzytelnianie HTTP a hostingi cPanel / LiteSpeed

Od wersji 1.0.1 plik .htpasswd jest generowany w formacie APR1-MD5 (format polecenia htpasswd -m), który odczytują Apache, LiteSpeed i nginx. Wersja 1.0.0 używała bcrypt, którego LiteSpeed (bardzo częsty za cPanelem) nie potrafi odczytać: staging odpowiadał wtedy 404 na wszystkich stronach.

Blok ochrony dodaje też wbudowaną stronę błędu 401. W cPanelu błąd 401 jest globalnie przekierowywany na /401.shtml, stronę, która w PrestaShop nie istnieje: podżądanie trafia do dispatchera produkcji i zwraca jej stronę 404, przez co przeglądarka nigdy nie wyświetla okna logowania. Wbudowana strona omija to przekierowanie.

Ponadto linia ErrorDocument 404 skopiowanego pliku .htaccess jest przepisywana na podkatalog stagingu: błąd na stagingu wyświetla stronę 404 stagingu, a nie produkcji.

Autotest przy tworzeniu

Na koniec konfiguracji moduł wysyła żądanie HEAD do robots.txt stagingu, z danymi logowania, jeśli ochrona jest włączona, a następnie bez nich, aby sprawdzić, czy serwer odpowiada 401. Wynik jest zapisywany w logach środowiska:

• 200 z danymi logowania i 401 bez nich: wszystko w porządku.
• Serwer odrzuca blok uwierzytelniania: moduł usuwa blok i plik .htpasswd, wyłącza opcję i wyświetla „Ready with warning” w wierszu środowiska. Staging jest wtedy dostępny bez hasła; włącz tryb konserwacji.
• Kod 0: serwer nie może wywołać sam siebie (zablokowane żądania wychodzące). Otwórz adres stagingu ręcznie.

FAQ i rozwiązywanie problemów

Czy moduł działa na hostingu współdzielonym? Tak. Silnik kopiowania partiami z automatycznym wznawianiem eliminuje timeouty, niezależnie od wartości max_execution_time na serwerze.

Tworzenie zostało przerwane, co zrobić? Otwórz ponownie pulpit Staging Pro: środowisko automatycznie wznowi kopiowanie w miejscu, w którym przerwało.

Czy staging może wysyłać e-maile do moich klientów? Nie, jeśli opcja „Wyłącz e-maile” jest aktywna (zalecane): wychodzące wiadomości są odcięte na stagingu.

Jak cofnąć zmiany po pushu? Użyj przycisku Rollback, który przywraca ostatni automatyczny backup. Następnie usuń nieaktualne tabele dfbak*.

Czy mogę utworzyć kilka stagingów jednocześnie? Tak, liczba środowisk jest nieograniczona, a każde z nich działa całkowicie niezależnie.

Staging odpowiada 404 wszędzie albo okno logowania się nie pojawia? To objaw naprawiony w wersji 1.0.1 na hostingach cPanel / LiteSpeed. Zaktualizuj moduł i uruchom Refresh środowiska; zobacz sekcję „Uwierzytelnianie HTTP a hostingi cPanel / LiteSpeed” powyżej.

Czy mogę utworzyć staging bez danych moich klientów? Tak, zaznacz „Bez danych klientów” przy tworzeniu. Zobacz sekcję „Staging bez danych klientów” powyżej.

Historia wersji

1.1.0 (4 września 2026)

• Nowa opcja „Bez danych klientów”: klienci, adresy klientów, zamówienia, koszyki, wiadomości, goście, newsletter i logi RODO tworzone jako puste na stagingu.
• Adresy dostawców, producentów i magazynów zachowane, podobnie jak tabele konfiguracyjne zamówień.
• Zabezpieczenie pusha: te tabele są usuwane z listy i odrzucane po stronie serwera na stagingu utworzonym bez danych klientów.

1.0.1 (3 września 2026)

• Ochrona htpasswd: hash generowany w formacie APR1-MD5, zgodnym z Apache i LiteSpeed (bcrypt był odrzucany na niektórych hostingach cPanel, przez co staging był niedostępny).
• Okno logowania HTTP: wbudowana strona 401 dla hostingów przekierowujących błędy 401 na nieistniejącą stronę.
• Linia ErrorDocument w .htaccess przepisana na podkatalog stagingu.
• Autotest po zakończeniu tworzenia: kontrola HTTP stagingu, automatyczne usunięcie ochrony, jeśli serwer ją odrzuca, oraz ostrzeżenie w panelu.

1.0.0 (11 czerwca 2026)

Pierwsza wersja publiczna.