5. rész: Gyakori hibák javítása telepítés után

Ha éppen most telepítetted a Divi 5-öt, és az oldalad hirtelen „hibás elrendezésbe” vált, a Visual Builder nem hajlandó betölteni magát, vagy REST hibákat látsz a konzolon, akkor egy nagyon gyakori esetben állsz szemben: a gyorsítótár, a szkriptek betöltési sorrendje és a biztonság (nonce/cookie-k) átfedése keveredik.

a probléma

A Divi 5 telepítése vagy aktiválása után WordPress A 6.9.4-es verziótól (2026. április) kezdve egyes oldalakon azonnali működési zavarok jelentkeznek: a vizuális szerkesztő nem töltődik be, a stílusok már nem érvényesülnek, vagy az adminisztráció instabillá válik.

Íme néhány tipikus üzenet, amit a PHP naplókban, a böngésző konzoljában vagy a hálózati válaszokban (a „Hálózat” fül alatt) látok.

Uncaught TypeError: Cannot read properties of undefined (reading '...')

REST API: 401 Unauthorized /wp-json/...

403 Forbidden (CSRF token missing or incorrect)

Failed to load resource: the server responded with a status of 404 (Not Found) /wp-content/themes/Divi/...

There has been a critical error on this website.

Ahol megjelenik:

Front-end Hiányzó CSS, stílustalan menü, rosszul igazított Divi modulok, hiányzó animációk.
admin : A Visual Builder ismétlődően ismétlődik („Betöltés…”), vagy fehér képernyő jelenik meg a szerkesztőben.
API hibák a következőn: /wp-json/ (REST API) és AJAX kérések (gyakran 401/403 hibát eredményeznek).

Tipikus körülmények:

Közvetlenül a Divi 5 telepítése után (vagy a Divi 4-ről a Divi 5-re való átállás után).
WordPress 6.9.x frissítés vagy aktivált gyorsítótár/CDN bővítmény után.
Biztonsági bővítmény/WAF (alkalmazástűzfal) vagy szigorúbb szerverszabályok aktiválása után.

Kinek szól ez: kezdő bloggereknek (de „profi” ellenőrzéseket is biztosítok). A végére tudni fogod, hogyan lehet elkülöníteni az okot. helyes megfelelően (anélkül, hogy a maggal babrálnánk), és ellenőrizzük, hogy a Divi 5 helyesen tölti-e be az erőforrásait, valamint hogy a szerkesztő megfelelően kommunikál-e REST/AJAX-on keresztül.

Gyors összefoglaló

az esetek 90%-a : gyorsítótár (plugin/CDN/böngésző) + JS/CSS optimalizálás, ami felborítja a betöltési sorrendet.
REST 401/403 hibák : nonce/sütik blokkolva (biztonsági bővítmény, WAF, ModSecurity szabály, „SameSite”).
Vizuális szerkesztő cikluson belül A REST API elérhetetlen, vagy a JS túl agresszívan minimalizált/késleltetett („defer/delay”).
404-es hiba a Divi fájlokban átírás (permalinkek), CDN-útvonal vagy jogosultságok.
500-as hiba / kritikus Kevés a PHP, nincs elég memória, vagy hibás kódrészlet van benne. functions.php.

Tünetek

Íme a Divi 5 telepítése utáni leggyakoribb tünetek, a „legláthatóbb”-tól a „legtrükkösebb”-ig rangsorolva.

Stílusozatlan elrendezés A Divi CSS fájlok jellemzően vagy nem töltődnek be, vagy egy gyorsítótárazott verzió váltja fel őket.
A Vizuális szerkesztő nem töltődik be : végtelen „Betöltés” képernyő, vagy visszatérés az adminisztrációhoz egyértelmű hiba nélkül.
Nem válaszoló modulok : inaktív kattintások, a húzás és elengedés nem lehetséges, nem nyíló felugró ablakok.
Hibák a konzolban : Típushiba, csonk betöltése sikertelen, CORS hibák, 401/403 bekapcsolva /wp-json/.
500-as hiba / fehér képernyő : gyakran plugin-ütközés, memóriakorlát vagy rossz helyre másolt kód.
Divi rövidkódok szövegként megjelenítve A tartalom importálva van, de a szerkesztő nem aktív, vagy ütközik egy szűrőbővítménnyel the_content.
Problémák „csak a gyártás során” CDN, szerver gyorsítótár, HTTP/2 push, minimalizálás vagy WAF szabályok.

