Sama migracja do Divi 5 to dopiero pierwszy etap. Prawdziwe pytania pojawiają się chwilę później, kiedy w panelu pojawia się raport Compatibility Check i trzeba zrozumieć, co on właściwie pokazuje.
Dla wielu użytkowników to właśnie ten moment jest najbardziej mylący. Strona działa. Builder się otwiera. Front wygląda poprawnie. A mimo to raport pokazuje zgodność tylko części elementów i sygnalizuje obszary, które nadal wymagają trybu kompatybilności.
Najważniejsze jest więc jedno: Compatibility Check nie odpowiada na pytanie, czy strona działa, tylko na ile działa już natywnie na Divi 5.
I właśnie tak najlepiej czytać ten raport.
Czym jest Compatibility Check w Divi 5
Compatibility Check to raport zgodności uruchamiany w trakcie migracji do Divi 5. Jego zadaniem nie jest naprawienie strony ani automatyczne rozwiązanie wszystkich problemów, ale pokazanie, które elementy projektu są już gotowe do działania na nowej architekturze, a które nadal opierają się na starszych rozwiązaniach.
Innymi słowy: to nie jest test „czy strona działa”, tylko mapa zgodności po migracji.
To ważne rozróżnienie, bo wiele osób intuicyjnie traktuje taki raport jak listę błędów. Tymczasem w praktyce jest to raczej raport stanu przejścia między Divi 4 a Divi 5.
Jakie obszary może obejmować raport
Raport Compatibility Check nie dotyczy wyłącznie jednej strony. Zwykle obejmuje różne części projektu, na przykład:
-
strony,
-
wpisy,
-
szablony Theme Buildera,
-
elementy biblioteki Divi,
-
produkty WooCommerce,
-
custom post types,
-
inne obszary, które zostały zbudowane z użyciem modułów Divi.
To oznacza, że wynik raportu trzeba czytać szerzej niż tylko z perspektywy jednego layoutu. Projekt może mieć zgodność w części stron, a jednocześnie nadal wymagać compatibility mode w szablonach, modułach albo elementach biblioteki.
Co raport pokazuje naprawdę
Raport Compatibility Check pokazuje przede wszystkim, gdzie w projekcie nadal znajdują się elementy zależne od starszej architektury Divi.
Jeśli dany obszar przechodzi test pozytywnie, oznacza to, że może działać natywnie na Divi 5.
Jeśli raport pokazuje ostrzeżenia albo zgodność warunkową, oznacza to najczęściej, że w tym miejscu nadal znajdują się:
-
legacy modules,
-
starsze układy wymagające trybu zgodności,
-
dodatki firm trzecich, które nie są jeszcze w pełni dostosowane,
-
elementy, które po migracji nadal uruchamiają Backward Compatibility Mode.
Czyli najprościej:
raport nie mówi „to działa” albo „to nie działa”.
Raport mówi raczej:
„to działa już natywnie” albo „to nadal działa przez warstwę zgodności”.
Czego ten raport nie mówi
To jest jeden z najważniejszych punktów.
Compatibility Check nie mówi automatycznie, że:
-
strona jest zepsuta,
-
migracja się nie udała,
-
Divi 5 nie działa,
-
trzeba wszystko przebudować od zera.
I właśnie tutaj najłatwiej o złą interpretację.
Projekt może działać poprawnie, a jednocześnie raport nadal może pokazywać elementy wymagające trybu zgodności. To nie musi oznaczać awarii. Oznacza tylko, że migracja nie została jeszcze domknięta w pełnym sensie technicznym.
Dlatego raport należy traktować bardziej jako narzędzie decyzyjne niż jako alarm.
Jak czytać wyniki rozsądnie
Najlepsze podejście jest dość proste.
1. Najpierw sprawdź, które sekcje mają ostrzeżenia
Nie patrz tylko na sam fakt, że raport coś sygnalizuje. Sprawdź dokładnie, gdzie pojawia się problem.
Czy dotyczy:
-
pojedynczych wpisów,
-
konkretnych stron,
-
szablonów Theme Buildera,
-
produktów WooCommerce,
-
elementów biblioteki,
-
modułów firm trzecich?
To robi dużą różnicę.
2. Oceń, czy chodzi o kluczowe obszary projektu
Ostrzeżenie przy mało używanym starym layoucie to jedno. Ostrzeżenie przy headerze, footerze albo głównym szablonie strony to coś zupełnie innego.
Dlatego raport trzeba czytać w kontekście:
-
co jest naprawdę używane,
-
co wpływa na cały projekt,
-
a co jest tylko starszym artefaktem w bibliotece.
3. Ustal, skąd bierze się brak pełnej zgodności
Najczęstsze przyczyny to:
-
starsze moduły Divi,
-
dodatki zewnętrzne,
-
biblioteka zbudowana jeszcze pod Divi 4,
-
szablony Theme Buildera,
-
elementy WooCommerce,
-
własne rozwiązania lub niestandardowe moduły.
Dopiero kiedy wiesz, co dokładnie utrzymuje compatibility mode, możesz zdecydować, co z tym zrobić.
4. Dopiero potem podejmij decyzję
Nie wszystko trzeba naprawiać natychmiast.
Czasem raport pokazuje obszary, które faktycznie wymagają przebudowy.
Czasem wskazuje tylko elementy, które możesz zostawić na później.
A czasem mówi po prostu, że projekt działa poprawnie, ale jeszcze nie korzysta w pełni z natywnego Divi 5.
Najczęstsze źródła ostrzeżeń w Compatibility Check
W praktyce raport najczęściej sygnalizuje problemy w kilku powtarzających się obszarach.
Legacy modules
To najczęstszy przypadek. Jeśli strona nadal korzysta z modułów z poprzedniej architektury, raport pokaże, że dany obszar nie działa jeszcze w pełni natywnie.
Dodatki firm trzecich
Jeśli używasz zewnętrznych rozszerzeń do Divi, one bardzo często są pierwszym kandydatem do compatibility mode. Sama migracja motywu nie sprawia automatycznie, że wszystkie marketplace modules nagle będą gotowe na Divi 5.
Theme Builder
Szablony globalne zawsze warto sprawdzać osobno. Nawet jeśli poszczególne strony wyglądają dobrze, ostrzeżenia w Theme Builderze mogą oznaczać, że cały projekt nadal opiera się częściowo na starszej logice.
Divi Library
Biblioteka bywa pełna elementów, które nie są już aktywnie używane, ale nadal istnieją w projekcie. Raport może je pokazać, mimo że nie mają dużego wpływu na bieżące działanie strony.
WooCommerce
Jeśli projekt korzysta z WooCommerce, raport zgodności nabiera jeszcze większego znaczenia. Produkty, szablony sklepu i moduły e-commerce to obszar, w którym zgodność warto czytać szczególnie uważnie.
Kiedy naprawdę trzeba reagować
Nie każdy komunikat w Compatibility Check wymaga natychmiastowej interwencji.
Możesz zachować spokój, jeśli:
-
strona działa poprawnie,
-
ostrzeżenia dotyczą pojedynczych starszych elementów,
-
problem dotyczy mniej ważnych obszarów,
-
dopiero kończysz migrację i wiesz, że część porządków jest jeszcze przed Tobą.
Reagować warto wtedy, gdy:
-
raport pokazuje dużo legacy modules,
-
ostrzeżenia dotyczą Theme Buildera lub kluczowych template’ów,
-
projekt ma działać już w pełni natywnie na Divi 5,
-
używasz dodatków, które nie mają jeszcze sensownej zgodności,
-
chcesz realnie korzystać z nowej architektury i jej potencjalnych korzyści.
Największym błędem nie jest sam raport z ostrzeżeniami.
Największym błędem jest uznanie, że skoro strona „jakoś działa”, to temat jest zamknięty.
Najważniejsze w 30 sekund
Compatibility Check w Divi 5 nie mówi, czy strona działa, tylko na ile działa już natywnie na nowej architekturze. Jeśli raport pokazuje ostrzeżenia, najczęściej oznacza to obecność legacy modules, dodatków firm trzecich albo elementów, które nadal uruchamiają Backward Compatibility Mode. Strona może działać poprawnie, ale migracja nie musi być jeszcze w pełni domknięta.
Jak najlepiej traktować ten raport
Najzdrowsze podejście jest takie:
-
nie panikuj,
-
nie ignoruj,
-
nie traktuj raportu jak listy błędów,
-
czytaj go jako mapę dalszych decyzji po migracji.
Compatibility Check pokazuje nie tyle awarie, co poziom przejścia projektu do natywnego Divi 5.
To właśnie dlatego jest tak ważny.
Bo w praktyce największy błąd po migracji polega często na tym, że użytkownik widzi działającą stronę i uznaje, że wszystko zostało zakończone. A raport zgodności przypomina, że technicznie może to być dopiero połowa drogi.
Podsumowanie
Raport Compatibility Check w Divi 5 najlepiej traktować nie jako listę problemów, ale jako narzędzie do oceny stanu migracji.
Pokazuje on:
-
które elementy projektu są już zgodne z natywnym Divi 5,
-
które nadal działają przez warstwę zgodności,
-
i gdzie warto jeszcze zajrzeć, zanim uznasz migrację za zamkniętą.
Najważniejsze pytanie po uruchomieniu raportu nie brzmi więc:
„czy coś jest zepsute?”
Lepiej zapytać:
„które części projektu nadal nie działają jeszcze natywnie na Divi 5?”
To właśnie z tej różnicy bierze się rozsądne czytanie całego raportu.
