Najczęstsze problemy po migracji do Divi 5 – które są normalne, a które wymagają działania

Migracja do Divi 5 nie zawsze kończy się scenariuszem „kliknąłem i wszystko wygląda identycznie”. Czasem po przejściu na nową wersję buildera pojawiają się rzeczy, które budzą niepokój: ostrzeżenia w Compatibility Check, komunikat o Backward Compatibility Mode, mniej płynna edycja niektórych modułów albo layout, który wygląda prawie tak samo, ale jednak trochę inaczej.

To ważny moment, bo właśnie wtedy najłatwiej źle zinterpretować sytuację.

Nie każdy taki objaw oznacza awarię. Część z nich jest normalnym efektem przejścia między Divi 4 a nową architekturą Divi 5, a część faktycznie wymaga działania. Elegant Themes podkreśla, że unsupported modules, legacy modules i niektóre dodatki firm trzecich mogą po migracji nadal działać przez backward compatibility, a staging i Compatibility Check powinny być standardem przed przejściem na produkcję. 

Najprościej mówiąc: po migracji do Divi 5 nie chodzi o to, żeby nic się nie zmieniło. Chodzi o to, żeby wiedzieć, które zmiany są normalne, a które oznaczają, że projekt nadal nie wyszedł ze starej warstwy technicznej.

Nie każda zmiana po migracji oznacza błąd

 

To najważniejsza rzecz na początek.

Divi 5 ma nową architekturę, ale jednocześnie zachowuje zgodność wsteczną z Divi 4. Gdy system wykrywa legacy modules lub nieprzystosowane jeszcze dodatki, uruchamia starszy framework Divi 4 tylko tam, gdzie jest potrzebny. Strona może działać poprawnie, ale nie korzysta wtedy jeszcze z pełnych usprawnień Divi 5. 

To oznacza, że po migracji możesz zobaczyć rzeczy, które wyglądają groźnie, choć w praktyce są po prostu stanem przejściowym.

1. Compatibility Check pokazuje ostrzeżenia

 

To jeden z najczęstszych momentów niepokoju.

Po migracji raport Compatibility Check pokazuje pomarańczowe ostrzeżenia przy stronach, wpisach, Theme Builderze, bibliotece albo WooCommerce. Dla wielu użytkowników wygląda to jak lista błędów. Tymczasem ET tłumaczy, że ostrzeżenia najczęściej oznaczają obecność unsupported Divi 4 modules albo legacy third-party modules, które po migracji nadal będą działały przez compatibility mode. 

To nie musi oznaczać, że coś się zepsuło.

W praktyce raport mówi raczej:

• ten element działa,

• ale jeszcze nie działa natywnie na Divi 5.

 

Kiedy trzeba reagować

 

Warto reagować wtedy, gdy ostrzeżenia dotyczą:

• globalnych template’ów,

• kluczowych landing pages,

• WooCommerce,

• albo dużej liczby aktywnie używanych elementów.

 

Kiedy nie trzeba panikować

 

Jeśli ostrzeżenia dotyczą pojedynczych starszych layoutów albo mniej ważnych elementów biblioteki, może to być po prostu etap przejściowy.

2. Strona działa, ale nadal jest w Backward Compatibility Mode

 

To bardzo częsty scenariusz.

Projekt już działa na Divi 5, builder się otwiera, front jest poprawny, ale komunikat o compatibility mode nie znika. ET opisuje ten mechanizm jasno: jeśli na stronie znajdują się legacy modules albo niezgodne dodatki, Divi ładuje framework Divi 4 obok Divi 5, żeby zachować działanie tych elementów. 

To nie jest jeszcze awaria. To sygnał, że projekt nadal działa częściowo przez warstwę przejściową.

Najważniejsze jest więc to, żeby nie pytać tylko:

czy działa?

Lepiej zapytać:

czy działa już natywnie?

3. Dodatki firm trzecich nie działają natywnie

 

To jeden z najczęstszych realnych powodów, dla których projekt nie wychodzi z compatibility mode.

ET podaje wprost, że third-party modules i Marketplace products, które nie zostały jeszcze przepisane pod Divi 5, będą działały przez backward compatibility. W FAQ i dokumentacji ET rekomenduje sprawdzanie oznaczenia „Compatibility with Divi 5” bezpośrednio na stronie produktu w Divi Marketplace albo kontakt z autorem modułu. 

W praktyce użytkownik może widzieć:

• działający moduł,

• ale builder reagujący inaczej,

• warning w admin barze,

• i brak pełnych korzyści wydajnościowych Divi 5.

 

To nie znaczy, że Divi 5 „nie daje rady”. Bardzo często oznacza po prostu, że projekt nadal zależy od dodatku, który nie nadążył jeszcze za nową architekturą.

4. Builder działa wolniej albo mniej wygodnie przy niektórych modułach

 

To kolejny objaw, który często wygląda groźniej, niż jest w rzeczywistości.

ET opisuje, że legacy modules i niektóre third-party Divi 4 modules działające w backward compatibility mogą wymagać przeładowania po zmianach w builderze i nie korzystają z pełnej płynności natywnego Divi 5. To sprawia, że edycja staje się bardziej toporna, mimo że sam moduł nadal jest używalny. 

Czyli jeśli builder:

• reaguje wolniej,

• przeładowuje moduł po zapisaniu zmian,

• albo nie daje tak płynnego doświadczenia, jakiego oczekujesz po Divi 5,

 

to nie zawsze oznacza błąd samego buildera. Często to po prostu efekt pracy na legacy module.

5. Layout wygląda trochę inaczej niż przed migracją

 