Gyors diagnosztikai táblázat (nagyon hasznos, ha elindulsz, és nem tudod, hol kezdjed).

tünet	Valószínű ok	igazolás	Megoldás
Hibás stílus / Hiányzó CSS	Gyorsítótárazás + CSS/JS csökkentés	Hálózat fül: A CSS 404-es hibát mutat, vagy nincs betöltve	Optimalizálás letiltása, Divi kizárása, gyorsítótárak törlése
Építőipari építő „Berakodás…”	REST blokkolva (401/403) vagy JS késleltetve	Konzol + Hálózat a /wp-json/ könyvtárban	Kizárás /wp-json/, helyes nonce/sütik, WAF
500-as hiba / kritikus	PHP/memória/kódrészlet hibás	WP_DEBUG + szervernaplók	Memória növelése, kód javítása, bővítményütközés
404-es hiba az eszközökön	Állandó linkek / átírás / engedélyek	Beállítások > Állandó linkek + közvetlen fájl URL-tesztelése	Generálj újra permalinkeket, ellenőrizd a .htaccess/Nginx fájlt
Divi tartalom rövidkódban	A készítő nem aktív / tartalomszűrő	Tiltsd le a bővítményeket, ellenőrizd az aktív témát	Aktiváld újra a Divit, izoláld a szűrőt tartalmazó bővítményt

Miért történik ez?

Kezdő verzió: A Divi 5 egy vizuális szerkesztő. Számos fájlt tölt be (CSS/JS), és lehetővé teszi a böngésző számára, hogy belső kéréseken (REST API és AJAX) keresztül kommunikáljon a WordPress-szel. Ha egy gyorsítótár, optimalizálás vagy biztonsági intézkedés blokkolja vagy módosítja ezeket az adatcseréket, számos tünetet fog tapasztalni.

Technikai verzió: A Divi 5 a szkriptek következetes betöltésére (sorrend, függőségek, chunkok), érvényes munkamenet-sütikre és WordPress nonce-okra támaszkodik. A nonce egy ideiglenes biztonsági token, amely bizonyos támadásokat megakadályoz (CSRF). Ha egy bővítmény késlelteti/elhalasztja a szkripteket (defer/delay), minimalizálja a szkripteket egy JS modul törésével, vagy ha egy WAF blokkolja a REST kéréseket, a builder "félig betöltve" lesz.

Valószínűsíthető okok (a leggyakoribbtól a legritkábbig):

Agresszív optimalizálás (gyorsítótár, tömörítés, kombináció, „JS késleltetés”, CDN), amely megváltoztatja a sorrendet vagy elavult fájlokat szolgál ki.
REST/AJAX blokkolás (biztonsági bővítmény, WAF, szerver szabályok, sütik/nonce hiba) → 401/403.
bővítményütközés (gyakran: optimalizálás, biztonság, fordítás vagy egy tartalmat szűrő bővítmény).
Szerverkorlátok (PHP memória, OPcache, időtúllépések) → 500 vagy „kritikus hiba” hibák.
Átírás/permalinkek hibás a migráció után → 404-es hiba a végpontokon vagy az eszközökön.
Emberi hiba : a kódrészlet rossz fájlba másolva, pontosvessző kimaradt, a hook nem megfelelő.

Oldalkészítő kompatibilitás: A Divi 5 telepítve lehet akkor is, ha időnként Elementort vagy Avadát használsz más oldalakon. Az ütközések főként akkor merülnek fel, ha több készítő saját globális szkripteket injektál (optimalizálás, lusta betöltés, könyvtárak). Az alábbi megoldások továbbra is érvényesek: a WordPress 6.9.4-et és az eszközök helyes betöltését célozzák, nem pedig egy törékeny, csak Divi-re optimalizált funkciót.

Előfeltételek a kezdés előtt

Bármilyen módosítás előtt, megtakarításTúl sok olyan weboldalt láttam már, amit egy egyszerű másolás-beillesztés hibásan tudott feldolgozni. functions.php.

