Czym jest staging
Najprościej mówiąc, staging to testowa kopia strony, na której można bezpiecznie sprawdzać zmiany przed wdrożeniem ich na działającej witrynie.
To może być kopia:
na subdomenie,
na osobnym środowisku hostingowym,
albo w narzędziu stagingowym udostępnianym przez hosting.
Najważniejsze jest jedno: staging nie służy odwiedzającym, tylko Tobie.
To miejsce, w którym możesz:
zaktualizować motyw,
uruchomić migrację,
sprawdzić zgodność,
przetestować stronę po zmianach,
bez ryzyka, że coś zepsujesz na produkcji.
Jeśli więc produkcja to „prawdziwa” strona widoczna dla użytkowników, staging jest jej bezpieczną wersją roboczą do testów.
Migracja do Divi 5 nie zaczyna się w chwili kliknięcia przycisku aktualizacji. Zaczyna się dużo wcześniej — na etapie przygotowania środowiska testowego, w którym można spokojnie sprawdzić zgodność projektu, uruchomić Migrator i obejrzeć efekty bez ryzyka dla działającej strony.
To właśnie dlatego staging nie jest dodatkiem dla ostrożnych. Przy migracji z Divi 4 do Divi 5 staging powinien być standardem. Elegant Themes wprost zaleca pełny backup i wykonanie migracji najpierw na środowisku testowym, bo na bardziej złożonych stronach mogą pojawić się błędy migracji, problemy z third-party modules albo strony uruchamiające backward-compatibility mode.
Najprościej mówiąc: jeśli chcesz bezpiecznie wejść w Divi 5, najpierw zrób staging.
Po co staging przy migracji do Divi 5
Na prostych stronach aktualizacja może wyglądać niewinnie. Klikasz update, uruchamiasz Migrator i strona działa dalej. Problem w tym, że nie każda instalacja jest prosta.
Jeśli projekt ma:
-
dodatki firm trzecich,
-
własne moduły,
-
Theme Builder,
-
WooCommerce,
-
bibliotekę Divi z historycznymi layoutami,
-
niestandardowe poprawki dokładane przez lata,
to migracja staje się zmianą techniczną, a nie zwykłą aktualizacją motywu.
Staging daje Ci trzy rzeczy:
-
bezpieczne miejsce do testu,
-
możliwość cofnięcia decyzji bez presji,
-
realny obraz tego, co pokaże Compatibility Check i jak projekt zachowa się po migracji.
ET podaje też jasno, że najpierw warto zaktualizować WordPress, Divi i wszystkie pluginy, a dopiero potem uruchomić migrację na stagingu.
Czym właściwie jest staging
Staging to kopia strony działająca poza produkcją. Ma ten sam projekt, tę samą bazę i te same pliki, ale nie jest publiczną wersją serwisu, z której korzystają użytkownicy.
To ważne, bo migracja do Divi 5 jest jednokierunkowym przejściem przez Migrator. ET dopuszcza rollback, ale im dłużej pracujesz już na Divi 5 i edytujesz treści, tym trudniej o czysty powrót.
Czyli staging nie jest tylko miejscem „do popatrzenia”. To Twoja strefa bezpieczeństwa przed wejściem na nowy update path.
Co powinien zawierać staging przed migracją
Najlepszy staging to nie pusta instalacja WordPressa z samym Divi. To możliwie wierna kopia działającej strony.
Powinien zawierać:
-
bazę danych,
-
katalog uploads,
-
motyw i child theme,
-
wszystkie używane wtyczki,
-
bibliotekę Divi,
-
Theme Builder,
-
produkty WooCommerce, jeśli są używane,
-
niestandardowe typy wpisów i elementy zaplecza.
ET zaleca pełny backup całej strony, w tym bazy, uploads, motywów i pluginów, zanim w ogóle zaczniesz migrację.
Jeśli staging nie odtwarza realnego projektu, test będzie tylko pozornie uspokajający.
Jak przygotować staging krok po kroku
1. Zrób pełny backup strony produkcyjnej
To pierwszy krok, nie ostatni.
Backup powinien obejmować:
-
bazę danych,
-
pliki WordPressa,
-
uploads,
-
motywy,
-
pluginy.
Nie zakładaj, że „hosting coś tam robi”. Sprawdź, czy naprawdę masz pełną kopię.
2. Utwórz środowisko staging
Możesz to zrobić:
-
z poziomu hostingu, jeśli ma funkcję staging,
-
przez osobną subdomenę,
-
ręcznie jako kopię na osobnym środowisku.
Najważniejsze, żeby staging był:
-
odcięty od indeksacji,
-
niepubliczny lub chroniony,
-
i możliwie zbliżony do produkcji.
3. Zaktualizuj WordPress, Divi i wtyczki przed migracją
To ważne. ET pisze wprost, że uruchamianie migracji na przestarzałym WordPressie albo starych pluginach zwiększa ryzyko konfliktów.
Na stagingu najpierw doprowadź środowisko do aktualnego stanu, a dopiero potem myśl o Divi 5.
4. Sprawdź dodatki firm trzecich
Jeśli korzystasz z Divi extensions albo zewnętrznych modułów, sprawdź, czy są gotowe na Divi 5. ET rekomenduje wprost, żeby przed migracją upewnić się, czy third-party modules mają oznaczenie zgodności z Divi 5.
Jeśli kluczowe dodatki nie są gotowe, staging bardzo szybko pokaże, że to jeszcze nie jest dobry moment na przejście.
5. Włącz Divi 5 update path dopiero na stagingu
Na stagingu przechodzisz do:
Divi → Dashboard
i dopiero tam włączasz aktualizacje Divi 5, a potem wykonujesz update. ET opisuje ten proces jako osobną decyzję między ścieżką Divi 4 a Divi 5.
To ważne, bo nie chcesz eksperymentować ze ścieżką aktualizacji od razu na produkcji.
6. Nie otwieraj stron przed uruchomieniem Migratora
To bardzo ważny detal. ET ostrzega, że otwarcie strony w Divi 5 przed uruchomieniem Migratora może spowodować natychmiastową konwersję bez wygodnej drogi rollbacku. Najpierw uruchamiasz Migrator, dopiero potem oglądasz strony.
7. Uruchom Compatibility Check i przeczytaj raport
Dopiero teraz zaczyna się właściwy test.
Compatibility Check automatycznie skanuje:
-
Pages
-
Posts
-
Custom Post Types
-
Theme Builder Templates
-
WooCommerce Products
-
Divi Library Items
-
Widgets
-
Presets
i pokazuje, które elementy są gotowe na natywne Divi 5, a które zawierają unsupported modules. Pomarańczowe ostrzeżenia wskazują elementy, które po migracji będą działać w backward-compatibility mode.
8. Zrób migrację i testy po migracji
Jeśli raport wygląda sensownie, uruchamiasz Migrator.
Potem testujesz:
-
najważniejsze strony,
-
Visual Builder,
-
Theme Builder,
-
WooCommerce,
-
menu,
-
formularze,
-
działanie pluginów firm trzecich.
ET zaleca właśnie taki post-migration check na stagingu przed ruszeniem produkcji.
Co sprawdzić na stagingu po migracji
Najlepiej przejść prostą checklistę:
-
czy homepage wygląda poprawnie,
-
czy działają kluczowe landing pages,
-
czy builder otwiera się bez błędów,
-
czy Theme Builder nie zgłasza problemów,
-
czy WooCommerce działa prawidłowo,
-
czy nie pojawia się backward-compatibility tam, gdzie nie powinien,
-
czy third-party modules nie psują layoutu,
-
czy nie ma różnic w headerze, footerze i szablonach globalnych.
Przy bardziej złożonej stronie to właśnie ten etap daje prawdziwą odpowiedź, czy można iść dalej.
Najczęstszy błąd przy stagingu
Najczęstszy błąd to nie „brak stagingu”, tylko staging zrobiony byle jak.
Na przykład:
-
bez aktualnej bazy,
-
bez części pluginów,
-
bez biblioteki Divi,
-
bez WooCommerce,
-
bez szablonów,
-
albo z innym środowiskiem niż produkcja.
Wtedy człowiek mówi sobie: „na stagingu było dobrze”, ale test nie miał większej wartości.
Drugi częsty błąd to zbyt szybkie przejście:
-
update,
-
migracja,
-
dwa kliknięcia w builder,
-
„działa”.
A potem problemy wychodzą dopiero przy mniej oczywistych częściach projektu.
Kiedy staging pokazuje, że jeszcze nie warto migrować
Staging jest też po to, żeby uczciwie powiedzieć sobie „nie teraz”.
To może być dobra decyzja, jeśli:
-
Compatibility Check pokazuje dużo legacy warnings,
-
kluczowe third-party modules nie są zgodne z Divi 5,
-
projekt jest w środku wdrożenia i nie ma przestrzeni na poprawki,
-
Theme Builder lub WooCommerce zachowują się niestabilnie,
-
rollback byłby zbyt kosztowny.
ET podaje wprost, że pozostanie chwilowo na Divi 4 jest valid short-term decision, jeśli strona jest złożona albo oparta na niegotowych dodatkach. Jednocześnie Divi 4 ma mieć pełne wsparcie przez co najmniej 12 miesięcy od publicznej premiery Divi 5 z 26 lutego 2026.
Najważniejsze w 30 sekund
Przed migracją do Divi 5 zrób staging, bo to właśnie tam bezpiecznie sprawdzisz Compatibility Check, uruchomisz Migrator i ocenisz realny stan projektu po przejściu na nową architekturę. Staging powinien być możliwie wierną kopią produkcji, z tą samą bazą, pluginami, Theme Builderem i biblioteką Divi. ET zaleca backup i testy na stagingu jako standard przed migracją.
Podsumowanie
Bezpieczny staging przed migracją do Divi 5 nie polega na postawieniu pustej kopii WordPressa. Polega na stworzeniu środowiska, które naprawdę odtwarza projekt i pozwala uczciwie sprawdzić:
-
zgodność,
-
działanie po migracji,
-
wpływ third-party modules,
-
i gotowość strony do wejścia na Divi 5 update path.
Najlepsza decyzja, jaką możesz podjąć przed migracją, to nie „czy kliknąć update”, tylko:
czy mam staging, na którym naprawdę mogę to sprawdzić.