To jeden z najbardziej „psychologicznych” problemów po migracji.

Strona niby wygląda dobrze, ale:

• spacing jest trochę inny,

• typografia wydaje się lekko przesunięta,

• jakiś element jest bardziej ciasny albo luźny niż wcześniej.

 

Nie musi to oznaczać, że Divi 5 „zepsuło layout”. Często migracja po prostu ujawnia starsze zależności:

• historyczne poprawki CSS,

• stare presety,

• globalne style,

• dziedziczenie ustawień, które wcześniej działało inaczej.

 

Warto pamiętać, że ET poprawia też bieżąco konkretne edge cases w compatibility mode, np. błędy spacingu w niektórych third-party D4 modules albo modułach działających przez legacy framework. 

Czyli nie każdy drobny wizualny rozdźwięk oznacza katastrofę. Czasem oznacza po prostu, że projekt niesie ze sobą starsze warstwy, które dopiero teraz wychodzą na wierzch.

6. Theme Builder albo biblioteka ciągną projekt w compatibility mode

 

To bardzo częsty i niedoceniany przypadek.

ET podaje, że Compatibility Check obejmuje nie tylko strony i wpisy, ale też Theme Builder templates, Divi Library items, WooCommerce products, custom post types i inne obszary projektu. 

To oznacza, że nawet jeśli zwykłe strony wyglądają dobrze, projekt nadal może być utrzymywany w compatibility mode przez:

• globalny header,

• footer,

• template wpisu,

• template archiwum,

• element z biblioteki używany w wielu miejscach.

 

I właśnie dlatego sama kontrola homepage nie wystarczy. Jeśli chcesz zrozumieć stan migracji, musisz patrzeć szerzej niż tylko na kilka głównych podstron.

7. Po migracji wszystko działa, ale nie czuć jeszcze Divi 5

 

To bardzo częsty zawód po pierwszej migracji.

Ktoś czyta o nowej architekturze Divi 5, o dynamicznym frameworku, modularnym JavaScripcie i lepszym ładowaniu zasobów, a potem migruje stronę i widzi:

• działający serwis,

• kilka warningów,

• trochę legacy modules,

• umiarkowaną zmianę.

 

I zadaje sobie pytanie:

to gdzie właściwie jest ten cały przeskok?

ET bardzo wyraźnie komunikuje, że pełne korzyści nowego silnika są najlepiej widoczne tam, gdzie projekt działa już natywnie na Divi 5 i nie ciągnie za sobą frameworka Divi 4. Dynamic Framework i Dynamic Assets w Divi 5 dają lean output i modularne ładowanie bibliotek, ale legacy elements utrzymujące compatibility mode ograniczają ten efekt. 

Czyli brak „efektu wow” po migracji nie musi oznaczać porażki. Często oznacza po prostu, że projekt jest jeszcze w połowie drogi.

Czego ten wpis nie powinien sugerować

 

To ważne, żeby powiedzieć to wprost.

Ten wpis nie oznacza, że:

• Divi 5 jest niestabilne,

• każda migracja kończy się problemami,

• warning = awaria,

• compatibility mode = porażka migracji.

 

ET jasno pokazuje, że backward compatibility jest częścią zaprojektowanego procesu przejścia, a nie sygnałem, że projekt „się rozsypał”. To pomost, który ma utrzymać działanie istniejących stron i dodatków, zanim projekt przejdzie w pełni na nową architekturę. 

Najczęściej problemem nie jest sam fakt, że coś działa przez compatibility mode. Problemem jest dopiero sytuacja, w której użytkownik uznaje to za stan końcowy i przestaje interesować się dalszym domykaniem migracji.

Jak sprawdzić, czy to naprawdę problem

 

Najlepiej przejść przez prosty schemat:

1. uruchom Compatibility Check,

2. sprawdź, których obszarów dotyczą ostrzeżenia,

3. ustal, czy chodzi o strony, Theme Builder, bibliotekę, WooCommerce czy pluginy,

4. sprawdź zgodność używanych dodatków firm trzecich,

5. oceń, czy problem dotyczy kluczowych elementów projektu,

6. dopiero potem decyduj, czy trzeba przebudować, wymienić moduł, poczekać na update autora czy na razie zostać przy compatibility mode.

 

ET zaleca staging, aktualizację WordPressa i pluginów oraz audit third-party Divi modules przed migracją właśnie po to, żeby takie rzeczy wychwycić przed wejściem na produkcję. 

Najważniejsze w 30 sekund

 

Po migracji do Divi 5 nie wszystko, co wygląda jak problem, jest błędem. Compatibility warnings, Backward Compatibility Mode czy mniej płynna edycja niektórych modułów często oznaczają po prostu, że projekt nadal korzysta z legacy elements albo dodatków firm trzecich bez pełnej zgodności z Divi 5. Trzeba odróżnić naturalny stan przejściowy od sytuacji, która naprawdę wymaga działania. 

Podsumowanie

 

Najczęstsze problemy po migracji do Divi 5 nie zawsze są awariami. Często są sygnałem, że projekt nadal niesie ze sobą:

• legacy modules,
• starsze template’y,
• dodatki firm trzecich,
• albo inne zależności od frameworka Divi 4.

 

To właśnie dlatego po migracji nie wystarczy spojrzeć na homepage i uznać temat za zamknięty.

Najważniejsze pytanie brzmi nie:

czy coś się zmieniło?

Lepiej zapytać:

czy to jest normalny efekt przejścia do Divi 5, czy sygnał, że projekt nadal nie wyszedł ze starej warstwy technicznej?

I dopiero od tej odpowiedzi zaczyna się naprawdę rozsądna migracja.