védelme : fájlok + adatbázis (ideális esetben a tárhelyszolgáltatódon keresztül).
Tesztkörnyezet : lehetőség szerint színpadra állított másolat.
változatok WordPress 6.9.4, PHP 8.1+ ajánlott (a 8.2/8.3 gyakran kényelmesebb), Divi 5 naprakész.
WordPress hibakeresés engedélyezése (ideiglenesen) a PHP hibák megtekintéséhez.
Tools :
- Lekérdezés figyelő (kérések, hookok, PHP hibák, REST).
- Állapotfelmérés és hibaelhárítás (hibaelhárítási mód a látogatók érintése nélkül).
- Hozzáférés a böngésző konzoljához (Chrome/Firefox) + Hálózat fül.

WP_DEBUG engedélyezése (gyakorlati környezetben vagy ideiglenesen éles környezetben) itt: wp-config.php :

/**
 * Active le debug WordPress (à utiliser temporairement).
 * À placer dans wp-config.php, avant "/* That's all, stop editing! */"
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // Écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // Évite d'afficher les erreurs aux visiteurs

Hivatalos hivatkozás: Hibakeresés a WordPress szolgáltatásban.

1. megoldás: Javítsa ki a Divi 5 CSS/JS hibáit, amelyek nem töltődnek be (sorba helyezés, gyorsítótár, sorrend)

Amikor a Divi 5 „elveszíti” a stílusait, vagy a szerkesztő interaktivitás nélkül töltődik be, az elsődleges ok egy teljesítménynövelő bővítmény, amely:

szkripteket kombinál/minimalizál modulok felbontásával,
késlelteti a létfontosságú szkripteket,
egy frissítés után megváltozott fájl gyorsítótárazott verzióját szolgálja ki.

Gyors diagnózis :

Nyisd meg az oldalad privát böngészési módban.
F12 → fül Hálózat → Szűrés „CSS”, majd „JS” szerint.
Újratöltés (Ctrl+F5). Keresés 404, 403, vagy váratlan CDN-tartományból kiszolgált fájlok.

A klasszikus eset: „Mindent kombinálok/minimalizálok”

Lehet, hogy hozzáadtál egy kódrészletet egy régi oktatóanyagból (gyakran a WordPress 6.5 előttiből), amely (szinte) minden szkriptre kikényszeríti a "defer" parancsot. A Divi 5 esetében ez egy instabil szerkesztő receptje.

ELSŐ (törött) : tipikus kód beillesztve ide functions.php (gyermektéma) vagy egy kódrészlet bővítmény.

add_filter( 'script_loader_tag', function( $tag, $handle ) {
	// MAUVAISE IDÉE : on diffère presque tout, sans exclusions.
	if ( false === strpos( $tag, 'defer' ) ) {
		$tag = str_replace( '<script ', '<script defer ', $tag );
	}
	return $tag;
}, 10, 2 );

Miért hibás: egyes szkripteknek egy adott sorrendben kell futniuk, vagy mielőtt a DOM „kész” lenne. Azzal, hogy mindent elhalasztasz, megváltoztatod a tényleges végrehajtási sorrendet. Gyakran láttam ezt a hibát olyan oldalakon, amelyek egy gyorsítótárazó bővítményt is használtak, amely „késlelteti a JS-t”: dupla csapás.

UTÁNA (javítva) ésszerű szintű optimalizálást tartunk fenn, de mi kizárja A kritikus szkriptek (Divi/Builder, jQuery, ha szükséges, és különösen minden, ami a szerkesztőhöz kapcsolódik). Ezt a kódot beilleszted a következőbe: a gyermektéma functions.php fájlja vagy még jobb, egy egyéni bővítmények (ajánlott).

<?php
/**
 * Plugin Name: BPCAB - Correctifs Divi 5 (assets)
 * Description: Exclusions de defer/delay pour éviter les bugs Divi 5 après installation.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Filtre = "hook" qui modifie une valeur.
 * Ici, on modifie la balise <script> générée par WordPress.
 *
 * Objectif : éviter de différer des scripts critiques (Divi/Builder/REST).
 */
