Dodatki third-party a Divi 5 — które najczęściej blokują pełne przejście

Migracja do Divi 5 może przebiec poprawnie, strona może działać bez widocznych błędów, a mimo to projekt nadal nie wchodzi w pełni w natywną architekturę nowego buildera. Najczęściej powód jest prosty: w środku nadal znajdują się moduły albo dodatki, które uruchamiają Backward Compatibility Mode. Elegant Themes opisuje to wprost — jeśli layout zawiera unsupported Divi 4 modules albo legacy third-party modules, Divi ładuje framework Divi 4, żeby te elementy dalej działały. 

To bardzo ważne, bo wiele osób po migracji zadaje sobie pytanie: dlaczego strona nadal nie wychodzi z compatibility mode, skoro sam update już się udał?

Najczęściej odpowiedź nie brzmi: „coś się zepsuło”, tylko: projekt nadal korzysta z elementów, które nie mają jeszcze natywnej wersji dla Divi 5.

Co najczęściej blokuje pełne przejście na Divi 5

 

1. Moduły z Divi Marketplace, które nie mają jeszcze zgodności z Divi 5

 

To najczęstszy przypadek. ET wyraźnie podaje, że third-party Marketplace products mogą nie być jeszcze w pełni wspierane, a unsupported modules po migracji będą działać w compatibility mode z pewnymi ograniczeniami. Przed migracją Elegant Themes wręcz zaleca sprawdzenie, czy używane rozszerzenia mają oznaczenie Compatibility with Divi 5 na stronie produktu. 

W praktyce chodzi o:

• dodatkowe paczki modułów,

• rozszerzenia layoutowe,

• moduły marketingowe,

• elementy rozbudowujące builder,

• dodatki instalowane z myślą o Divi 4.

 

Jeśli ich autor nie przygotował jeszcze natywnej wersji pod Divi 5, projekt pozostanie częściowo na warstwie legacy.

2. Legacy modules z wcześniejszego projektu

 

ET podkreśla, że backward compatibility uruchamia się wtedy, gdy na stronie znajdują się legacy modules. Strona może działać normalnie, ale nie korzysta wtedy z pełnych usprawnień wydajnościowych Divi 5, dopóki te moduły nie zostaną zastąpione natywnymi wersjami. 

To często dotyczy stron, które były rozwijane przez długi czas i zawierają:

• stare układy z biblioteki Divi,

• historyczne sekcje kopiowane między projektami,

• moduły zachowane jeszcze z wcześniejszych wdrożeń,

• elementy, których nikt od dawna nie ruszał, bo „działają”.

 

Na froncie mogą wyglądać poprawnie, ale technicznie nadal utrzymują projekt w compatibility mode.

3. Dodatki firm trzecich używające legacy Divi 4 framework

 

Problemem nie są tylko same moduły dodawane do layoutu. ET zaznacza też, że compatibility warning może pojawić się wtedy, gdy któryś z pluginów korzysta z legacy Divi 4 framework. W takiej sytuacji strona nadal ładuje starą warstwę, nawet jeśli główne treści zostały już zmigrowane. 

To ważne, bo czasem użytkownik patrzy tylko na zawartość strony i nie widzi żadnych „starych modułów”, a projekt i tak nie wychodzi z compatibility mode. Właśnie dlatego sam Compatibility Check jest tak ważny — pokazuje, że problem może siedzieć głębiej niż w samym layoucie. 

4. Starsze szablony Theme Buildera

 

Migrator i Compatibility Check obejmują nie tylko zwykłe strony i wpisy, ale też Theme Builder templates. ET podaje, że raport zgodności pokazuje osobne sekcje dotyczące Pages, Posts, Theme Builder templates i innych obszarów projektu. 

To oznacza, że nawet jeśli homepage i kilka głównych stron działają już dobrze, projekt może nadal wpadać w compatibility mode przez:

• globalny header,

• footer,

• template wpisu,

• template archiwum,

• starszy układ produktu WooCommerce.

 

To częsty przypadek, bo Theme Builder zwykle gromadzi bardziej historyczne elementy niż zwykłe strony.

5. Starsze elementy z Divi Library

 

Podobny problem dotyczy biblioteki Divi. Migrator sprawdza także Divi Library items i raportuje, jeśli właśnie tam siedzą legacy modules albo unsupported components. 

To ważne, bo biblioteka bardzo często jest miejscem, gdzie zostają:

• dawne sekcje,

• zapomniane layouty,

• komponenty kopiowane z projektu do projektu,

• stare wzorce, które wciąż są używane w nowych miejscach.

 

Jeśli któryś z takich elementów trafia do aktywnego layoutu, compatibility mode wraca razem z nim.

6. Część starszych funkcji Divi 4, które nadal nie są w pełni wspierane

 

ET zaznacza też, że niektóre funkcje znane z Divi 4 nie są jeszcze w pełni wspierane. W dokumentacji i materiałach ET jako przykłady pojawiają się m.in. Quick Access, Full Site Editing czy Draggable Spacing. To nie zawsze będą moduły blokujące cały projekt, ale mogą być częścią szerszego obrazu: projekt nadal opiera się na elementach starego świata Divi 4. 

To nie znaczy, że wszystko się zepsuje. To znaczy tylko, że pełne przejście na Divi 5 może wymagać jeszcze cierpliwości albo przebudowy pewnych obszarów.

7. WooCommerce modules w starszych wdrożeniach

 

Tu sytuacja jest ciekawsza. ET wcześniej przyznawało, że Woo modules działały przez backward compatibility, a później zaczęły pojawiać się ich natywne wersje dla Divi 5. To oznacza, że na starszych wdrożeniach sklepowych część projektu mogła długo pozostawać w compatibility mode właśnie przez moduły WooCommerce. 

Jeśli projekt ma sklep, warto patrzeć szczególnie uważnie na:

• template produktu,

• archiwa sklepu,

• moduły produktowe,

• starsze układy checkoutu lub listingów.

 

Co blokuje przejście najczęściej w praktyce

 

Jeśli z tego wszystkiego zrobić bardzo prostą listę, to najczęściej pełne przejście na Divi 5 blokują:

• paczki modułów z Divi Marketplace bez natywnego wsparcia Divi 5, 

• legacy modules zostawione po starych layoutach, 

• pluginy korzystające z legacy Divi 4 framework, 

• starsze template’y w Theme Builderze, 

• elementy z Divi Library kopiowane między projektami, 

• niektóre obszary WooCommerce na starszych wdrożeniach. 

 

Czego nie sugerujemy

 

Warto też powiedzieć to wprost.

To, że projekt nadal korzysta z compatibility mode, nie oznacza automatycznie błędu. ET opisuje backward compatibility jako mechanizm pomostowy, który ma utrzymać działanie istniejących stron i dodatków, zanim zostaną one przebudowane do natywnego Divi 5. 

Czyli:

• strona może działać poprawnie,

• projekt może być bezpieczny do używania,

• migracja mogła się udać,

• ale pełne przejście na Divi 5 jeszcze się nie domknęło.

 

To ważna różnica.

Jak sprawdzić, co dokładnie blokuje przejście

 

Najlepsza droga jest dość prosta:

1. uruchom Compatibility Check,

2. sprawdź, które sekcje raportu mają ostrzeżenia,

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

4. sprawdź, czy używane dodatki mają oznaczenie zgodności z Divi 5,

5. dopiero potem decyduj, co przebudować, co wymienić, a co po prostu przeczekać.

 

ET zaleca dokładnie takie podejście: najpierw audit third-party modules, potem migracja, a przy większej liczbie niegotowych dodatków — nawet odłożenie migracji. 

Najważniejsze w 30 sekund

 

Najczęściej pełne przejście na Divi 5 blokują nie same strony, ale legacy modules i dodatki firm trzecich, zwłaszcza z Divi Marketplace, które nie mają jeszcze natywnej zgodności z Divi 5. Do tego dochodzą starsze szablony Theme Buildera, elementy z Divi Library i niektóre pluginy korzystające z trybu legacy Divi 4. Strona może działać poprawnie, ale dopóki te elementy pozostają w projekcie, Divi nadal będzie uruchamiać Backward Compatibility Mode. 

Podsumowanie

 

Pełne przejście na Divi 5 najczęściej blokuje nie sam builder, ale to, co projekt wnosi ze swojej historii:

• stare moduły,

• nieprzepisane dodatki,

• starsze template’y,

• komponenty z biblioteki,

• rozwiązania firm trzecich, które jeszcze nie nadążyły za nową architekturą.

 

To dlatego Compatibility Check jest tak ważny. Nie pokazuje tylko, czy coś „działa”, ale gdzie projekt nadal polega na starszej warstwie Divi 4.