Miért döntöttem úgy, hogy a WordPress Divi4 weboldalt Divi 5-re migrálom?
Egy WordPress weboldal migrálása Divi 4-ről Divi 5-re elsőre egyszerű technikai frissítésnek tűnhet
Mielőtt belevágnál az olvasásba, szeretnék szólni. Ha csak egy gyors választ keresel arra, hogy „érdemes-e Divi 5-re migrálni?”, akkor a rövid válaszom: Igen.
Ha viszont arra vagy kíváncsi, hogy mi történik egy valódi WordPress weboldallal a Divi 4 → Divi 5 migráció során, milyen hibákba futhatsz bele, hogyan lehet ezeket megoldani, és milyen tanulságokat vontam le a folyamatból, akkor jó helyen jársz.
Ez ugyanis nem egy mesterséges intelligencia által összegyűjtött elméleti útmutató. Nem egy átdolgozott sajtóközlemény. Nem egy olyan cikk, amelyet valaki úgy írt meg, hogy életében egyszer sem migrált még Divi weboldalt. Ez egy valós projekt története. Egy olyan WordPress weboldalé, amelyet ténylegesen Divi 4-ről Divi 5-re állítottam át. És igen…Voltak érdekes pillanatok.
Az út során találkoztam:
- rejtélyes fekete blokkal a lábléc alatt,
- eltűnő modulokkal,
- shortcode-ként megjelenő carousel elemekkel,
- visszatérő világoskék Divi gombokkal,
- makacs hover állapotokkal,
- elcsúszott ikonokkal,
- cache okozta hallucinációkkal,
- és olyan hibákkal is, amelyek végül egyetlen kattintással megjavultak.
A kedvencem talán az volt, amikor már fél órája a láblécet hibáztattam egy probléma miatt, majd kiderült, hogy valójában egy teljesen másik elem, a Back To Top gomb okozta az egészet. Ilyenkor az ember egyszerre érzi magát webfejlesztőnek, nyomozónak és pszichológusnak.
Azt is megtanultam, hogy Divi 5 migráció után nem szabad azonnal pánikba esni. A weboldal ugyanis sokszor nincs elromolva. Csak máshogy néz ki. És ez óriási különbség. Sőt, a folyamat végére egyre inkább azt éreztem, hogy a Divi 5 migráció nem egyszerűen egy frissítés. Sokkal inkább egy technikai audit.
Megmutatja, hogy az évek során milyen egyedi CSS-ek, pluginok, trükkök, gyorsjavítások és kreatív megoldások kerültek bele a weboldalba. Némelyik kellemes meglepetést okoz. Némelyik kevésbé. És még valami.
Ha idáig eljutottál, akkor szeretnélek figyelmeztetni. Ez a cikk végül olyan hosszú lett, hogy lassan külön irányítószámot lehetne igényelni hozzá. Közel 10.000 szó. Igen, jól olvastad. Ha mazochista vagy, imádod a WordPress weboldalakat, a Divit, a hibakeresést, a migrációkat és a technikai részleteket, akkor olvasd végig.
Ha nem vagy mazochista, akkor is olvasd végig. Csak készíts magad mellé egy kávét. Vagy kettőt. Én szóltam. 🙂
Ez a cikk egy valós Divi 4 → Divi 5 migráció története
Ránézésre csak annyi történik, hogy van egy régi Divi verzió, van egy új Divi verzió, és a kettő között le kell futtatni egy migrációs folyamatot. A gyakorlatban viszont ez ennél jóval összetettebb.
Ezt a cikket nem elméleti útmutatónak szánom, hanem egy valós projekt tapasztalati összefoglalójának. Egy működő WordPress weboldalon mentem végig a Divi 4-ről Divi 5-re történő átállás folyamatán, és közben több olyan hibával, vizuális eltéréssel, pluginproblémával és beállítási anomáliával találkoztam, amely más weboldaltulajdonosoknál, marketingeseknél vagy WordPress fejlesztőknél is előfordulhat.
A legfontosabb tanulság már az elején: nem kell azonnal megijedni, ha Divi 5 migrálás után valami furcsán néz ki. Attól, hogy egy gomb színe visszaáll, egy ikon nem úgy jelenik meg, egy háttérréteg máshogy viselkedik, vagy egy régi modul nem renderelődik megfelelően, még nem biztos, hogy a weboldal menthetetlenül elromlott. Sokszor nem strukturális hibáról van szó, hanem újraszámolási, kompatibilitási, cache-elési vagy örökölt stílusproblémáról.
Nálam is ez történt. A weboldal alapvetően működött, de több ponton látszott, hogy a Divi 5 már más logika szerint kezeli a szerkesztőfelületet, a modulokat, a globális sablonokat, a Theme Builder elemeket és bizonyos harmadik féltől származó megoldásokat.
A Divi 5 nem egyszerű kozmetikai frissítés. A háttérben komoly szerkezeti változás történt. Emiatt a migráció előtt érdemes másképp gondolkodni, mint egy szokásos WordPress bővítmény- vagy sablonfrissítésnél. Nem elég csak megnyomni a frissítés gombot, majd reménykedni, hogy minden tökéletes lesz. Itt előkészítésre, mentésre, kompatibilitási ellenőrzésre, vizuális átnézésre és szükség esetén kézi finomhangolásra van szükség.
Miért nem lehet már sokáig halogatni a Divi 5-re való átállást?
A Divi 5 iránya egyértelmű: gyorsabb szerkesztési környezet, modernebb háttérstruktúra, jobb teljesítmény és hosszú távon fenntarthatóbb alap. Aki Divi alapú WordPress weboldallal dolgozik, annak előbb-utóbb szembe kell néznie azzal, hogy a Divi 4-es rendszer nem maradhat örökké az elsődleges munkakörnyezet.
Ez különösen igaz olyan weboldalaknál, ahol nem csak néhány egyszerű szöveges oldal van, hanem összetett Theme Builder sablonok, egyedi fejlécek, globális láblécek, Divi Library elemek, harmadik féltől származó modulok, pop-upok, slide-in elemek, carousel megoldások, űrlapok, ikonblokkok, animációk és egyedi CSS-ek is működnek.
A hivatalos Divi dokumentáció szerint a Divi 5 migráció előtt érdemes biztonsági mentést készíteni, staging környezetben tesztelni, majd a Divi 5 Migrator segítségével kompatibilitási vizsgálatot futtatni. Ez azért fontos, mert a migrátor nem csak egyetlen oldalt néz meg, hanem a weboldal több kritikus részét is vizsgálja: oldalakat, bejegyzéseket, Theme Builder sablonokat, Divi Library elemeket és harmadik féltől származó modulokat is.
A halogatásnak tehát két oldala van. Egyrészt érthető, hogy egy működő ügyféloldalt nem szívesen bolygat az ember. Másrészt minél tovább gyűlnek a régi megoldások, egyedi CSS-ek, régi modulok és nem frissített bővítmények, annál nehezebb lehet később tisztán átállni Divi 5-re.
Én ezért nem úgy tekintek a Divi 5 migrációra, mint egy egyszerű frissítésre, hanem mint egy technikai állapotfelmérésre is. Ilyenkor derül ki igazán, hogy mennyire tiszta a weboldal szerkezete, mennyire stabilak a bővítmények, mennyire átlátható az egyedi CSS, és mennyi olyan régi megoldás maradt bent, amely Divi 4 alatt még működött, Divi 5 alatt viszont már hibát vagy vizuális eltérést okozhat.
Miben más a Divi 5, mint a Divi 4?
A Divi 5 egyik legfontosabb különbsége, hogy nem csak a kezelőfelület frissült, hanem a mögöttes működés is. A Divi 4-ben megszokott szerkesztési logika, modulkezelés és rövidkódos háttér több ponton más alapokra került. Ez önmagában jó irány, mert hosszú távon gyorsabb és tisztább rendszert eredményezhet, de átálláskor pont emiatt lehetnek kellemetlen meglepetések.
A saját tapasztalatom alapján a leggyakoribb eltérések nem feltétlenül abból adódnak, hogy a weboldal teljesen szétesik. Sokkal inkább abból, hogy bizonyos elemek máshogy örökölnek stílust, másképp számolódik újra egy méret, más lesz egy gomb hover állapota, vagy egy régi modul nem ugyanúgy viselkedik, mint korábban.
Például előfordulhat, hogy egy gomb háttérszíne nem ott van beállítva, ahol elsőre keresnéd. A modulban látszólag nincs beállítva háttérszín, mégis világoskék marad, mert a Divi alapértelmezett gombszínét örökli. Nálam konkrétan a #2EA3F2 szín jelent meg több helyen, miközben az arculati kék sötétebb volt. Ilyenkor nem elég azt mondani, hogy „rossz a gomb”, hanem meg kell nézni, honnan örökli a színt: modulbeállításból, globális Divi beállításból, CSS osztályból, pseudo-elemből vagy külső pluginból.
Ugyanez igaz a Theme Builder elemekre is. A globális fejlécben és láblécben lévő elemek különösen érzékenyek lehetnek. Ha ott van egy slide-in gomb, egy ikonmodul, egy social media blokk, egy egyedi header info elem vagy egy Divi Pixel / Divi Supreme modul, akkor migráció után ezeket külön végig kell ellenőrizni.
A Divi 5 tehát nem feltétlenül „rontja el” a weboldalt, hanem más rendszerbe helyezi át. A kérdés az, hogy az eredeti weboldal mennyire volt tisztán felépítve, mennyi egyedi módosítás volt benne, és a használt bővítmények mennyire vannak felkészítve Divi 5-re.
Miért nem szabad vakon rányomni a migrálásra?
Azért, mert egy WordPress weboldal ritkán csak a Divi sablonból áll. A legtöbb valódi ügyféloldalon van cache bővítmény, űrlapkezelő, SEO bővítmény, biztonsági bővítmény, egyedi child theme, saját CSS, esetleg Divi Supreme Pro, Divi Pixel, popup plugin, galéria modul, carousel, egyedi header vagy valamilyen külső integráció.
Ha ezek közül bármelyik nincs megfelelő állapotban, a migráció után lehetnek problémák. Nem feltétlenül végzetes problémák, de olyan hibák igen, amelyek időt visznek el. Például:
- egy carousel shortcode-ként jelenik meg a frontendben,
- egy slide-in gomb visszavált Divi alapkékre,
- egy ikon nem az arculati színt használja,
- a hover állapot külön színt kap,
- a Back to Top gomb eltorzul,
- egy háttérkép fölött a fehér szöveg olvashatatlanná válik,
- a mobilnézetben egy sor vagy oszlop másképp viselkedik,
- a Theme Builderben nem ott látszik a hiba, ahol a frontendben megjelenik.
A Divi 5 Migrator hivatalosan is arra szolgál, hogy a migráció előtt felmérje a kompatibilitást. A Divi 5 rendszerben van backward compatibility, vagyis visszafelé kompatibilitási mód is, amely bizonyos régi elemeket segíthet tovább futtatni. Ez viszont nem jelenti azt, hogy minden vizuális részlet automatikusan tökéletes lesz. A kompatibilitás nem ugyanaz, mint a pixelpontos megjelenés.
Én ezért azt javaslom, hogy Divi 5 migráció előtt ne az legyen a kérdés, hogy „rá merjek-e nyomni”, hanem az, hogy előtte megvolt-e a teljes előkészítés.
A biztonságos sorrend nálam így néz ki:
- teljes mentés készítése,
- pluginok frissítése,
- kritikus bővítmények Divi 5 kompatibilitásának ellenőrzése,
- staging környezet létrehozása,
- Divi 5 Migrator kompatibilitási ellenőrzés futtatása,
- migráció tesztkörnyezetben,
- fejléc, lábléc, főoldal, aloldalak, mobilnézet és űrlapok ellenőrzése,
- cache törlés,
- hibák dokumentálása,
- csak ezután élesítés.
Ez elsőre sok lépésnek tűnhet, de sokkal kevesebb idő, mint egy rosszul sikerült éles migráció után pánikszerűen visszaállítani a weboldalt.
A legfontosabb tanulság: nem kell azonnal megijedni, ha migrálás után szétesik valami
A Divi 5 migráció egyik legfontosabb pszichológiai része az, hogy ne ess pánikba az első vizuális hiba láttán. Ezt azért írom ilyen egyértelműen, mert egy régi Divi 4-es weboldalnál szinte biztos, hogy találsz majd valamit, ami nem pontosan úgy jelenik meg, mint korábban.
Lehet, hogy csak egy szín tér el. Lehet, hogy egy gomb hover állapota rossz. Lehet, hogy egy ikon világoskékre vált. Lehet, hogy egy régi modul szövegként írja ki a shortcode-ot. Lehet, hogy a Back to Top gomb furcsán nagy fekete elemként jelenik meg. Ezek ijesztőnek tűnnek, de nem feltétlenül jelentik azt, hogy a WordPress weboldal alapjaival van baj.
Nálam is volt olyan pont, amikor elsőre úgy tűnt, mintha a lábléc alatt egy teljesen ismeretlen fekete blokk jelent volna meg. Logikus lett volna azt gondolni, hogy a globális láblécben van egy elrontott szekció. De a Builderben nem látszott. A Theme Builder láblécében sem látszott. Végül kiderült, hogy nem is a lábléc volt a hibás, hanem a TOP / Back to Top gomb torzult el.
Ez tökéletes példája annak, hogy Divi 5 migráció után nem elég szemre keresni a hibát. A frontendben látható probléma nem mindig ott keletkezik, ahol vizuálisan megjelenik.
A weboldal sokszor működik, csak a megjelenés csúszik el
A migráció után fontos különválasztani két dolgot:
- működési hiba,
- megjelenési hiba.
Működési hiba az, amikor az oldal nem tölt be, 500-as hibát ad, adatbázis-kapcsolati hiba jelenik meg, nem működik a menü, nem működik az űrlap, vagy eltűnik egy kritikus funkció. Megjelenési hiba az, amikor az oldal betölt, a tartalom ott van, de egyes elemek színe, mérete, távolsága, hover állapota, ikonja vagy pozíciója eltér az eredetitől.
Divi 5 migráció után nagyon sok bosszantó hiba ebbe a második kategóriába tartozik. Ezek kellemetlenek, mert rontják a weboldal minőségérzetét, de általában javíthatók. Sokszor elég egy beállítás újramentése, egy érték kicsi módosítása, egy célzott CSS, vagy egy pluginfrissítés.
Volt olyan tapasztalatom is, hogy egy elem kiterjedése, szélessége vagy méretezése Divi 5 után furcsán viselkedett. Ilyenkor nem mindig kell az egész szakaszt újraépíteni. Előfordulhat, hogy bemész a méretezési vagy kiterjedési beállításokhoz, egy értéket eggyel feljebb, majd visszaállítasz, és az elem újraszámolja magát. Ez apróságnak hangzik, de migráció után sokszor pont ilyen apró újraaktiválás segít.
Gombok, színek, ikonok és méretek visszaállhatnak alapértelmezett értékre
A saját projektben az egyik visszatérő jelenség az volt, hogy bizonyos elemek visszavettek Divi alapértelmezett stílusokat. A leglátványosabb ilyen a világoskék gombszín volt. A gomb modulban látszólag nem volt háttérszín beállítva, mégis világoskék maradt. A Chrome DevTools mutatta meg, hogy a háttér valójában #2EA3F2.
Ez tipikusan olyan hiba, amelyet a Builderben elsőre nehéz megtalálni. A modul beállításaiban nem feltétlenül látszik, mert az érték öröklődik. Ilyenkor három irányból lehet keresni:
- Divi modul saját beállítása,
- globális Divi / Theme Builder beállítás,
- CSS vagy plugin által adott osztály.
A gomboknál külön figyelni kell a hover állapotra is. Nálam előfordult, hogy normál állapotban már jó volt a gomb sötétkék színe, de ha rámentem egérrel, visszaváltott világoskékre. Ez azért történt, mert a hover állapot külön szabályból jött. Ilyenkor nem elég a normál background-color értéket módosítani, hanem a hover, focus és active állapotokat is kezelni kell.
Ugyanez igaz az ikonokra. Egy beszédbuborék ikon például szintén Divi alapkéket örökölt, miközben az arculati színnek sötétebb kéknek kellett volna lennie. Ilyenkor célzottan az ikon színét kell módosítani, nem a teljes modul hátterét.
Miért bosszantó, de nem feltétlenül kritikus hiba a vizuális eltérés?
Azért, mert a vizuális eltérés nem mindig jelent tartalmi vagy technikai összeomlást. Ha egy WordPress weboldal betölt, a menü működik, a szövegek látszanak, az űrlapok elérhetők, az aloldalak megnyílnak, akkor már van stabil kiindulópontod. Innen lehet haladni hibáról hibára.
A veszély ott kezdődik, amikor valaki pánikból teljes visszaállítást indít, rossz mentést választ, vagy nem csak a WordPress fájlokat és adatbázist állítja vissza, hanem az egész tárhelyfiókot, domainbeállításokat, SSL-t, e-mail fiókokat és panelkonfigurációt is. Ezzel könnyen nagyobb bajt lehet okozni, mint maga a Divi 5 migrációs vizuális hiba.
Ezért fontos a higgadt hibakeresés. Először nézd meg, hogy működik-e az oldal. Utána nézd meg, hogy a hiba globális vagy csak egy adott oldalon jelenik meg. Majd keresd meg, hogy modul, Theme Builder, plugin, CSS vagy cache okozza-e.
A Divi 5 migráció nem mindig lesz teljesen sima, de a legtöbb probléma kezelhető, ha nem találgatva, hanem rendszerben gondolkodva mész végig rajta.
Biztonsági mentés nélkül ne kezdj bele Divi 5 migrációba
Ha egyetlen tanácsot kellene adnom azoknak, akik Divi 4-ről Divi 5-re szeretnének átállni, akkor ez lenne:
soha ne indítsd el a migrációt teljes biztonsági mentés nélkül.
Ezt nem azért mondom, mert a Divi 5 veszélyes vagy instabil lenne. Azért mondom, mert minden WordPress weboldal más. Más bővítmények futnak rajta, más egyedi CSS-ek vannak benne, más Theme Builder sablonok működnek a háttérben, és teljesen más lehet a korábbi fejlesztési története.
A saját tapasztalatom alapján a migráció utáni problémák jelentős része nem magából a Divi 5-ből ered, hanem abból, hogy a weboldal évek alatt rengeteg egyedi módosítást kapott. Ezek között lehetnek olyan elemek is, amelyekről már rég megfeledkeztünk, mégis hatással vannak az oldal működésére.
Éppen ezért a Divi 5 migráció előtt mindig úgy kell gondolkodni, mintha egy nagyobb rendszerfrissítést végeznél, nem pedig egy egyszerű pluginfrissítést.
Miért kell teljes mentés fájlokról, adatbázisról és feltöltésekről?
Egy WordPress weboldal valójában több részből áll.
Az első a fájlrendszer:
- WordPress magfájlok
- Divi sablon
- Child theme
- Bővítmények
- Egyedi PHP fájlok
- Feltöltött képek
- Dokumentumok
- Videók
A második az adatbázis:
- oldalak
- bejegyzések
- menük
- űrlapok
- Divi beállítások
- Theme Builder sablonok
- felhasználók
- SEO beállítások
Ha csak az egyik részről készítesz mentést, az nem teljes biztonsági mentés. Migráció előtt mindig olyan mentést készíts, amelyből szükség esetén az egész WordPress weboldal visszaállítható. A legrosszabb helyzet az, amikor valaki azt hiszi, hogy van mentése, majd kiderül, hogy csak az adatbázist mentette le, vagy csak a wp-content könyvtárat.
Ilyenkor a visszaállítás már nem olyan egyszerű.
JetBackup, cPanel, AIO WP Migration vagy tárhelyszintű mentés?
A gyakorlatban többféle mentési stratégia létezik.
JetBackup
Tárhelyszolgáltatóknál az egyik legkényelmesebb megoldás.
Előnye:
- gyors
- automatizált
- több korábbi mentés elérhető
- fájlok és adatbázis együtt kezelhető
Hátránya:
- sokan nem tudják pontosan, hogy mit állítanak vissza
A saját projektem során is találkoztam olyan helyzettel, amikor a JetBackup visszaállítás elsőre logikusnak tűnt, de valójában túl nagy területet érintett volna.
AIO WP Migration
Nagyon hasznos WordPress szinten.
Előnye:
- egyszerű
- gyors
- könnyen visszaállítható
Hátránya:
- nagy oldalaknál méretkorlátok lehetnek
- tárhelyszintű problémákat nem kezel
cPanel mentés
Haladóbb felhasználóknak.
Előnye:
- teljes kontroll
Hátránya:
- könnyű rossz helyre nyúlni
- több szakértelmet igényel
Tárhelyszolgáltatói mentések
Sok esetben a legbiztonságosabb megoldás.
Érdemes megkérdezni a szolgáltatót:
- milyen gyakran készül mentés
- hány napra visszamenőleg érhető el
- pontosan mit tartalmaz
Miért veszélyes teljes cPanel-fiókot visszaállítani, ha csak a WordPress weboldalt kell javítani?
Ez az egyik legfontosabb tanulság, amit sokan csak akkor tanulnak meg, amikor már baj van. Amikor JetBackup vagy cPanel visszaállítást indítasz, nem mindig csak a WordPress weboldalt állítod vissza.
Egy teljes fiókvisszaállítás érintheti:
- e-mail fiókokat
- SSL tanúsítványokat
- domain beállításokat
- cron feladatokat
- adatbázis felhasználókat
- panel konfigurációkat
Ha a probléma kizárólag a Divi 5 migráció után jelentkezett, akkor szinte biztosan nincs szükség teljes tárhelyfiók visszaállítására.
A legtöbb esetben elegendő:
- a WordPress fájlok
- és az adatbázis
visszaállítása. A teljes fiókvisszaállítás sokkal nagyobb beavatkozás.
Mikor elég csak a fájlokat és az adatbázist visszaállítani?
A Divi 5 migrációs problémák döntő többségénél.
Ha például:
- egy gomb színe elromlik
- a Theme Builder hibásan jelenik meg
- egy modul shortcode-ként látszik
- a fejléc szétesik
- egy popup nem működik
akkor ezek tipikusan WordPress szintű problémák.
Ilyenkor általában elegendő:
- fájlok visszaállítása
- adatbázis visszaállítása
- cache ürítése
- pluginok ellenőrzése
Nincs szükség:
- e-mail fiókok
- SSL tanúsítványok
- cron feladatok
- teljes cPanel környezet
visszaállítására.
Saját tapasztalat
A Divi 5 migráció során nálam is felmerült a visszaállítás gondolata, amikor több vizuális hiba jelent meg egyszerre. Utólag visszanézve szerencsére kiderült, hogy a legtöbb probléma nem adatvesztés vagy rendszerhiba volt.
Voltak:
- visszaállt színek
- hibás hover állapotok
- elcsúszott ikonok
- rosszul működő slide-in elemek
- shortcode-ként megjelenő Divi Supreme modulok
de maga a WordPress weboldal működött. Ez nagyon fontos különbség. Mielőtt mentésből visszaállítasz bármit, először döntsd el: valóban összeomlott a weboldal, vagy csak a megjelenés változott meg?
A két helyzet között óriási különbség van. Sok esetben néhány óra hibakeresés gyorsabb és biztonságosabb, mint egy teljes visszaállítás.
Staging környezet: a biztonságos Divi 5 migráció alapja
A következő nagy tanulság az volt, hogy a Divi 5 migrációt ideális esetben soha nem az éles weboldalon kell először lefuttatni.
Ez különösen igaz:
- ügyféloldalakra
- webáruházakra
- aktív érdeklődőgyűjtő oldalakra
- SEO szempontból fontos projektekre
A staging környezet pontosan azért létezik, hogy a hibák ott jelenjenek meg először, ne az éles oldalon.
A következő részben részletesen bemutatom:
- hogyan érdemes staging oldalt készíteni,
- mit kell ellenőrizni a migráció után,
- és miért a Theme Builder az egyik legérzékenyebb terület Divi 5 alatt.
Staging környezet: a biztonságos Divi 5 migráció alapja
Ha ma újra végigmennék egy Divi 4 → Divi 5 migráción, akkor egy dolgot biztosan másképp csinálnék: először staging környezetben tesztelnék mindent. Sok WordPress weboldal tulajdonos úgy gondolkodik, hogy ha van mentés, akkor nyugodtan lehet kísérletezni az éles oldalon. Elméletileg ez igaz. Gyakorlatban azonban egy visszaállítás mindig idő, stressz és bizonytalanság.
Egy staging oldal viszont lehetőséget ad arra, hogy minden hibát előre megtalálj. A saját projektem során több olyan probléma is előkerült, amelyek ugyan nem okoztak működésképtelenséget, de éles oldalon kellemetlen meglepetést jelentettek volna:
- színek visszaállása
- hibás hover effektek
- Divi Supreme modulok megjelenítési problémái
- slide-in elemek hibái
- Theme Builder anomáliák
- ikonok elcsúszása
- háttér overlay problémák
Ha ezek először egy tesztkörnyezetben jelennek meg, sokkal nyugodtabban lehet javítani őket.
Miért ne az éles weboldalon tesztelj először?
Azért, mert az éles weboldal általában nem csak neked fontos.
Ott vannak:
- a látogatók
- az ügyfelek
- az ajánlatkérések
- a telefonhívások
- a kapcsolatfelvételi űrlapok
- a Google által indexelt tartalmak
Ha egy Divi 5 migráció után szétesik a fejléc, eltűnik egy CTA gomb vagy hibás lesz egy popup, akkor ezek közvetlenül hatással lehetnek a konverziókra.
Sokan ilyenkor azt mondják: „Majd gyorsan kijavítom.”
- A probléma az, hogy nem tudod előre, milyen hibák jelennek meg.
- Lehet, hogy öt perc alatt javítható.
- Lehet, hogy három órás hibakeresés lesz belőle.
A staging környezet pontosan ezt a bizonytalanságot veszi ki a folyamatból.
Hogyan készíts staging környezetet?
Erre több módszer is létezik.
Tárhelyszolgáltatói staging
Ez a legkényelmesebb.
Sok modern tárhelyszolgáltató egyetlen kattintással létrehoz:
- staging.domain.hu
- test.domain.hu
- dev.domain.hu
aloldalt.
Ilyenkor a rendszer lemásolja:
- a fájlokat
- az adatbázist
- a WordPress beállításokat
és külön környezetben dolgozhatsz.
AIO WP Migration
Ha nincs staging funkció a tárhelyen, akkor létrehozhatsz egy külön aldomaint.
Például:
staging.domain.huvagy
dev.domain.huUtána:
- új WordPress telepítés
- AIO WP Migration export
- AIO WP Migration import
Néhány perc alatt kész a tesztkörnyezet.
Kézi klónozás
Haladó felhasználóknak.
Itt:
- másolni kell a fájlokat
- létre kell hozni új adatbázist
- módosítani kell a wp-config.php fájlt
Ez teljes kontrollt ad, de több hibalehetőséget is.
Mit ellenőrizz staging oldalon a migráció után?
Ez az a pont, ahol a legtöbb ember hibázik.
- Lefuttatja a migrációt.
- Ránéz a főoldalra.
- Működik.
- Örül.
- Élesíti.
- Majd másnap jönnek a hibajelzések.
A helyes folyamat:
Fejléc
Ellenőrizd:
- logó
- menü
- hamburger menü
- CTA gombok
- telefon ikon
- e-mail ikon
- slide-in elemek
Nálam több hiba is itt jelent meg először.
Lábléc
Nézd meg:
- közösségi ikonok
- kapcsolatfelvételi adatok
- űrlapok
- copyright rész
A migráció során nálam egy hatalmas fekete blokk jelent meg a lábléc alatt, amelyről először azt hittem, hogy a lábléc hibája. Később kiderült, hogy a TOP gomb okozta.
Főoldal
Különösen figyelj:
- hero szekció
- háttérképek
- overlay-ek
- CTA blokkok
- ikonok
- animációk
Aloldalak
A legtöbb hiba nem a főoldalon jelenik meg.
Sokszor:
- szolgáltatásoldalakon
- blogcikkekben
- egyedi landing page-eken
buknak ki a problémák.
Mobilnézet, fejléc, lábléc, gombok, pop-upok és űrlapok ellenőrzése
A Divi 5 migráció után külön ellenőrzőlistát készítettem.
Minden oldalon megnéztem:
Mobilnézet
- logó
- menü
- hamburger ikon
- CTA gombok
- ikonok
- távolságok
Gombok
- háttérszín
- hover állapot
- ikonok
- kattinthatóság
Popupok
- megjelennek-e
- működik-e a bezárás
- helyes-e a színük
Slide-in elemek
Nálam több probléma is ezeknél jelentkezett.
Például:
- visszaálló világoskék szín
- hibás hover állapot
- ikonelcsúszás
Űrlapok
Ellenőrizni kell:
- kapcsolatfelvételi űrlap
- ajánlatkérő űrlap
- hírlevél feliratkozás
- popup űrlap
Mert ezek azok az elemek, amelyek közvetlenül bevételt termelnek.
Saját tapasztalat
A migráció során többször előfordult, hogy elsőre komoly hibának tűnő jelenségről később kiderült:
- cache probléma
- örökölt CSS
- plugin kompatibilitási kérdés
- hover állapot
- újraszámolási hiba
Volt olyan elem is, amely egyszerűen attól megjavult, hogy a Divi 5-ben megnyitottam a méretezési beállítást, egy értéket módosítottam, majd visszaállítottam. A Divi 5 sok esetben újraszámolja a modulokat. Ezért migráció után mindig végig kell menni az oldalon modulról modulra.
Nem azért, mert a Divi 5 rossz.
Hanem azért, mert a régi Divi 4-es struktúrák és az új Divi 5-ös rendszer között vannak olyan különbségek, amelyek csak használat közben derülnek ki.
Divi 5 Migrator: mit ellenőriz, és miért fontos a Compatibility Scan?
Sokan azt hiszik, hogy a migráció ott kezdődik, amikor megnyomják a Divi 5 frissítés gombot. Valójában a folyamat ennél sokkal korábban indul. Az egyik legfontosabb eszköz a Divi 5 Compatibility Scan, amelyet az Elegant Themes kifejezetten azért készített, hogy még a migráció előtt felmérhesd a weboldalad állapotát.
A következő részben részletesen bemutatom:
- hogyan működik a Divi 5 Compatibility Scan,
- mit vizsgál a Migrator,
- milyen hibákat találhat meg előre,
- és miért érdemes komolyan venni a figyelmeztetéseit.
Divi 5 Migrator: mit ellenőriz, és miért fontos?
A legtöbb WordPress weboldal tulajdonos ott követi el az első hibát, hogy a Divi 5 migrációt egy egyszerű frissítésként kezeli.
- Megjelenik a Divi 5 lehetősége.
- Megnyomja a gombot.
- Majd reménykedik benne, hogy minden rendben lesz.
A valóságban a Divi fejlesztői pontosan tudták, hogy a világon több százezer olyan weboldal fut, amely évek óta Divi 4 alatt működik, ezért a Divi 5 migrációs folyamatot külön ellenőrző rendszerrel egészítették ki.
Ez lett a Compatibility Scan és a Divi 5 Migrator.
A célja egyszerű:
még a migráció előtt megmutatni, hogy hol lehet probléma. Ha ezt a lépést kihagyod, gyakorlatilag vakon indulsz neki a folyamatnak.
Oldalak, bejegyzések, Theme Builder sablonok és Divi Library elemek vizsgálata
A Compatibility Scan nem csak a főoldalt ellenőrzi. Ez nagyon fontos. Sokan megnyitják a kezdőlapot, látják, hogy működik, és azt gondolják, hogy minden rendben. A valóságban a problémák nagy része nem a főoldalon jelentkezik.
A Divi Migrator ellenőrzi többek között:
- oldalakat
- bejegyzéseket
- Theme Builder sablonokat
- Divi Library elemeket
- globális modulokat
- mentett szekciókat
- globális fejléceket
- globális lábléceket
Ez azért fontos, mert egy sokéves WordPress weboldalon rengeteg olyan elem lehet, amelyet már nem használsz aktívan, mégis része a rendszernek.
Előfordulhat például, hogy:
- egy régi landing oldalban van egy inkompatibilis modul
- egy globális fejléc tartalmaz egy régi beállítást
- egy Divi Library elem használ elavult struktúrát
A migráció után ezek ugyanúgy problémát okozhatnak.
Harmadik féltől származó modulok és bővítmények ellenőrzése
A saját tapasztalataim alapján ez az egyik legkritikusabb pont. A legtöbb komoly Divi alapú WordPress weboldal ma már nem csak Diviből áll.
Gyakori kiegészítők:
- Divi Supreme Pro
- Divi Pixel
- Divi Booster
- Divi Areas Pro
- Divi Overlays
- WooCommerce modulok
- popup rendszerek
- slider rendszerek
- egyedi modulcsomagok
A Compatibility Scan külön figyeli a külső modulokat is. Ez azért lényeges, mert a Divi 5 hiába működik tökéletesen, ha egy külső modul fejlesztője még nem készítette el a kompatibilis verziót.
A saját projektjeimnél például mindig végignézem:
- a plugin gyártójának weboldalát
- a changelogot
- a dokumentációt
- a támogatási fórumot
mielőtt elindítom a migrációt.
Miért nem szabad figyelmen kívül hagyni a figyelmeztetéseket?
Sokan úgy gondolkodnak: „Majd migrálok, aztán lesz valami.” Ez általában rossz stratégia. Ha a Compatibility Scan hibát jelez, annak oka van. Nem biztos, hogy kritikus. Nem biztos, hogy azonnal összeomlik tőle a weboldal. De valószínűleg időt fogsz veszíteni miatta.
A saját tapasztalataim szerint sokkal gyorsabb:
- előre javítani
- előre frissíteni
- előre ellenőrizni
mint utólag hibát keresni.
A Compatibility Scan nem azért van, hogy megijesszen. Azért van, hogy megmutassa, mire kell figyelned.
Bővítmények ellenőrzése migrálás előtt
Ha csak egyetlen területet emelhetnék ki a Divi 5 migráció kapcsán, akkor az a bővítmények kompatibilitása lenne. A legtöbb migrációs probléma nem a Divi magjából ered. Hanem abból, hogy a weboldalon futó bővítmények egy része még Divi 4 logikára épül.
Ez különösen igaz azokra a pluginokra, amelyek:
- saját modulokat adnak a Builderhez
- saját popup rendszert használnak
- saját carousel elemeket tartalmaznak
- saját header funkciókat biztosítanak
Miért kell felkeresni minden fontos bővítmény gyártói oldalát?
Mert a WordPress admin felületen látható „Frissítés elérhető” üzenet önmagában nem jelent Divi 5 kompatibilitást.
Két külön dologról beszélünk:
- WordPress kompatibilitás
- Divi 5 kompatibilitás
Egy plugin lehet tökéletesen kompatibilis a legfrissebb WordPress verzióval, miközben bizonyos Divi 5 funkciókkal még problémái vannak.
Migráció előtt mindig ellenőrzöm:
- hivatalos weboldal
- changelog
- dokumentáció
- support fórum
- Facebook csoportok
- GitHub vagy fejlesztői közlemények
információit.
Divi Supreme Pro és Divi 5 kompatibilitás
A saját migrációm során külön figyelmet kapott a Divi Supreme Pro.
Ennek egyszerű oka van: a weboldalon Divi Supreme modulok működtek.
Például:
- Image Carousel
- slider elemek
- egyedi design modulok
A migráció előtt ezért külön utánanéztem a gyártó dokumentációjában, hogy a legfrissebb Divi Supreme Pro verzió támogatja-e a Divi 5-öt. Ez olyan lépés, amelyet minden plugin esetében érdemes megtenni.
Divi Pixel, slide-in popupok, custom header elemek és extra modulok
A másik gyakori terület a Divi Pixel. A saját projektben is több olyan elem volt, amely később kiderült, hogy Divi Pixel komponens.
Például:
- slide-in elemek
- popup megoldások
- header CTA elemek
- egyedi ikonblokkok
Migráció után ezeknél jelentkeztek:
- színproblémák
- hover hibák
- ikonpozíció hibák
- örökölt stílusok
Nem azért, mert a plugin rossz. Hanem azért, mert a Divi 5 alatt másképp öröklődtek bizonyos beállítások.
Mi történhet, ha egy Divi 4-es modul nem kompatibilis Divi 5-tel?
Ez az a helyzet, amelyre fel kell készülni.
A leggyakoribb tünetek:
- modul eltűnik
- hibás megjelenítés
- shortcode jelenik meg
- design szétesik
- szerkesztő hibát mutat
A saját migrációm során pontosan találkoztam egy ilyen jelenséggel. Egy ponton nem a modul jelent meg a frontendben. Hanem maga a shortcode. Elsőre ijesztő volt. De valójában fontos diagnosztikai információt adott. Megmutatta, hogy a rendszer nem tudja renderelni az adott modult. A következő fejezetben pontosan ezt a helyzetet fogom bemutatni. Azt, amikor a Divi Supreme carousel helyett maga a shortcode jelent meg a weboldalon, és hogyan sikerült megtalálni a probléma valódi okát.
Saját tapasztalat: eltűnő vagy hibásan megjelenő Divi Supreme shortcode-ok
A Divi 5 migráció során az egyik első igazán látványos hibával akkor találkoztam, amikor egy teljesen jól működő carousel elem egyszer csak eltűnt. Pontosabban nem eltűnt. Valami sokkal furcsább történt. A látogatók nem a carousel-t látták. Hanem magát a shortcode-ot.
Valami ilyesmit:
[dsm_image_carousel ...]
Első pillanatban ez meglehetősen ijesztő látvány. Főleg akkor, ha egy ügyféloldalon jelenik meg. Az ember ilyenkor hajlamos arra gondolni, hogy:
- összeomlott a weboldal
- elromlott a Divi
- hibás lett a migráció
- vissza kell állítani az egész rendszert
A valóság azonban sokkal árnyaltabb volt.
Amikor a carousel helyett shortcode jelenik meg az oldalon
A konkrét esetben egy Divi Supreme modulról volt szó. Korábban tökéletesen működött. A logók megfelelően görögtek. A carousel szépen jelent meg. A migráció után viszont a frontendben már nem maga a modul renderelődött. Hanem a shortcode jelent meg. Ez egy nagyon fontos hibajelenség.
Mert ilyenkor a WordPress gyakorlatilag azt mondja:
„Látom a shortcode-ot, de nem tudom feldolgozni.”
Ez teljesen más helyzet, mint amikor egy modul hibásan jelenik meg. Itt a renderelés folyamata áll meg.
Miért jelent meg a [dsm_image_carousel] szöveg a frontendben?
A hibakeresés során több lehetőség is felmerült.
1. A plugin nem fut
Ez a leggyakoribb ok.
Ha a Divi Supreme plugin:
- kikapcsolódik
- megsérül
- hibás verzió fut
- nem kompatibilis a Divi 5-tel
akkor a shortcode mögötti feldolgozó rendszer nem indul el. Ilyenkor maga a shortcode jelenik meg.
2. Nem megfelelő verzió fut
Ez különösen fontos.
Sok felhasználó úgy gondolkodik:
„A plugin friss.”
Ez nem ugyanaz, mint a Divi 5 kompatibilitás.
Lehet, hogy a plugin:
- WordPress kompatibilis
- PHP kompatibilis
de még nem Divi 5 kompatibilis.
Ezért migráció előtt mindig ellenőrizni kell a fejlesztő oldalát.
3. Cache probléma
Ez meglepően gyakori. A LiteSpeed Cache, Cloudflare vagy más gyorsítótárazó rendszer régi állapotot szolgálhat ki.
Ilyenkor előfordulhat, hogy:
- a plugin már javítva van
- a cache viszont még a hibás állapotot mutatja
Ezért a hibakeresés első lépései közé mindig bekerül:
- LiteSpeed Purge All
- böngésző cache törlés
- Ctrl + F5
- inkognitó mód
Mit jelent, ha egy külső modul nem renderelődik?
A Divi 5 migráció során ezt nagyon fontos megérteni.
Ha egy külső modul nem renderelődik: az még nem jelenti azt, hogy az egész weboldal hibás. Sőt. Sokszor maga a WordPress tökéletesen működik. A Divi is működik. Csak az adott külső modul nem. Ez óriási különbség.
A hibakeresés során mindig először azt kell eldönteni:
- rendszerhiba történt
- vagy csak egy konkrét modul hibás
A kettő között nagyságrendi különbség van.
Pluginfrissítés, cache törlés és modul újraellenőrzés
A saját tapasztalatom alapján ilyenkor ezt a sorrendet érdemes követni.
1. Plugin verzió ellenőrzése
Meg kell nézni:
- melyik verzió fut
- van-e frissebb verzió
- szerepel-e a changelogban a Divi 5 támogatás
2. Plugin gyártójának weboldala
Mindig ellenőrizd:
- dokumentáció
- support
- release notes
- kompatibilitási információk
3. Cache ürítése
LiteSpeed esetén:
- Purge All
Cloudflare esetén:
- Purge Cache
Utána:
- Ctrl + F5
4. Modul újraellenőrzése
Nyisd meg:
- Visual Builder
- Wireframe mód
és nézd meg:
- valóban Divi Supreme modul van-e ott
- nincs-e hibás shortcode
- nincs-e sérült modulbeállítás
Saját tanulság
Ez volt az egyik első olyan hiba, amely megtanított arra, hogy Divi 5 migráció után nem szabad rögtön a legrosszabbra gondolni. A shortcode megjelenése elsőre drámainak tűnik.
Valójában viszont sokszor csak azt jelenti, hogy:
- a plugin nem kompatibilis
- a plugin nincs aktiválva
- a plugin hibás verziója fut
- cache probléma van
Ezek általában javíthatók. A valódi veszély nem ez. A valódi veszély az, amikor a hibát félrediagnosztizáljuk, és emiatt feleslegesen kezdünk teljes visszaállításokba vagy újraépítésbe.
A Theme Builder külön figyelmet igényel Divi 5 migráció után
A migráció során egy idő után egyre világosabbá vált számomra, hogy a weboldal legérzékenyebb része nem az egyes oldalak tartalma volt.
- Nem a blogcikkek.
- Nem a szolgáltatásoldalak.
- Nem a képek.
- Hanem a Theme Builder.
A legtöbb komoly Divi alapú WordPress weboldal ma már használ:
- globális fejlécet
- globális láblécet
- egyedi body sablonokat
- kategória sablonokat
- blog sablonokat
- egyedi post template-eket
És ezek migráció után külön ellenőrzést igényelnek.
A következő részben bemutatom:
- milyen hibákat találtam a Theme Builderben,
- miért nem mindig ott látszik a hiba, ahol keletkezik,
- és hogyan jutottam el végül a híres „fekete blokk a lábléc alatt” probléma valódi okához.
A Theme Builder külön figyelmet igényel Divi 5 migráció után
A Divi 5 migráció során egy idő után rájöttem valamire. A legtöbb probléma nem az oldalakon jelentkezett.
- Nem a blogcikkeknél.
- Nem a szolgáltatásoldalakon.
- Nem a képeknél.
Hanem a Theme Builderben. Ez teljesen logikus, ha belegondolsz. A Theme Builder az a terület, amely szinte az egész weboldalt vezérli.
Itt található:
- a globális fejléc
- a globális lábléc
- az egyedi sablonok
- a blog sablonok
- a kategória sablonok
- a speciális oldalsablonok
Ha itt valami hibázik, akkor az nem egyetlen oldalon fog megjelenni. Hanem az egész weboldalon. Éppen ezért a Divi 5 migráció után a Theme Builder az egyik legfontosabb ellenőrzési pont.
Globális fejléc hibák
A fejléc szinte minden oldalon jelen van. Ha itt van probléma, azt a látogatók azonnal észreveszik. A saját migrációm során több olyan jelenség is előkerült, amely elsőre teljesen érthetetlennek tűnt.
Például:
- gombok visszaálltak Divi alapkékre
- hover effektek megváltoztak
- ikonok más színt kaptak
- CTA elemek elveszítették az eredeti megjelenésüket
A legérdekesebb az volt, hogy több esetben a modulbeállításokban minden jónak tűnt. A gomb háttérszíne például nem volt beállítva világoskékre. Mégis világoskék volt. A háttérben ugyanis öröklődési probléma állt. A Divi alapértelmezett színe visszavette az irányítást. Ilyenkor a megoldás nem feltétlenül a Builderben található. Sokszor csak a Chrome DevTools segítségével derül ki, hogy valójában honnan öröklődik az adott stílus.
Globális lábléc hibák
A lábléc szintén kritikus terület. A migráció során itt találkoztam az egyik legfurcsább hibával. A weboldal látszólag rendben működött. A lábléc is rendben volt. Aztán egyszer csak megjelent egy hatalmas fekete blokk az oldal legalján.
Első pillanatban teljesen logikusnak tűnt, hogy a probléma a láblécben van. Hiszen ott jelent meg.
Elkezdtem átnézni:
- globális láblécet
- sorokat
- modulokat
- közösségi ikonokat
- kapcsolatfelvételi elemeket
És semmit nem találtam.
A Theme Builderben egyszerűen nem látszott az a fekete blokk. Ez később nagyon fontos tanulsággá vált. A frontendben megjelenő hiba nem mindig ott keletkezik, ahol látod.
Egyedi body, custom footer és template override problémák
A Divi 5 migráció során különösen figyelni kell azokra a projektekre, ahol:
- egyedi body template van
- custom footer fut
- több sablon dolgozik együtt
- külön blog sablon készült
- külön kategória sablon készült
Minél összetettebb a rendszer, annál több helyen jelenhet meg eltérés. Ez nem feltétlenül a Divi hibája. Egyszerűen arról van szó, hogy a Divi 5 másképp dolgozza fel a korábban létrehozott struktúrákat.
Miért nem mindig látszik a hiba a Visual Builderben?
Ez az egyik legfontosabb tapasztalat, amit a migráció során szereztem. A frontend és a Builder nem mindig ugyanazt mutatja.
Előfordulhat, hogy:
- a frontend hibás
- a Builder tökéletesnek látszik
vagy éppen fordítva.
Ezért migráció után mindig két helyen kell ellenőrizni:
Builder nézetben
Itt látod:
- modulokat
- sorokat
- szekciókat
- sablonokat
Frontend nézetben
Itt látod:
- a valódi renderelt oldalt
- a CSS öröklődést
- a pluginok által generált elemeket
- a cache által kiszolgált verziót
A fekete blokkos hiba tökéletes példa volt erre. A Builderben nem látszott. A frontendben viszont igen. És emiatt teljesen rossz irányba indult a hibakeresés.
Konkrét hiba: hatalmas fekete blokk jelent meg a lábléc alatt
Ez volt az a pillanat, amikor egy rövid hibajavításból komoly nyomozás lett.
- A weboldal működött.
- A fejléc működött.
- A tartalom működött.
- A lábléc működött.
Mégis ott volt az oldal alján egy hatalmas fekete téglalap. Ami ráadásul úgy nézett ki, mintha a lábléc része lenne. Minden arra utalt, hogy a probléma a Theme Builder láblécében található. Csakhogy nem ott volt.
Miért tűnt először láblécproblémának?
A fekete blokk közvetlenül a lábléc alatt jelent meg.
Ezért teljesen logikus volt a feltételezés:
„Valami elromlott a láblécben.”
Elkezdtem végignézni:
- globális footer
- sorok
- modulok
- ikonok
- közösségi média elemek
Még a Wireframe nézetet is. És semmi. A Builder egyszerűen nem mutatta azt az elemet, amely a frontendben látszott. Ilyenkor könnyű rossz irányba indulni.
Hogyan derült ki, hogy a TOP / Back to Top gomb okozta?
A megoldás végül egy egyszerű tesztből született. Elkezdtem kizárásos alapon haladni.
- Mi történik, ha ezt kikapcsolom?
- Mi történik, ha azt kikapcsolom?
- Mi történik, ha ezt eltávolítom?
Végül eljutottam a Divi beépített:
Back To Top funkciójához. Amikor kikapcsoltam… a fekete blokk eltűnt. Azonnal.
Ez volt az a pillanat, amikor kiderült:
- nem a lábléc hibás.
- Nem a Theme Builder hibás.
- Nem a modul hibás.
- Hanem a TOP gomb jelenített meg egy hibásan formázott elemet.
Miért torzulhat el egy lebegő gomb Divi 5 migráció után?
A Divi 5 migráció során több okból is előfordulhat ilyen jelenség.
Például:
- örökölt CSS
- régi child theme stílus
- plugin beavatkozás
- egyedi kód
- hibás hover állapot
- pseudo-element probléma
A frontend ilyenkor nem magát a gombot jeleníti meg hibásan. Hanem annak valamelyik háttérelemét. Ezért tűnhet úgy, mintha egy teljesen ismeretlen fekete blokk jelent volna meg.
Megoldás: TOP gomb kikapcsolása vagy CSS javítása
A diagnózis után már egyszerűbb volt a helyzet.
Két lehetőség maradt:
1. Kikapcsolni a Back To Top funkciót
Ez gyors megoldás. A fekete blokk azonnal eltűnik.
2. Megkeresni a hibás CSS-t
Ez időigényesebb. Viszont hosszú távon jobb.
A Chrome DevTools segítségével végül pontosan azonosíthatóvá vált, hogy melyik elem okozza az anomáliát.
Saját tanulság
Ez az eset tökéletesen megmutatta, miért nem szabad találgatni. A hiba helye és a hiba oka két teljesen különböző dolog lehet. Ha kizárólag a láblécet néztem volna, valószínűleg órákat töltök el teljesen feleslegesen.
A Divi 5 migráció során ezért a legfontosabb szabály: Ne azt keresd, hogy hol látszik a hiba. Azt keresd, hogy mi generálja. A kettő nem mindig ugyanaz.
Konkrét hiba: a Divi alapértelmezett világoskék színe visszajött
A következő hibával valószínűleg nagyon sok Divi felhasználó találkozni fog. Elsőre apróságnak tűnik. Valójában viszont az egyik legidegesítőbb jelenség. Nálam több gomb, ikon és slide-in elem egyszer csak visszaváltott a Divi jól ismert világoskék színére. A probléma azért volt különösen megtévesztő, mert a Builderben első ránézésre nem látszott semmilyen hibás színbeállítás.
A következő részben megmutatom:
- hogyan derült ki, hogy a háttérben a #2EA3F2 dolgozik,
- hogyan segített a Chrome DevTools,
- miért nem mindig ott van a szín beállítva, ahol keresed,
- és hogyan lehet végleg megszüntetni az ilyen öröklődési problémákat.
Konkrét hiba: a Divi alapértelmezett világoskék színe visszajött
A fekete blokkos probléma után azt hittem, hogy a nehezén már túl vagyok. Tévedtem. A következő hiba sokkal alattomosabb volt. Nem okozott működési problémát. Nem omlott össze a weboldal. Nem tűntek el modulok. Mégis azonnal szemet szúrt. A Divi migráció után több helyen visszatért a jól ismert világoskék Divi szín. Ha régóta dolgozol Divivel, biztosan találkoztál már vele.
A pontos szín:
#2EA3F2
Ez a Divi egyik alapértelmezett kék árnyalata. A probléma csak az volt, hogy az adott projekt egyáltalán nem ezt a színt használta. Az arculati szín sötétkék volt. Mégis több helyen újra megjelent a világoskék.
Miért jelent meg újra a #2EA3F2 szín?
Elsőre teljesen logikátlannak tűnt. Megnyitottam a gomb beállításait. Nem volt ott. Megnéztem a modul háttérszínét. Nem volt ott. Megnéztem a sor beállításait. Nem volt ott. Megnéztem a szekciót. Ott sem volt. A frontend viszont makacsul világoskék maradt.
Ez az a pont, ahol sokan órákra elakadnak. A Divi 5 migráció után ugyanis előfordulhat, hogy bizonyos elemek nem a korábban beállított értékeket használják, hanem újra elkezdik örökölni a Divi alapértelmezett stílusait. A szín tehát nem feltétlenül ott található, ahol elsőre keresnéd.
Hogyan segített a Chrome DevTools?
Ez volt az a pillanat, amikor a Builder már nem adott elég információt. Előkerült a Chrome DevTools. Ha Divi 5 migráció után hibát keresel, ez az egyik legfontosabb eszközöd.
A folyamat egyszerű:
- F12
- Elem kijelölése
- Kattintás a problémás elemre
Amikor kijelöltem a világoskék gombot, a DevTools azonnal megmutatta:
background: #2EA3F2;
Ezzel végre kiderült, hogy valóban a Divi alapkéke jelenik meg. A következő lépés már csak az volt, hogy megtaláljam, honnan örökli.
Gomb háttérszín öröklődése Divi alapbeállításból
Ez az egyik leggyakoribb Divi 5 migrációs jelenség. A Builderben úgy tűnik, hogy nincs háttérszín. Valójában azonban a modul örököl.
A háttérben lehet:
- globális gombstílus
- Theme Builder beállítás
- Divi Pixel elem
- Divi Supreme elem
- egyedi CSS
- pseudo-element
A saját projektemben végül több helyen is kiderült, hogy nem közvetlen háttérszín volt beállítva. Hanem örökölt stílus működött. Ezért nem találtam meg elsőre.
Ikonok, CTA gombok és slide-in gombok színproblémája
A migráció után nem csak a gombokkal volt probléma. Az ikonok is érintettek voltak.
Például:
- telefon ikon
- beszédbuborék ikon
- CTA elemek
- slide-in indító gombok
Több helyen ugyanaz a világoskék jelent meg. Ez azért fontos felismerés, mert ilyenkor nem különálló hibákról beszélünk. Hanem ugyanannak a stílusöröklési problémának több megjelenési formájáról. Sokszor egyetlen globális szabály több helyen is hibás megjelenést okoz.
Megoldás: modulon belüli beállítás vagy célzott CSS felülírás
A javítás módja mindig a konkrét helyzettől függ.
A legjobb megoldás: először a Builderben javítani. Ha a modul szintjén beállítható a szín, akkor ott érdemes módosítani.
Csak akkor nyúlj CSS-hez, ha:
- a Builder nem mutatja a problémát
- az érték öröklődik
- külső plugin generálja a stílust
A saját projektemben több esetben végül célzott CSS felülírás oldotta meg a problémát. De csak azután, hogy pontosan kiderült, honnan érkezik a hibás szín.
Saját tanulság
A Divi 5 migráció után ne abból indulj ki, hogy amit látsz, az ott van beállítva. Nagyon sok esetben nem. A Builder és a frontend nem mindig ugyanazt mutatja.
A szín lehet:
- örökölt
- generált
- plugin által hozzáadott
- globális stílusból származó
Ezért a DevTools használata gyakorlatilag kötelező.
Konkrét hiba: hover állapotban visszaváltott a gomb világoskékre
Miután sikerült kijavítani a gomb normál állapotát, azt hittem, hogy a probléma megoldódott. A gomb végre a megfelelő sötétkék színt használta. Aztán rávittem az egeret. És újra világoskék lett. Pontosan ugyanazzal a színnel. Ez az a típusú hiba, amely különösen frusztráló tud lenni. Az ember látja, hogy a javítás működik. Majd egyetlen hover állapot lerombolja az egészet.
Miért nem elég csak a normál állapotot módosítani?
A weboldalak többsége ma már több állapotot kezel.
Például:
- normál
- hover
- focus
- active
A Divi 4 alatt ezek sok esetben automatikusan együtt mozogtak. A Divi 5 migráció után viszont előfordulhat, hogy külön öröklődnek.
Ezért fordulhat elő az a jelenség, hogy:
- normál állapot jó
- hover állapot hibás
Hover, focus és active állapotok kezelése
A hibakeresés során kiderült, hogy a gombnak több különálló stílusa van. A normál állapot javítása önmagában nem elegendő. A hover állapot külön szabályból érkezett. Ezért vált vissza újra világoskékre.
A tanulság egyszerű! ha színt javítasz, mindig ellenőrizd:
- hover
- focus
- active
állapotban is.
Mikor kell globális CSS-t használni?
Ideális esetben soha. A gyakorlatban viszont előfordul, hogy szükség van rá.
Különösen akkor, ha:
- külső plugin generálja az elemet
- örökölt stílus okozza a hibát
- a Builder nem mutatja a valódi forrást
Ilyenkor a célzott CSS felülírás gyors és stabil megoldás lehet.
Miért kell óvatosan bánni az Előtte és Utána CSS mezőkkel?
Ez egy olyan tanulság, amelyet a saját hibámból tanultam meg. A hover probléma javítása közben elkezdtem az:
- Előtte (Before)
- Utána (After)
mezőkkel dolgozni. Elsőre logikusnak tűnt. A végeredmény viszont meglepő lett. A gombon lévő grafikai elemek elcsúsztak. A kis vonalak rossz helyre kerültek. A design szétesett. A következő fejezet pontosan erről fog szólni.
Arról, hogyan tud egyetlen rossz pseudo-element szabály teljesen összezavarni egy egyébként tökéletesen működő gombot.
Konkrét hiba: a gomb ikonrétege elcsúszott
A Divi 5 migráció során volt egy olyan hiba is, amely elsőre teljesen jelentéktelennek tűnt. Aztán kiderült, hogy egyetlen CSS módosítás több órás hibakeresést okozhat. A történet egy egyszerű gombbal kezdődött.
- A gomb színe nem volt megfelelő.
- A hover állapot hibás volt.
- A cél egyszerűnek tűnt:
- javítani a színt.
A probléma az volt, hogy a javítás során olyan CSS mezőkhöz nyúltam, amelyek nem csak a színt kezelték. Hanem a gomb grafikai elemeit is.
Miért csúsztak fel a kis vonalkák a gombon?
A Divi és több Divi-alapú bővítmény is használ úgynevezett pseudo-elemeket. Ezeket általában nem látod a Builderben. A háttérben működnek.
Leggyakrabban:
:before
:after
formában.
Ezek rajzolhatnak:
- animációkat
- ikonokat
- díszítőelemeket
- háttércsíkokat
- hover effekteket
- nyilakat
- grafikai vonalakat
A saját projektemben egy olyan CTA gomb szerepelt, amelynek a jobb oldalán egy különleges grafikai elem jelent meg. A gomb maga működött. A szín működött. Viszont amikor módosítottam a pseudo-elementek hátterét, a dekoráció teljesen elcsúszott. A kis vonalak felugrottak. A design szétesett. Elsőre úgy tűnt, mintha a Divi 5 migráció okozta volna. Valójában én okoztam a hibát.
Hogyan tud belenyúlni a pseudo-element az ikonrajzolásba?
Ez azért fontos, mert sok Divi felhasználó nem is tud róla, hogy egy adott elem mögött pseudo-elemek dolgoznak.
A Builderben gyakran csak ezt látod:
- gomb
- ikon
- szöveg
A háttérben azonban a plugin vagy a sablon több különálló rétegből építi fel az elemet.
Például:
- maga a gomb
- egy háttérréteg
- egy animációs réteg
- egy dekorációs réteg
Ha egy CSS szabály rossz helyre kerül, akkor nem csak a színt módosítja. Hanem a teljes rétegszerkezetet. Ez történt nálam is.
Mit ne írj az Előtte és Utána mezőkbe?
A migráció során az egyik tanulság az volt, hogy a Divi:
- Előtte (Before)
- Utána (After)
mezőit csak akkor érdemes használni, ha pontosan tudod, mit csinálsz. Sokan úgy kezelik ezeket, mint egyszerű CSS mezőket. Valójában viszont ezek közvetlenül a pseudo-elementeket módosítják.
- Ha például ide háttérszínt írsz:
- megváltozhat az animáció
- eltűnhet egy ikon
- elcsúszhat egy dekoráció
- hibás lehet a hover effekt
Ezért a saját gyakorlatomban ma már az a szabály: először mindig a modul saját beállításaiban keresem a megoldást. A pseudo-elementekhez csak végső esetben nyúlok.
Saját tanulság
A Divi 5 migráció során nagyon könnyű összekeverni a migrációs hibát és a saját javítás közben okozott hibát. A két dolog nem ugyanaz.
Ha egy módosítás után jelenik meg a probléma, mindig gondold végig:
- valóban a migráció okozta?
- vagy egy későbbi beavatkozás?
Nálam ez az eset utólag hasznos tanulság lett. Megtanított arra, hogy a Divi 5 hibakeresés során mindig kis lépésekben haladjak.
- Egy módosítás.
- Mentés.
- Ellenőrzés.
- Újabb módosítás.
- Mentés.
- Ellenőrzés.
Így sokkal könnyebb visszakeresni, hogy pontosan mi okozta a problémát.
Konkrét hiba: háttérképen nem volt olvasható a fehér szöveg
A következő problémát valószínűleg szinte minden webdesigner és WordPress fejlesztő ismeri. A háttérkép gyönyörű volt. A szöveg jól nézett ki a Builderben. A frontendben viszont alig lehetett elolvasni. A Divi 5 migráció után több helyen is azt vettem észre, hogy a korábban megfelelően működő hero szekciók másképp viselkednek.
- Nem omlottak össze.
- Nem tűntek el.
- Egyszerűen elvesztették az olvashatóságukat.
Miért romolhat az olvashatóság migráció után?
A legtöbb esetben nem maga a szöveg változik. Hanem a háttér viselkedése.
Például:
- más lesz a kép pozíciója
- más lesz a kép méretezése
- megváltozik a háttér overlay
- eltűnik egy korábbi árnyékolás
- megváltozik a kontraszt
Ilyenkor a szöveg ugyanott marad. Csak éppen nem emelkedik ki eléggé a háttérből.
Háttér overlay használata Divi 5-ben
A saját projektemben végül a legegyszerűbb megoldás működött. Nem a szöveget módosítottam. Nem a képet cseréltem le. Hanem egy finom overlay réteget tettem a háttérkép fölé.
Ez sokszor elegánsabb megoldás, mint:
- nagyobb betűméret
- vastagabb betűtípus
- erősebb árnyék
Az overlay segít megtartani a kép hangulatát, miközben javítja az olvashatóságot.
Mikor jobb sötét overlay-t használni világos szöveghez?
A gyakorlatban szinte mindig.
Ha a szöveg:
- fehér
- világosszürke
- világoskék
akkor általában a sötét overlay működik a legjobban. A saját projektben több hero szekciónál is ezt használtam. Az eredmény azonnal látható volt.
- A szöveg kiemelkedett.
- A háttérkép megmaradt.
- A design pedig professzionálisabb lett.
Ajánlott értékek: rgba(0,0,0,0.20–0.30)
Tapasztalatom szerint a legtöbb esetben nincs szükség erős sötétítésre.
A legjobban működő értékek:
rgba(0,0,0,0.20)
vagy
rgba(0,0,0,0.25)
vagy
rgba(0,0,0,0.30)
30% fölött már gyakran túl sötét lesz a kép. 20–30% között viszont általában tökéletes egyensúly érhető el.
Saját tanulság
A Divi 5 migráció után nem csak hibákat kell keresni. Érdemes újraértékelni a design egyes részeit is. Több helyen azt vettem észre, hogy egy apró módosítás:
- overlay
- kontraszt
- árnyék
- háttérbeállítás
látványosabb eredményt hozott, mint amit az eredeti Divi 4-es verzióban használtam. Ez az egyik pozitív oldala a migrációnak. Nem csak javítási lehetőség. Hanem egyfajta minőségi audit is.
Méretezési hibák Divi 5 után: néha elég egy apró újraállítás
A következő jelenség annyira furcsa volt, hogy elsőre magam sem hittem el. Bizonyos elemek hibásan jelentek meg. Majd egyetlen kattintás után megjavultak.
A következő részben bemutatom:
- hogyan működik a Divi 5 újraszámolási logikája,
- miért segíthet egy méretérték apró módosítása,
- és miért nem kell minden hibás szekciót újraépíteni a nulláról.
Méretezési hibák Divi 5 után: néha elég egy apró újraállítás
A Divi 5 migráció során volt egy olyan jelenség, amelyet elsőre szinte lehetetlen volt logikusan megmagyarázni.
Bizonyos elemek:
- rossz szélességben jelentek meg,
- elcsúsztak,
- furcsa térközöket kaptak,
- a sorok másképp viselkedtek,
- egyes blokkok túl keskenyek vagy túl szélesek lettek.
Az első reakcióm természetesen az volt, hogy valami komoly migrációs hiba történt. Aztán elkezdtem vizsgálni az egyes elemeket. És ekkor jött az egyik legfontosabb Divi 5 tanulság.
Néha nem hibás a modul, csak újraszámolásra van szüksége
A Divi 5 mögött teljesen új rendszer dolgozik. A régi Divi 4-es struktúrák egy része ugyan kompatibilis marad, de a rendszer sok esetben újraszámolja:
- a méreteket,
- a szélességeket,
- a paddingokat,
- a marginokat,
- a kiterjedéseket,
- a responsive értékeket.
Itt találkoztam egy érdekes jelenséggel.
- Egy elem hibásan jelent meg.
- Megnyitottam a beállításait.
- Bementem a méretezéshez.
- A szélességet eggyel feljebb állítottam.
- Majd visszaállítottam az eredeti értékre.
Mentés. És a probléma megszűnt. Elsőre véletlennek tűnt. Később azonban több alkalommal is ugyanez történt.
A „feljebb-lejjebb kattintás” módszer
Ez az egyik olyan tapasztalat, amelyet még nem nagyon láttam dokumentálva.
Ha Divi 5 migráció után egy elem:
- rossz szélességű,
- rossz magasságú,
- elcsúszott,
- furcsa pozícióban jelenik meg,
akkor érdemes megpróbálni a következőt. Nyisd meg az elemet.
Menj ide:
Tervezés → Méretezés
vagy
Tervezés → Kiterjedés
Ezután:
- növeld meg az értéket,
- mentsd el,
- állítsd vissza az eredetire,
- mentsd újra.
Meglepően sok esetben ez elég ahhoz, hogy a Divi 5 újraszámolja az elemet.
Nem minden hibát kell újraépíteni
Ez nagyon fontos. Sok felhasználó az első vizuális eltérésnél elkezdi:
- újraépíteni a sort,
- újraépíteni a szekciót,
- újra létrehozni a modult.
Pedig sokszor nincs szükség erre. A saját projektemben több alkalommal is előfordult, hogy egy látszólag hibás elem valójában teljesen ép volt. Egyszerűen a Divi 5 nem számolta újra megfelelően az adott értéket. Amint új mentést kapott, minden helyreállt.
Kiterjedés, padding és margin problémák
A migráció után különösen érdemes ellenőrizni:
Padding
Gyakori hibák:
- túl nagy felső térköz,
- eltűnt alsó térköz,
- mobilon túl szűk megjelenés.
Margin
Tipikus tünetek:
- elemek egymásra csúsznak,
- túl nagy távolság jelenik meg,
- szekciók között furcsa üres hely keletkezik.
Kiterjedés
A saját tapasztalatom szerint ez az egyik legérzékenyebb terület.
Különösen:
- teljes szélességű soroknál,
- hero szekcióknál,
- CTA blokkoknál,
- egyedi fejléceknél.
Mobilnézetben külön ellenőrizni kell
A Divi 5 migráció után mindig külön végigmegyek:
- asztali nézeten,
- tableten,
- mobilon.
Ez azért fontos, mert előfordulhat, hogy:
- desktop tökéletes,
- mobil hibás.
Vagy éppen fordítva. A responsive értékek újraszámolása sokszor csak egy adott nézetet érint.
Saját tanulság
A Divi 5 migráció egyik legnagyobb időmegtakarítása lehet, ha nem kezdesz el rögtön mindent újraépíteni.
Először mindig próbáld meg:
- megnyitni az elemet,
- módosítani egy értéket,
- visszaállítani,
- újramenteni.
Meglepően gyakran ez elegendő. Nem látványos megoldás. Nem technikai bravúr. Viszont rengeteg időt tud megspórolni.
A fájlszerkezet kérdése: mikor lehet nagyobb baj?
A Divi 5 migráció során van egy terület, amely szerintem sokkal fontosabb, mint a színek, a gombok vagy az ikonok. Ez pedig a fájlszerkezet. Mert a saját tapasztalataim alapján a legtöbb vizuális hiba javítható. Viszont ha korábban belenyúltál a Divi működésének alapjaiba, akkor a helyzet már egészen más lehet.
Ha nem módosítottál fájlszerkezetet, általában kisebb a kockázat
Ez az egyik legmegnyugtatóbb tapasztalatom. Azoknál a WordPress weboldalaknál, ahol:
- csak Divi Buildert használtam,
- csak CSS módosítások történtek,
- nem nyúltam a sablonfájlokhoz,
- nem módosítottam PHP fájlokat,
ott a Divi 5 migráció általában kezelhető problémákat okozott.
Tipikusan:
- színek,
- ikonok,
- hover állapotok,
- térközök,
- responsive eltérések.
Ezek időigényesek lehetnek. De általában javíthatók.
Ha Divi 4 alatt módosítottad a fájlszerkezetet
Itt már óvatosabb lennék.
Különösen akkor, ha korábban módosítottad:
- header.php
- footer.php
- functions.php
- custom template fájlok
- egyedi modulfájlok
- child theme sablonokat
A Divi 5 mögött ugyanis jelentősen megváltozott a működési logika. Ezért előfordulhat, hogy egy korábbi megoldás:
- Divi 4 alatt működött,
- Divi 5 alatt viszont már nem.
Saját véleményem a fájlszerkezet módosításáról
A migráció során egyre inkább megerősödött bennem az a vélemény, hogy hosszú távon érdemes minél több dolgot:
- Builderből,
- Theme Builderből,
- globális CSS-ből,
megoldani.
Minél mélyebben nyúlunk bele a fájlszerkezetbe, annál nagyobb eséllyel jelentkezhetnek problémák egy nagyobb verzióváltás során.
Child Theme, custom CSS és functions.php ellenőrzése
Migráció előtt mindig ellenőrzöm:
- child theme használatát,
- functions.php módosításokat,
- egyedi JavaScriptet,
- egyedi CSS-t,
- külső integrációkat.
Ezek a területek sokszor évek alatt gyűlnek össze. A probléma az, hogy idővel már senki sem emlékszik rájuk. A Divi 5 migráció viszont nagyon gyorsan rámutat arra, hogy hol vannak ezek az örökölt megoldások.
Saját tanulság
Ha nem nyúltál bele mélyen a sablon működésébe, akkor a Divi 5 migrációtól általában nem kell félni.
- Bosszúságokat okozhat.
- Lesz hibakeresés.
- Lesz finomhangolás.
De a legtöbb esetben kezelhető marad.
Ha viszont éveken keresztül módosítottad a Divi belső működését, akkor a migráció előtt különösen fontos:
- a mentés,
- a staging környezet,
- és az alapos tesztelés.
Mert ott már nem csak design elemekről beszélünk. Hanem a rendszer működésének alapjairól.
Cache problémák Divi 5 migráció után
Ha egyetlen olyan hibaforrást kellene megneveznem, amely a legtöbb felesleges hibakeresést okozza Divi 5 migráció után, akkor az a cache lenne.
- Nem a Divi.
- Nem a WordPress.
- Nem a pluginok.
Hanem a cache.
A saját migrációs tapasztalataim alapján rengeteg olyan hibának tűnő jelenség volt, amely végül nem is létezett. Legalábbis már nem. A probléma egyszerű: a weboldal javítva volt, de a böngésző vagy a gyorsítótár még a régi állapotot mutatta. Ez sokszor teljesen félre tudja vinni a hibakeresést.
Miért ennyire veszélyes a cache migráció után?
Mert a Divi 5 migráció során rengeteg fájl változik.
Változhat:
- CSS
- JavaScript
- modulstruktúra
- Theme Builder sablon
- globális stílus
- plugin generált fájl
A gyorsítótár viszont gyakran még a korábbi verziót szolgálja ki.
Ilyenkor kialakul az egyik legidegesítőbb helyzet:
- A Builderben már jó.
- A frontendben még rossz.
- Vagy éppen fordítva.
LiteSpeed Cache – az első ellenőrzési pont
Ha LiteSpeed Cache fut a weboldalon, akkor a migráció után az első feladat:
LiteSpeed Cache → Toolbox → Purge → Purge All
Sokan ezt kihagyják. Pedig migráció után kötelező lépés.
Különösen akkor, ha használod:
- CSS Minify
- JS Minify
- UCSS
- CCSS
- Page Optimization
funkciókat.
A Divi 5 új struktúrája miatt előfordulhat, hogy a korábban generált cache fájlok már nem megfelelőek.
Cloudflare cache ürítése
Ha Cloudflare is működik a weboldal előtt, akkor egy második cache réteggel is számolni kell. Ilyenkor nem elég a WordPress oldalon törölni a gyorsítótárat.
A Cloudflare-ben is érdemes:
Caching → Purge Cache → Purge Everything
funkciót futtatni.
Különben előfordulhat, hogy:
- a WordPress már jó,
- a Cloudflare még a régi verziót mutatja.
A böngésző cache is becsaphat
Ez az a rész, amit még tapasztalt felhasználók is hajlamosak elfelejteni.
Nálam többször előfordult, hogy:
- javítottam a hibát,
- elmentettem,
- töröltem a LiteSpeed cache-t,
és még mindig láttam a problémát. Azt hittem, nem működött a javítás. Pedig működött. Csak a böngésző a saját gyorsítótárából töltötte vissza a régi állapotot.
Ctrl + F5 – a legegyszerűbb teszt
Ezért migráció után szinte automatikusan használom:
Ctrl + F5
Ez kényszerített újratöltést végez. Sok esetben már ez is megoldja a rejtélyt.
Inkognitó mód
Ha biztosra akarok menni:
- Chrome Inkognitó
- Edge InPrivate
ablakban is megnyitom az oldalt. Itt a böngésző nem használja a normál gyorsítótár nagy részét.
Ezért nagyon gyorsan kiderül:
- valódi hibáról van szó,
- vagy csak cache problémáról.
Amikor a Builder és a frontend mást mutat
A migráció során több alkalommal találkoztam ezzel.
A Builderben:
- minden jó volt.
A frontendben:
- rossz szín,
- rossz méret,
- hibás gomb.
Elsőre azt gondoltam:
a Builder hibás. Aztán cache törlés után minden helyreállt. Valójában nem a Builder és nem a Divi hibázott. A gyorsítótár mutatott egy korábbi állapotot.
UCSS és CCSS külön figyelmet igényel
Ha LiteSpeed Cache alatt használod:
- UCSS (Unique CSS)
- CCSS (Critical CSS)
funkciókat, akkor migráció után különösen fontos:
Purge All
majd
Regenerate
műveletet végezni.
A Divi 5 más struktúrát használhat, mint a Divi 4. Ezért a korábban generált optimalizált CSS-ek könnyen elavulhatnak.
Mikor gyanakodj cache problémára?
A saját tapasztalatom szerint akkor, ha:
- a Builderben jó, frontendben rossz,
- egyik böngészőben jó, másikban rossz,
- inkognitó módban jó,
- mobilon jó, asztalin rossz,
- a hiba időnként eltűnik.
Ezek nagyon gyakran cache tünetek.
Saját tanulság
A Divi 5 migráció során többször is majdnem elkezdtem újraépíteni elemeket. Utólag kiderült, hogy semmi szükség nem volt rá.
Elég lett volna:
- LiteSpeed Purge All,
- Cloudflare Purge,
- Ctrl + F5,
- inkognitó teszt.
Ezért ma már a hibakeresési sorrendem így néz ki:
- Cache törlés.
- Böngésző frissítés.
- Inkognitó teszt.
- DevTools ellenőrzés.
- Csak ezután kezdek el tényleges hibát keresni.
Chrome DevTools: a legfontosabb hibakereső eszköz Divi 5 után
Ha a Divi 5 migráció során csak egyetlen eszközt vihetnék magammal, az a Chrome DevTools lenne. Őszintén szólva a migráció során több problémát oldottam meg DevTools segítségével, mint magában a Builderben.
A következő részben megmutatom:
- hogyan használd a Chrome DevTools-t Divi 5 hibakereséshez,
- hogyan találtuk meg a világoskék #2EA3F2 szín forrását,
- hogyan derítettük ki a hibás ikonokat,
- és hogyan lehet percek alatt megtalálni egy olyan CSS szabályt, amelyet a Builderben órákig keresnél.
Chrome DevTools: a legfontosabb hibakereső eszköz Divi 5 után
Ha a Divi 5 migráció során csak egyetlen eszközt ajánlhatnék, akkor az nem a Divi Builder lenne.
- Nem a WordPress admin.
- Nem egy plugin.
Hanem a Chrome DevTools.
A migráció során számos alkalommal előfordult, hogy a Builderben minden rendben lévőnek tűnt, a frontendben viszont teljesen más jelent meg. Ilyenkor a találgatás helyett a DevTools adta meg a választ.
A folyamat egyszerű:
- F12
- Elem kijelölése
- Kattintás a problémás elemre
- Styles és Computed panel vizsgálata
Ennek segítségével sikerült megtalálni:
- a visszatérő világoskék #2EA3F2 színt,
- a hibás ikonörökléseket,
- a hover állapotokat,
- a háttérszíneket,
- a plugin által generált CSS-eket,
- a Divi Pixel elemeket,
- és több olyan szabályt, amelyet a Builderben szinte lehetetlen lett volna megtalálni.
A DevTools használata után teljesen másként kezdtem hibát keresni.
Nem azt kérdeztem:
„Hol látszik a hiba?”
Hanem azt:
„Mi generálja a hibát?”
Ez a szemlélet rengeteg időt takarított meg.
Divi 5 migrációs ellenőrzőlista
Ha ma újra kezdeném a teljes folyamatot, a következő sorrendet követném.
Migráció előtt
- teljes biztonsági mentés
- adatbázis mentés
- fájlmentés
- pluginfrissítések
- Divi frissítése
- plugin kompatibilitások ellenőrzése
- Divi Supreme Pro ellenőrzése
- Divi Pixel ellenőrzése
- child theme ellenőrzése
- egyedi CSS ellenőrzése
- staging környezet létrehozása
Migráció közben
- Compatibility Scan futtatása
- Divi 5 Migrator futtatása
- hibajelzések dokumentálása
- plugin hibák rögzítése
- frontend ellenőrzése
Migráció után
- LiteSpeed Purge All
- Cloudflare Purge Cache
- Ctrl+F5
- inkognitó teszt
- fejléc ellenőrzése
- lábléc ellenőrzése
- mobilnézet ellenőrzése
- CTA gombok ellenőrzése
- kapcsolatfelvételi űrlapok ellenőrzése
- popupok ellenőrzése
- slide-in elemek ellenőrzése
- ikonok ellenőrzése
- hero szekciók ellenőrzése
Amit külön ellenőriznék
- háttér overlay-ek
- hover állapotok
- responsive beállítások
- paddingok
- marginok
- teljes szélességű sorok
- Theme Builder sablonok
- globális fejléc
- globális lábléc
Mikor ne migrálj még Divi 5-re?
Bár alapvetően támogatom a Divi 5-re való átállást, vannak helyzetek, amikor érdemes várni.
Például:
- nincs biztonsági mentésed,
- nincs staging környezeted,
- kritikus pluginjeid még nem kompatibilisek,
- nincs időd végigtesztelni az oldalt,
- sok egyedi fejlesztés van a fájlszerkezetben.
Ilyenkor nem a Divi 5 a probléma. Egyszerűen még nincs meg a megfelelő előkészítés.
Mikor érdemes belevágni?
A saját tapasztalataim alapján akkor, ha:
- van teljes mentés,
- van staging környezet,
- a pluginok kompatibilisek,
- a migrációt tesztkörnyezetben lefuttattad,
- van időd a finomhangolásra.
Mert a valóság az, hogy a Divi 5 migráció ritkán lesz teljesen problémamentes.De a problémák jelentős része kezelhető.
A legfontosabb tanulságom a Divi 5 migrációról
Ha egyetlen mondatban kellene összefoglalnom az egész folyamatot, akkor ezt mondanám: A Divi 5 migráció nem katasztrófa, hanem egy technikai átállás.
A saját projektjeim során találkoztam:
- shortcode hibákkal,
- plugin kompatibilitási kérdésekkel,
- világoskék színvisszaállásokkal,
- hover problémákkal,
- ikonhibákkal,
- háttér overlay problémákkal,
- méretezési anomáliákkal,
- cache problémákkal,
- és egy rejtélyes fekete blokkal is a lábléc alatt.
Mégis az esetek döntő többségében a weboldal működőképes maradt. Ez nagyon fontos. A migráció után nem feltétlenül az a kérdés, hogy működik-e az oldal. Sokkal inkább az, hogy mennyi finomhangolásra van szükség.
A tapasztalataim alapján a legtöbb vizuális eltérés javítható:
- egy plugin frissítésével,
- egy cache törléssel,
- egy CSS korrekcióval,
- egy újramentéssel,
- vagy egyszerűen azzal, hogy a Divi 5 újraszámolja az adott elemet.
Ezért ma már nem félek a Divi 5 migrációtól.
- Tisztelem.
- Előkészítem.
- Lementem.
- Letesztelem.
És utána végigmegyek rajta elemről elemre. Pontosan úgy, ahogy egy komoly WordPress weboldal megérdemli.
GYIK – Divi 4 migrálása Divi 5-re
Biztonságos a Divi 4-ről Divi 5-re migrálás?
Igen, megfelelő előkészítés mellett általában biztonságos. A teljes mentés és a staging környezet használata erősen ajánlott.
Eltűnhetnek elemek Divi 5 migráció után?
Előfordulhat, hogy bizonyos modulok vagy pluginok hibásan jelennek meg, különösen akkor, ha még nem Divi 5 kompatibilisek.
Miért jelenik meg a Divi alapértelmezett világoskék színe?
Gyakran öröklődési probléma áll a háttérben. A migráció után egyes elemek visszatérhetnek a Divi alapértelmezett stílusaihoz.
Mi az a Divi 5 Compatibility Scan?
A Divi hivatalos ellenőrző rendszere, amely segít azonosítani a kompatibilitási problémákat a migráció előtt.
Miért fontos a staging környezet?
Mert lehetővé teszi, hogy a hibák először egy tesztoldalon jelenjenek meg, ne az éles weboldalon.
Mit tegyek, ha shortcode jelenik meg modul helyett?
Ellenőrizd a plugin kompatibilitását, frissítsd a modult, töröld a cache-t, és nézd meg a fejlesztő dokumentációját.
Miért nem látszik a hiba a Visual Builderben?
A Builder és a frontend nem mindig ugyanazt a renderelt állapotot mutatja. Ezért érdemes DevTools segítségével is vizsgálódni.
Mit tegyek, ha egy elem rossz méretben jelenik meg?
Próbáld meg módosítani a méretezési vagy kiterjedési beállítást, majd állítsd vissza az eredeti értékre. A Divi 5 sok esetben újraszámolja az elemet.
Mit tegyek, ha a lábléc alatt megjelenik egy furcsa fekete blokk?
Ne feltételezd automatikusan, hogy a lábléc hibás. Nálam például a Back To Top gomb okozta a problémát.
Mikor érdemes visszaállítani mentésből?
Csak akkor, ha valódi működési probléma jelentkezik vagy a weboldal nem állítható helyre ésszerű idő alatt. Sok vizuális hiba javítható teljes visszaállítás nélkül.
Záró gondolat a Divi4 és Divi5-ről
A Divi 5 nem egy újabb sablonfrissítés. Ez a Divi ökoszisztéma egyik legnagyobb technológiai váltása. Aki WordPress weboldalt üzemeltet Divivel, előbb-utóbb találkozni fog vele. A kérdés nem az, hogy átállsz-e. A kérdés az, hogy mennyire felkészülten állsz neki.
Az én tapasztalataim alapján a siker kulcsa:
- biztonsági mentés,
- staging környezet,
- kompatibilitás ellenőrzés,
- türelem,
- és módszeres hibakeresés.
Ha ezek megvannak, akkor a Divi 5 migráció nem ellenség lesz, hanem egy olyan fejlesztés, amely hosszú távon gyorsabb, modernebb és stabilabb WordPress weboldalt eredményezhet.
Divi 4-ről Divi 5-re szeretnél migrálni, de nem kockáztatnád a weboldalad működését?
Segítek a teljes folyamatban:
- előzetes állapotfelmérés,
- kompatibilitási ellenőrzés,
- biztonsági mentés,
- staging környezet kialakítása,
- Divi 5 migráció,
- hibajavítás,
- teljes tesztelés.
Ha szeretnéd, hogy a WordPress weboldalad biztonságosan és minél kevesebb kellemetlenséggel álljon át Divi 5-re, vedd fel velem a kapcsolatot ide kattintva.
Használt források
- Elegant Themes Divi 5 Documentation
- Elegant Themes Divi 5 Compatibility Scan
- Divi Supreme Pro Documentation
- Chrome DevTools Documentation
- LiteSpeed Cache Documentation