add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {

	// Liste d'exclusion : adaptez si vous identifiez des handles précis via Query Monitor.
	$excluded_handles = array(
		'jquery',
		'jquery-core',
		'wp-api',
		'wp-api-request',
		'wp-polyfill',
	);

	// Exclusion "par motif" sur l'URL si le handle n'est pas fiable (cas fréquent avec des bundles).
	$excluded_src_patterns = array(
		'/et-core/',   // souvent utilisé côté Divi/ET
		'/divi/',      // prudence
		'/builder/',   // prudence
		'admin-ajax.php',
		'/wp-json/',
	);

	// 1) Exclusion par handle
	if ( in_array( $handle, $excluded_handles, true ) ) {
		return $tag;
	}

	// 2) Exclusion par motif d'URL
	foreach ( $excluded_src_patterns as $pattern ) {
		if ( is_string( $src ) && str_contains( $src, $pattern ) ) {
			return $tag;
		}
	}

	// 3) Sinon, on peut ajouter defer, mais sans casser le type="module" si présent.
	if ( ! str_contains( $tag, ' defer' ) && ! str_contains( $tag, ' type="module"' ) ) {
		$tag = str_replace( '<script ', '<script defer ', $tag );
	}

	return $tag;

}, 10, 3 );

Hová kell beilleszteni ezt a kódot :

Tiszta opció: fájl létrehozása wp-content/plugins/bpcab-divi5-fixes/bpcab-divi5-fixes.phpIlleszd be a kódot, majd aktiváld a bővítményt.
„Gyors” opció: functions.php a gyermektéma (kevésbé robusztus, ha témát váltasz).

Mentés szerkesztés előttEgy elfeledett zárójel a functions.php elég ahhoz, hogy fehér képernyőt okozzon.

Gyorsítótár és CDN: az igazi „nem probléma”

Mielőtt hozzányúlnál a kódhoz, végezd el ezeket a tisztításokat ebben a sorrendben (különben egy olyan webhelyet fogsz tesztelni, ami valójában nem is létezik):

Töröld a bővítmény gyorsítótárát (LiteSpeed Cache / WP Rocket / stb.).
Töröld a szerver (tárhelyszolgáltató) gyorsítótárát, ha elérhető.
Töröld ki a CDN gyorsítótárát (Cloudflare stb.).
Töröld a böngésző gyorsítótárát (vagy használj privát böngészést).

Ha párhuzamosan használod az Elementort vagy az Avadát: alkalmazd ugyanazt a logikát. A „globális” optimalizálások bármilyen modern buildert tönkretesznek.

2. megoldás: REST/AJAX hibák javítása (nonce, sütik, biztonság, WAF)

Amikor a Divi 5 már nem tudja menteni, betölteni a buildert vagy lekérni az adatokat, gyakran a következőket látjuk:

401 jogosulatlan sur /wp-json/
Tiltott 403 sur admin-ajax.php
„nonce invalid” hibák (néha csak a JSON válaszban láthatók)

Kezdőknek szóló fordítás: A WordPress elutasít egy kérést, mert úgy gondolja, hogy az nem legitim. Vagy a böngésző nem küldi a megfelelő sütiket, vagy egy tűzfal módosítja/blokkolja a kérést, vagy egy gyorsítótár egy "bejelentkezett" oldalt jelenít meg egy kijelentkezett látogatónak.

1. lépés: Ellenőrizze, hogy a REST API válaszol-e

Egyszerű teszt: nyisd meg ezt az URL-t (miközben be vagy jelentkezve az admin felületre):

https://votre-site.tld/wp-json/

JSON-t (adatszerkezetet) kell beszerezned, nem pedig blokkoló HTML-oldalt. Ha „Hozzáférés megtagadva” oldalt, egy kihívást vagy WAF HTML-t látsz, akkor megtaláltad a hiba okát.

Hivatalos REST API dokumentáció: WordPress REST API kézikönyv.

2. lépés: Gyakori eset – gyorsítótár, amely adminisztrációs/szerkesztői oldalakat tárol

Néhány gyorsítótár-beállítás (vagy rosszul konfigurált CDN) gyorsítótár-oldal, amelyeket soha nem szabad gyorsítótározni: /wp-admin/, wp-json, vagy a builder által használt végpontok.

Anélkül, hogy belemennénk az egyes bővítmények konkrét konfigurációjába, a szabály egyszerű:

Kizárás / Wp-admin /, /wp-json/, admin-ajax.php gyorsítótár.
Ideiglenesen tiltsa le a „Delay JS” és a „Combine JS” funkciókat tesztelés céljából.

3. lépés: Gyakori eset — biztonsági bővítmény/WAF blokkolja az admin-ajax vagy a wp-json parancsot

Gyakran találkoztam ezzel a túl szigorú szabályoknál: blokkolják a kéréseket. POST hogy admin-ajax.php ou /wp-json/, vagy bizonyos paramétereket szűrnek.

Diagnosztikai :

Ellenőrizd a biztonsági bővítmények naplóit (blokkolt események).
Ellenőrizd a szervernaplókat (ModSecurity, WAF hosting).
A Hálózat részben nyisd meg a 403-as kérést, és nézd meg a választ: néha a WAF „aláírja” az oldalát.

WordPress oldali javítás (tiszta) Győződj meg róla, hogy a WordPress helyesen küldi a gyorsítótár nélküli fejléceket az érzékeny oldalaknak, és akadályozd meg, hogy egy proxy gyorsítótárazza azokat. Ez nem csodaszer a WAF ellen, de segít néhány rosszul konfigurált fordított proxy esetén.

Beillesztés egy egyéni bővítménybe (vagy functions.php (a gyerekek témájából):

<?php
/**
 * Empêche le cache sur les pages où Divi/WordPress ont besoin d'une session cohérente.
 * Utile si un proxy/CDN est un peu trop "zélé".
 */
add_action( 'send_headers', function() {

	// Ne pas toucher au front-end public.
	if ( ! is_admin() && ! wp_doing_ajax() ) {
		return;
	}

	// En admin/AJAX, on force des en-têtes anti-cache.
	nocache_headers();

	// Certains proxies respectent mieux ces directives explicites.
	header( 'Cache-Control: no-store, no-cache, must-revalidate, max-age=0' );
	header( 'Pragma: no-cache' );
}, 20 );

Miért segít ez A Divi 5 hitelesített kérésekre támaszkodik. Ha egy válasz gyorsítótárazva van és újra kiszolgálva, akkor inkonzisztens nonce/cookie-t kaphat, ami 401/403-as hibát eredményezhet.

4. lépés: Vegyes tartalom vagy következetlen domain (www vagy nem www) javítása

A Divi 5 gyorsan problémássá válik, ha az oldalad a következők között váltakozik:

http:// et https://
www és nemwww

Check Beállítások> Általános A „WordPress webcím” és a „Webhely webcíme” mezőknek pontosan meg kell egyezniük.

Referencia: Nonces (WordPress biztonság) (hasznos annak megértéséhez, hogy miért romlik el).

3. megoldás: Javítsa ki a 404-es hibákat, a ciklusszerkesztőt és az 500-as hibákat (permalinkek, átírás, memória, PHP)

Ez a megoldás három hasonló kinézetű, de eltérő okokból eredő hibacsaládot fed le: 404-es hiba, betöltési ciklusok és kritikus hibák.

A eset – 404 telepítés/migrálás után: permalinkek és átírási szabályok

Tünetek :

Néhány oldal működik, mások 404-es hibát adnak vissza.
A builder betöltődik, de néhány belső kérés sikertelen.

Kezdő javítás (kód nem szükséges) :

megy Beállítások> Permalinks.
Ne változtass semmit, csak kattints Nyilvántartás.

Ez újragenerálja az átírási szabályokat. Sok 404-es hiba "telepítés után" így megoldódik.

Hivatalos dokumentum: flush_rewrite_rules() (nem minden oldalon hívandó meg, lásd alább).

B eset — kritikus hiba / 500: hibás PHP memória és kódrészletek

Ha a „Kritikus hiba történt ezen a weboldalon” üzenetet látja, kezdje azzal, hogy megnézi wp-content/debug.log (ha a WP_DEBUG_LOG aktív) vagy a tárhelyszolgáltató PHP naplói.

Realisztikus hiba #1 : egy kódrészlet rossz helyre másolva (pl. a wp-config.php de rossz helyen), vagy egy elfelejtett pontosvessző.

ELSŐ (törött) : szándékosan hamis példa.

define( 'WP_MEMORY_LIMIT', '256M' )  // Point-virgule manquant => fatal error

UTÁNA (javítva) : Be wp-config.php, a „szerkesztés leállítása” sor előtt.

/** Augmente la mémoire PHP côté WordPress (ne remplace pas la limite serveur). */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin/éditeur

Miért: A Divi 5 (mint az Elementor/Avada) nagy terhelést jelenthet az adminisztrátor számára. Ha a korlát 128 MB, véletlenszerű hibákat tapasztalhatsz, különösen több bővítmény használata esetén.

PHP referencia (memóriakorlátok, konfiguráció): PHP memóriakorlát.

C eset – Ciklusok betöltése: OPcache és „elavult” fájlok

Ritkábban előfordul, de agresszív tárhelyszolgáltatóknál láttam már ilyet: az OPcache a frissítés után a régi PHP fájlokat a memóriában tartja. Ennek eredményeként a Divi/WordPress azt hiszi, hogy egy verziót tölt be, de a szerver valójában egy másikat futtat.

Diagnosztikai A hiba közvetlenül a frissítés után jelenik meg, néhány óra múlva „magától” eltűnik, vagy a PHP-FPM újraindítása után.

Rögzít Kérd meg a tárhelyszolgáltatódat, hogy törölje az OPcache-t és indítsa újra a PHP-FPM-et. A WordPress oldalon ezt nem lehet tisztán kikényszeríteni szerverhozzáférés nélkül (és nem javaslom az "opcache_reset()" szkriptek használatát éles környezetben: biztonsági kockázatot jelent, ha nem megfelelően védett).

Javítás utáni ellenőrzések

Ne elégedj meg azzal, hogy "jobban néz ki". Teszteld meg reprodukálható módon.

Elülső tesztelés : nyiss meg egy Divi oldalt privát böngészésben → a CSS-nek az első betöltéstől kezdve helyesnek kell lennie.
Tesztkészítő : nyisd meg a Visual Buildert, helyezz át egy modult, mentsd el, frissítsd → a módosításnak meg kell maradnia.
REST teszt nyitott /wp-json/ → JSON-t kell látnia, nem blokkoló HTML-t.
Konzol : nincsenek hiányzó (404) vagy elutasított (403) fájlokkal kapcsolatos piros hibák.
Lekérdezés figyelő : ellenőrizd a „HTTP API hívások” és a „PHP hibák” részt. Nulla végzetes hiba, és nincsenek ismétlődő 401/403-as hibák.

Ha a Divi 5-öt Elementorral vagy Avadával használod ugyanazon az oldalon: ellenőrizd mindkét builderrel létrehozott oldalt. Egy rosszul konfigurált gyorsítótár az egyik buildert hibásan működtetheti, a másikat viszont nem, ami hamis jelzéseket adhat.

Ha ez még mindig nem működik

Hibaelhárítási eljárás, amit akkor használok, ha a probléma "ragadós". Csináld sorrendben: elkerülöd a 10 beállítás vakon történő megváltoztatását.

1) Bővítmény/téma ütközés elkülönítése a webhely meghibásodása nélkül (Állapotfelmérés)

