Zmiana page buildera w WordPressie nie polega na zwykłym wyłączeniu jednej wtyczki i włączeniu drugiej. Każdy kreator zapisuje treść i układ strony w swoim formacie, dlatego migracja zwykle wymaga oczyszczenia treści oraz ręcznej budowy layoutu od nowa.
Dlaczego zmiana buildera może zepsuć stronę?
Page buildery, takie jak WPBakery, Elementor czy inne wizualne edytory, przechowują informacje o układzie strony w bazie danych WordPressa. Często wykorzystują do tego własne shortcode’y, czyli specjalne znaczniki interpretowane przez aktywną wtyczkę.
Po dezaktywacji starego narzędzia WordPress nie zawsze usuwa te dane. Na stronie mogą więc pojawić się ciągi przypominające [elementor-section], [vc_row] lub inne znaczniki. Dla przeglądarki i użytkownika są one zwykłym tekstem, a nie gotową sekcją, kolumną czy przyciskiem.
WPBakery i Elementor nie są ze sobą bezpośrednio kompatybilne. Nowy builder nie odczyta automatycznie wszystkich ustawień starego, takich jak marginesy, responsywność, animacje, klasy CSS czy niestandardowe moduły. Dlatego trzeba zaplanować migrację jako przebudowę treści, a nie wymianę jednej wtyczki na drugą.
Jak przygotować bezpieczną migrację?
Najpierw utwórz środowisko stagingowe, czyli kopię witryny przeznaczoną do testów. Nie zmieniaj buildera bezpośrednio na stronie produkcyjnej, zwłaszcza gdy witryna obsługuje klientów, formularze, sprzedaż lub integracje z zewnętrznymi usługami.
Przed rozpoczęciem prac sprawdź następujące elementy:
- Pełna kopia zapasowa – zapisz bazę danych oraz wszystkie pliki WordPressa, w tym motyw, wtyczki i katalog uploads.
- Środowisko stagingowe – skopiuj stronę na osobny adres lub instalację testową i wykonuj migrację właśnie tam.
- Kompatybilność motywu – sprawdź, czy aktywny motyw współpracuje z wybranym builderem i nie wymaga starej wtyczki.
- Lista zależności – zanotuj formularze, WooCommerce, pola niestandardowe, szablony, widżety i integracje, które mogą korzystać ze starego narzędzia.
Ostrzeżenie: dezaktywacja lub usunięcie page buildera nie oznacza automatycznego usunięcia shortcode’ów z treści. Bez kopii zapasowej błędne czyszczenie bazy danych może spowodować utratę zawartości albo ustawień strony.
Jak zmienić page builder na inny krok po kroku?
Najbezpieczniejsza procedura zakłada stopniowe przenoszenie zawartości. Nie usuwaj starego buildera, dopóki nie sprawdzisz, które strony i elementy nadal z niego korzystają.
- Spisz wszystkie podstrony, wpisy i szablony utworzone w starym builderze. Zapisz także adresy URL, użyte zdjęcia, formularze i niestandardowe moduły.
- Wykonaj kopię bazy danych i plików, a następnie utwórz staging. Zachowaj oryginalną wersję jako punkt powrotu.
- Wyeksportuj treść, którą można przenieść bezpośrednio, na przykład teksty, nagłówki, adresy URL i obrazy. Elementy layoutu zwykle trzeba odtworzyć ręcznie.
- Na stagingu usuń lub zastąp stare shortcode’y dopiero po sprawdzeniu, że ich zawartość została zachowana. Przydatne może być wyszukiwanie charakterystycznych znaczników w bazie.
- Zbuduj układ w nowym narzędziu. Odtwórz sekcje, kolumny, przyciski, formularze, obrazy, odstępy i ustawienia wersji mobilnej.
- Przetestuj każdą stronę na komputerze i urządzeniach mobilnych. Sprawdź formularze, linki, obrazy, menu, przekierowania, dane strukturalne i działanie WooCommerce, jeśli jest używany.
- Po akceptacji stagingu wykonaj nową kopię zapasową strony produkcyjnej i przenieś gotową wersję. Nie wyłączaj starego buildera przed zakończeniem testów.
Możesz spotkać wtyczki i narzędzia oferujące automatyczną konwersję między builderami. Ich działanie zależy jednak od wersji obu narzędzi, motywu, użytych dodatków i niestandardowego kodu. Automatyczna migracja może przyspieszyć przenoszenie prostych sekcji, ale nie gwarantuje zachowania wyglądu ani wszystkich funkcji.
| Metoda | Pracochłonność | Ryzyko błędów | Jakość kodu |
|---|---|---|---|
| Ręczna przebudowa | Duża, szczególnie przy rozbudowanej stronie | Niższe, jeśli prace odbywają się na stagingu | Łatwiej usunąć stare shortcode’y i uporządkować strukturę |
| Automatyczna konwersja | Mniejsza na początku | Wyższe, zwłaszcza przy dodatkach i niestandardowych polach | Wynik zależy od narzędzia, często wymaga ręcznego poprawiania |
Wybór metody zależy od liczby podstron, powtarzalności układów i złożoności witryny. Przy kilku prostych stronach ręczna przebudowa bywa szybsza niż późniejsze poprawianie niepełnej konwersji.
Jak oczyścić bazę danych po starym builderze?
Po migracji przeszukaj treści pod kątem shortcode’ów używanych przez poprzednią wtyczkę. Samo usunięcie jej plików nie usuwa znaczników zapisanych w tabelach bazy danych. Ich nazwy zależą od konkretnego narzędzia, dlatego najpierw ustal, jakie prefiksy występowały w witrynie.
Do wyszukiwania i zastępowania ciągów tekstowych można wykorzystać narzędzia typu Search and Replace. Przed każdą zmianą wykonaj kopię bazy i testuj operację na stagingu. Przy rozbudowanych instalacjach lepiej zlecić czyszczenie osobie, która rozumie strukturę bazy WordPressa.
Nie usuwaj hurtowo fragmentów kodu bez sprawdzenia, gdzie są używane. Shortcode może znajdować się nie tylko w treści strony, lecz także w widżetach, polach niestandardowych, szablonach lub opisach produktów. Pozostawione znaczniki pogarszają czytelność treści i mogą utrudniać dalszą edycję, a nieuporządkowany kod może zwiększać liczbę elementów renderowanych przez przeglądarkę.
Po czyszczeniu sprawdź również:
- czy na stronach nie wyświetlają się surowe shortcode’y ani puste kontenery,
- czy nie zostały nieużywane klasy CSS, skrypty i style starego buildera,
- czy obrazy mają prawidłowe adresy, rozmiary i teksty alternatywne,
- czy wersja mobilna, formularze, linki i funkcje sklepu działają tak jak przed migracją.
Czy lepiej zmienić builder, czy zbudować stronę od nowa?
Przy małej witrynie z kilkoma powtarzalnymi podstronami zmiana buildera jest zwykle możliwa do przeprowadzenia bez tworzenia całego serwisu od początku. Duży serwis z wieloma niestandardowymi polami, integracją WooCommerce lub zewnętrznym API może jednak wymagać większej przebudowy.
Jeśli stary układ jest niespójny, zawiera dużo ręcznych wyjątków i pozostałości po kilku narzędziach, budowa nowej struktury może kosztować mniej niż naprawianie efektów częściowej migracji. Niezależnie od wybranej metody, staging, pełna kopia zapasowa i etapowe testy są podstawą bezpiecznej zmiany.