Telepítés Állapotfelmérés és hibaelhárítás, Akkor:

Aktiválja a hibaelhárítási mód (csak neked).
Deaktiváld az összes bővítményt, kivéve a Divit (és azokat, amelyek elengedhetetlenek).
Teszteld a készítőt.

Ha hibaelhárítási módban működik, akkor ütközés van. Aktiváld újra a bővítményeket egyenként, és minden alkalommal teszteld.

2) PHP hibák és PHP verzió ellenőrzése

PHP 8.1 minimum ajánlott. Ha 8.0-s vagy 7.4-es verziót használsz: tűzzel játszol (biztonság + kompatibilitás).
néz wp-content/debug.log és a szervernaplókat.

3) Ellenőrizze a fájlengedélyeket

Tünet: 403/404 hibák a fájlokban itt: wp-content/themes/ ou wp-content/uploads/.

Fájlok: 755 (gyakran)
Fájlok: 644 (gyakran)

Ha bizonytalan vagy, kérdezd meg a tárhelyszolgáltatódat. Soha ne használd a „chmod 777” parancsot: biztonsági kockázatot jelent.

4) Az átírás ellenőrzése (Apache/Nginx)

Ha a permalinkek nem generálódnak újra, akkor lehet, hogy szerverkonfigurációs probléma van (mod_rewrite, Nginx szabályok). Ez gyakori a migráció után.

Referencia: WordPress az Apache-on.

5) Ellenőrizd a böngésző konzolját és a hálózati kérelmeket

Ismétlem ezt, mert órákat takarít meg: ha a builder nem töltődik be, a konzol és a hálózat szinte mindig megmondja, miért (404-es, 403-as WAF, CORS stb. hibakód beillesztése).

Gyakori buktatók és hibák

Tünet / hiba	Valószínű ok	Ajánlott megoldás
„Betöltés…” végtelen a Divi 5-ben	REST API blokkolva (401/403), JS késik	Zárd ki a /wp-json/ és a Divi szkripteket az optimalizálásból, ellenőrizd a WAF-ot
CSS hiányzik a frissítés után	A gyorsítótár CDN/bővítmény egy régebbi verziót futtat	Az összes gyorsítótár törlése (bővítmény, szerver, CDN, böngésző)
Kritikus hiba közvetlenül egy kódrészlet hozzáadása után	Rossz helyre illesztettem be a kódot, pontosvesszőt elfelejtettem	Biztonsági mentés visszaállítása, szintaxis javítása, egyéni bővítmény használata
Látható Divi rövidkódok	A szerkesztő letiltva, bővítményütközés miatt a tartalom szűrése megtörtént.	Izoláció állapotfelméréssel, a hibás bővítmény letiltása
„Nem egyszer érvénytelen” / 403 admin-ajax	Sütik blokkolva, gyorsítótár a privát oldalakon, WAF	Admin/AJAX kizárása a gyorsítótárból, https/www domain ellenőrzése, biztonsági naplók
Helyben minden működik, de élesben nem.	CDN/WAF/OPcache/szerver optimalizálás	Ideiglenesen tiltsd le a CDN-t, ürítsd ki az OPcache-t a tárhelyszolgáltatón keresztül, és hasonlítsd össze a fejléceket.

Emberi hibák, amiket gyakran látok:

Másold be a kódot style.css helyett functions.php (vagy fordítva).
Összezavarni akció et szűrők Egy művelet adott időpontban végrehajtja a kódot; egy szűrő módosít egy értéket, és visszatérés valamit.
Túl korai hook használata (pl. szkriptek manipulálása, mielőtt a WordPress mentené őket).
Közvetlen tesztelés éles környezetben mentés vagy privát böngészés nélkül.

Változat / alternatíva

Kód nélküli módszer: teljesítmény szempontjából "biztonságos" konfigurációból kiindulva

Kezdőként a legjobb megközelítés gyakran a következő:

JS csökkentés/kombináció/késleltetés ideiglenes letiltása.
Ellenőrizd, hogy a Divi 5 stabil-e.
Aktiváld újra az optimalizálásokat egyenként, szükség szerint a Divi/REST kizárásával.

Ez Elementor és Avada esetén is működik: meg kell keresni azt a beállítást, amelyik megszegi a JS végrehajtási sorrendjét.

Fejlesztői módszer: a kizárandó pontos handle-ok elkülönítése a Query Monitor segítségével

A Lekérdezésfigyelőben a „Szkriptek” lapon láthatja a következőket: fogantyúk ténylegesen lekérdezett. A handle a szkript belső azonosítója a WordPressben. Ezután ezeket a handle-eket konkrétan kizárhatja a szűrőből. script_loader_tag (1. megoldás) az URL-töredékek egyeztetése helyett.

A nyomozás hivatalos dokumentuma: wp_enqueue_script ().

Kerülje el ezt a problémát a jövőben

Kerüld a „varázslatos” kódrészleteket 100/100 PageSpeed-et ígérnek, miközben mindent elhalasztanak. Gyakran megelőzik a modern oldalkészítőket.
Inkább egyéni bővítményt használj ahelyett, hogy beillesztené a kódot functions.phpA javításokat akkor is megtartod, ha témát váltasz.
Dokumentálja a gyorsítótár-kizárásokat (egy egyszerű szövegfájl): /wp-json/, admin-ajax.php, építőoldalak.
Frissítés szakaszokban Először WordPress, majd Divi, végül bővítmények. Teszteld őket közöttük.
Hibák figyelése : egy Query Monitorhoz hasonló bővítmény tesztelés alatt, és tiszta naplók éles környezetben.

Ha a kódban lévő permalinkeket ki kell üríteni (például egy bővítmény aktiválásakor), akkor ezt csak aktiváláskor tedd, soha ne minden betöltéskor:

<?php
/**
 * Exemple sûr : flush rewrite rules uniquement à l'activation.
 * À placer dans un plugin (pas dans functions.php).
 */
register_activation_hook( __FILE__, function() {
	flush_rewrite_rules();
} );

register_deactivation_hook( __FILE__, function() {
	flush_rewrite_rules();
} );

Mire való: flush_rewrite_rules() drága. Ha minden oldalon meghívja, az jelentősen lelassíthatja az oldalt.

erőforrás

Gyakran Ismételt Kérdések

Kompatibilis a Divi 5 a WordPress 6.9.4-gyel?

Igen, a gyakorlatban ez egy gyakori kombináció 2026-ban. A telepítés utáni problémák gyakrabban a gyorsítótárazási/optimalizálási/biztonsági problémákból erednek, mintsem "tiszta" kompatibilitási inkompatibilitásból. Tartsd naprakészen a Divit és a WordPress-t, és teszteld egy próbakörnyezetben.

Le kell tiltanom a gyorsítótárazó bővítményt a Divi 5 használatához?

Nem. De gyakran kell majd kizárni Kerülj bizonyos végpontokat (REST/AJAX) és a túlságosan agresszív „JS késleltetés” opciókat. Ha engedélyezel egy opciót és a builder összeomlik, akkor megtaláltad a bűnöst.

Miért kapok 401/403-as hibákat a /wp-json/ címen, pedig csatlakozom?

A leggyakoribb ok a blokkolt sütik (inkonzisztens www/nem www domain), a gyorsítótárazás privát oldalakon, vagy a POST kéréseket blokkoló WAF. Ellenőrizd a webhely URL-címeinek konzisztenciáját, és teszteld a biztonság/CDN ideiglenes letiltásával.

Beilleszthetem a kódrészleteket egy „Kódrészletek” bővítménybe?

Igen, de óvatosan. Egy hibás kódrészlet akkor is összeomlaszthatja az oldalt, ha a bővítmény mindenhol végrehajtja. Én egy kisebb, verziózott, egyedi bővítményt (akár minimálisat is) részesítek előnyben, mert jobban kézben tarthatod, hogy mi töltődik be.

Az építőmester nekem dolgozik, de egy másik adminisztrátornak nem: miért?

Gyakran a böngésző gyorsítótára, egy bővítmény vagy egy eltérő sütiszabályzat a ludas. Próbáld ki privát böngészési módban, bővítmények nélkül, és hasonlítsd össze a hálózati kéréseket (401/403).

Csak akkor kapok 500-as hibát, amikor megnyitom a Visual Buildert.

Ez memóriakorlátra, időtúllépésre vagy egy adott útvonalon (REST/AJAX) kiváltott végzetes hibára utal. Engedélyezze a WP_DEBUG_LOG függvényt, reprodukálja a hibát, majd olvassa el a naplót. wp-content/debug.log.

Divi 5 + Elementor ugyanazon az oldalon: ez rossz ötlet?

Nem „tiltott”, de növeli a konfliktusok kockázatát (globális szkriptek, optimalizálás, CSS). Ha mégis meg kell tenned, kerüld az olyan optimalizálásokat, amelyek mindent összevonnak/elhalasztanak, és minden frissítés után teszteld az összes építőt.

Rendszeresen törölnöm kell a permalinkeket?

Nem. Akkor tedd meg, amikor megváltoztatod a permalink struktúráját, migrálod a webhelyet, vagy útvonalakat hozzáadó bővítményt telepítesz. Kódban, csak egy bővítmény aktiválásakor/deaktiválásakor.

Mit kell először ellenőrizni, ha a Divi 5 „nem töltődik be”?

A konzol és a Hálózat fül. Szinte mindig 401/403 (REST/AJAX), 404 egy JS/CSS adatcsomagon, vagy optimalizálás által blokkolt szkriptet fogsz látni.