Divi 5: Поправяне на често срещани грешки след инсталиране

Ако току-що сте инсталирали Divi 5 и сайтът ви внезапно премине в „счупен вид“, Visual Builder отказва да се зареди или виждате REST грешки в конзолата, значи се намирате в много често срещан случай: комбинация от кеш, ред на зареждане на скриптове и сигурност (nonce/бисквитки), които се припокриват.

Проблемът

След инсталиране или активиране на Divi 5 на WordPress 6.9.4 (април 2026 г.), някои сайтове изпитват незабавни неизправности: визуалният редактор не се зарежда, стиловете вече не се прилагат или администрирането става нестабилно.

Ето някои типични съобщения, които виждам в PHP лог файловете, в конзолата на браузъра или в мрежовите отговори (в раздела „Мрежа“).

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.

Къде се появява:

Front-End Липсващ CSS, неоформено меню, неправилно подравнени Divi модули, липсващи анимации.
Admin : Цикъл на Visual Builder („Зареждане…“) или бял екран на редактора.
API грешки на /wp-json/ (REST API) и AJAX заявки (често водещи до 401/403).

Типични обстоятелства:

Веднага след инсталирането на Divi 5 (или мигрирането от Divi 4 към Divi 5).
След актуализация на WordPress до версия 6.9.x или активиран плъгин за кеш/CDN.
След активиране на плъгин за сигурност/WAF (приложна защитна стена) или по-строги правила за сървъра.

За кого е предназначено това: начинаещи блогъри (но предоставям и „професионални“ проверки). Накрая ще знаете как да изолирате причината. corriger правилно (без да се намесвам в ядрото) и да проверя дали Divi 5 зарежда ресурсите си правилно и дали редакторът комуникира правилно чрез REST/AJAX.

Бързо обобщение

90% от случаите : кеш (плъгин/CDN/браузър) + JS/CSS оптимизация, която нарушава реда на зареждане.
Грешки REST 401/403 : nonce/бисквитките са блокирани (плъгин за сигурност, WAF, правило на ModSecurity, „SameSite“).
Визуален конструктор в цикъл REST API е недостъпен или JS е минимизиран/забавен („defer/delay“) твърде агресивно.
Грешка 404 в Divi файлове пренаписване (постоянни връзки), CDN път или разрешения.
Грешка 500 / критична PHP е твърде нисък, недостатъчна памет или повреден фрагмент в functions.php.

Симптомите

Ето най-честите симптоми след инсталиране на Divi 5, подредени от най-„видимите“ до най-„трудните“.

Нестилизиран дизайн Обикновено CSS файловете на Divi или не се зареждат, или се заменят с кеширана версия.
Визуалният конструктор не се зарежда : безкраен екран „Зареждане“ или връщане към администратора без ясна грешка.
Модули, които не отговарят : неактивни кликвания, плъзгане и пускане не е възможно, изскачащи прозорци, които не се отварят.
Грешки в конзолата : Тип грешка, зареждането на фрагмента не беше успешно, грешки в CORS, 401/403 включен /wp-json/.
Грешка 500 / бял екран често конфликт на плъгини, ограничение на паметта или код, копиран на грешното място.
Шорткодовете на Divi се показват като текст Съдържанието е импортирано, но конструкторът не е активен или има конфликт с плъгин за филтриране the_content.
Проблеми „само в производството“ CDN, кеш на сървъра, HTTP/2 push, минификация или WAF правила.

Бърза диагностична диаграма (много полезна, когато започвате и не знаете откъде да започнете).

симптом	Вероятна причина	проверка	Решение
Неработещ стил / Липсващ CSS	Кеширане + CSS/JS минификация	Раздел „Мрежа“: CSS показва грешка 404 или не е зареден	Деактивиране на оптимизацията, изключване на Divi, изчистване на кешовете
Строител „Зареждане…“	REST блокиран (401/403) или JS забавен	Конзола + Мрежа на /wp-json/	Изключи /wp-json/, corriger еднократни изрази/бисквитки, WAF
Грешка 500 / критична	PHP/памет/фрагмент е повреден	WP_DEBUG + сървърни логове	Увеличаване на паметта, коригиране на код, конфликт на плъгини
404 за активи	Постоянни връзки / пренаписване / разрешения	Настройки > Постоянни връзки + тест за директен URL адрес на файл	Регенерирайте постоянните връзки, проверете .htaccess/Nginx
Divi съдържание в шорткод	Конструкторът не е активен / филтър за съдържание	Деактивирайте плъгините, проверете активната тема	Реактивирайте Divi, изолирайте плъгина, който филтрира

Защо се случва това?

Версия за начинаещи: Divi 5 е визуален конструктор. Той зарежда много файлове (CSS/JS) и позволява на браузъра ви да комуникира с WordPress чрез вътрешни заявки (REST API и AJAX). Ако кеш, оптимизация или мярка за сигурност блокира или променя тези обмени, ще видите голямо разнообразие от симптоми.

Техническа версия: Divi 5 разчита на последователно зареждане на скриптове (ред, зависимости, парчета), валидни бисквитки за сесия и nonce-и на WordPress. Nonce-ът е временен токен за сигурност, който предотвратява определени атаки (CSRF). Ако плъгин забави/отложи скриптове (defer/delay), минимизира чрез нарушаване на JS модул или ако WAF блокира REST заявки, конструкторът в крайна сметка е „наполовина зареден“.

Вероятни причини (от най-честите към най-редките):

Агресивна оптимизация (кеш, минификация, комбинация, „JS забавяне“, CDN), който променя реда или обслужва остарели файлове.
Блокиране на REST/AJAX (плъгин за сигурност, WAF, правила на сървъра, бисквитки/nonce) → 401/403.
конфликт на плъгини (често: оптимизация, сигурност, превод или плъгин, който филтрира съдържание).
Ограничения на сървъра (PHP памет, OPcache, таймаути) → 500 или грешки „критична грешка“.
Пренаписване/постоянни връзки прекъснато след миграция → 404 на крайни точки или активи.
Човешка грешка : фрагментът е копиран в грешен файл, пропусната точка и запетая, неподходяща кука.

Съвместимост с конструктора на страници: Можете да имате инсталиран Divi 5, дори ако понякога използвате Elementor или Avada на други страници. Конфликтите възникват главно, когато няколко конструктора инжектират свои собствени глобални скриптове (оптимизация, лениво зареждане, библиотеки). Решенията по-долу остават валидни: те са насочени към WordPress 6.9.4 и правилното зареждане на ресурси, а не към крехка функция „само за Divi“.

Предварителни изисквания преди започване

Преди каквато и да е модификация, спасиВиждал съм твърде много уебсайтове, повредени от обикновено копирайтиране. functions.php.

защита : файлове + база данни (в идеалния случай чрез вашия хостинг доставчик).
Тестова среда : поетапно копие, ако е възможно.
Версии WordPress 6.9.4, препоръчително PHP 8.1+ (8.2/8.3 често е по-удобно), Divi 5 е актуален.
Активиране на отстраняване на грешки в WordPress (временно), за да видите PHP грешки.
Инструменти :
- Монитор на заявките (заявки, куки, PHP грешки, REST).
- Проверка на състоянието и отстраняване на неизправности (режим на отстраняване на неизправности без да се засягат посетителите).
- Достъп до конзолата на браузъра (Chrome/Firefox) + раздел „Мрежа“.

Активирайте WP_DEBUG (на етап на подготовка или временно на етап производство) в 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

Официална справка: Отстраняване на грешки в WordPress.

Решение 1: Поправете CSS/JS кодовете в Divi 5, които не се зареждат (поставяне в опашка, кеширане, подреждане)

Когато Divi 5 „губи“ стиловете си или редакторът се зарежда без интерактивност, причина номер едно е плъгин за производителност, който:

комбинира/минимизира скриптове чрез разбиване на модули,
забавя важни скриптове,
предоставя кеширана версия на файл, който се е променил след актуализация.

Бърза диагноза :

Отворете страницата си в режим на частно сърфиране.
F12 → табулация мрежа → Филтрирайте по „CSS“, след това по „JS“.
Презареждане (Ctrl+F5). Търсене за 404, 403или файлове, предоставяни от неочакван CDN домейн.

Класическият случай: „Комбинирам/минимизирам всичко“

Може би сте добавили откъс от стар урок (често преди WordPress 6.5), който налага командата „defer“ на (почти) всички скриптове. С Divi 5 това е рецепта за нестабилен конструктор.

ПРЕДНА (счупена) типичен код, поставен в functions.php (дъщерна тема) или плъгин за фрагменти.

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 );

Защо се поврежда: някои скриптове трябва да се изпълняват в определен ред или преди DOM да е „готов“. Като отлагате всичко, променяте действителния ред на изпълнение. Често съм виждал този бъг в сайтове, които също използват плъгин за кеширане, който „забавя JS“: double whammy.

СЛЕД (коригирано) поддържаме разумно ниво на оптимизация, но ние изключва Критичните скриптове (Divi/Builder, jQuery, ако е необходимо, и особено всичко, свързано с редактора). Поставяте този код в functions.php на дъщерната тема или, още по-добре, в персонализирани добавки (препоръчително).

<?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 );

Къде да вмъкна този код :

Опция за почистване: създаване на файл wp-content/plugins/bpcab-divi5-fixes/bpcab-divi5-fixes.phpПоставете кода, след което активирайте плъгина.
„Бърза“ опция: functions.php на дъщерната тема (по-малко стабилна, ако промените темите).

Запазване преди редактиранеЗабравена скоба в functions.php достатъчно, за да се появи бял екран.

Кеш и CDN: истинският „не-проблем“

Преди да докоснете кода, изпълнете тези прочиствания в този ред (в противен случай ще тествате сайт, който всъщност не съществува):

Изчистете кеша на плъгините (LiteSpeed Cache / WP Rocket / и др.).
Почистете кеша на сървъра (хостинг), ако има такъв.
Почистете кеша на CDN (Cloudflare и др.).
Изчистете кеша на браузъра си (или използвайте режим на частно сърфиране).

Ако използвате Elementor или Avada паралелно: приложете същата логика. „Глобалните“ оптимизации пречат на всеки съвременен конструктор.

Решение 2: Поправете REST/AJAX грешки (nonce, бисквитки, сигурност, WAF)

Когато Divi 5 вече не може да запазва, зарежда конструктора или извлича данни, често виждате:

401 Неразрешено от /wp-json/
Forbidden 403 от admin-ajax.php
Грешки „nonce invalid“ (понякога видими само в JSON отговора)

Превод за начинаещи: WordPress отхвърля заявка, защото смята, че не е легитимна. Или браузърът не изпраща правилните бисквитки, защитна стена променя/блокира заявката, или кешът показва страница „влязъл в системата“ на невлязъл посетител.

Стъпка 1: Проверете дали REST API отговаря

Прост тест: отворете този URL адрес (докато сте влезли в администраторския панел):

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

Трябва да получите JSON (структура от данни), а не блокираща HTML страница. Ако видите страница „Достъпът е отказан“, предизвикателство или WAF HTML, значи сте открили причината.

Официална документация за REST API: Ръководство за WordPress REST API.

Стъпка 2: Често срещан случай — кеш, който кешира администраторски/редакторски страници

Някои настройки на кеша (или неправилно конфигурирана CDN мрежа) кешират страници, които никога не трябва да се кешират: /wp-admin/, wp-jsonили крайни точки, използвани от конструктора.

Без да навлизаме в специфичната конфигурация на всеки плъгин, правилото е просто:

Изключване / WP-администратор /, /wp-json/, админ-ajax.php кеш.
Временно деактивирайте „Delay JS“ и „Combine JS“ за тестване.

Стъпка 3: Често срещан случай — блокиране на admin-ajax или wp-json от плъгин за сигурност/WAF

Често съм се сблъсквал с това при прекалено строги правила: те блокират заявките. ПУСНИ Vers admin-ajax.php ou /wp-json/или филтрират определени параметри.

Диагностичен :

Проверете лог файловете на плъгините за сигурност (блокирани събития).
Проверете лог файловете на сървъра (ModSecurity, WAF хостинг).
В „Мрежа“ отворете заявката 403 и вижте отговора: понякога WAF „подписва“ страницата си.

Странична корекция на WordPress (чиста) Уверете се, че WordPress правилно изпраща заглавки без кеширане към чувствителни страници и предотвратете кеширането им от прокси сървър. Това не е магическо решение срещу WAF, но помага при някои лошо конфигурирани обратни прокси сървъри.

Поставете в персонализиран плъгин (или functions.php (на детската тема):

<?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 );

Защо това помага Divi 5 разчита на удостоверени заявки. Ако даден отговор е кеширан и резервиран, може да се окажете с несъответстващ nonce/cookie, което да доведе до грешка 401/403.

Стъпка 4: Коригирайте смесено съдържание или непоследователен домейн (www срещу не-www)

Divi 5 бързо става проблематичен, ако вашият сайт редува:

http:// et https://
www и неwww

Проверка Настройки> Общи „Уеб адрес на WordPress“ и „Уеб адрес на сайта“ трябва да са абсолютно еднакви.

Справка: Nonces (WordPress Security) (полезно за разбиране защо се чупи).

Решение 3: Поправете грешките 404, редактора на цикли и грешките 500 (постоянни връзки, пренаписване, памет, PHP)

Това решение обхваща три семейства грешки, които изглеждат сходни, но имат различни причини: 404, цикли на зареждане и критични грешки.

Случай A — 404 след инсталиране/миграция: постоянни връзки и правила за пренаписване

симптоми:

Някои страници работят, други връщат 404.
Конструкторът се зарежда, но някои вътрешни заявки се провалят.

Поправка за начинаещи (не се изисква код) :

отивам Настройки> Постоянни връзки.
Не променяйте нищо, просто кликнете Enregistrer.

Това регенерира правилата за презаписване. Много грешки 404 „след инсталацията“ се разрешават по този начин.

Официален документ: flush_rewrite_rules() (да не се извиква на всяка страница, вижте по-долу).

Случай Б — критична грешка / 500: повредена PHP памет и фрагменти

Ако видите „Възникна критична грешка на този уебсайт.“, започнете с проверка wp-content/debug.log (ако WP_DEBUG_LOG е активен) или PHP лог файловете на доставчика на хостинг услуги.

Реалистична грешка №1 : фрагмент, копиран на грешното място (напр. в wp-config.php но на грешното място) или забравена точка и запетая.

ПРЕДНА (счупена) : умишлено фалшив пример.

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

СЛЕД (коригирано) В wp-config.php, преди реда „спиране на редактирането“.

/** 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

Защо: Divi 5 (като Elementor/Avada) може да натовари администратора сериозно. Ако ограничението ви е 128MB, може да се сблъскате с произволни грешки, особено при инсталиране на множество плъгини.

PHP справочник (ограничения на паметта, конфигурация): PHP ограничение на паметта.

Случай C — Зареждане на цикли: OPcache и „остарели“ файлове

По-рядко срещано, но съм го виждал при агресивни доставчици на хостинг: OPcache запазва стари PHP файлове в паметта след актуализация. В резултат на това Divi/WordPress смята, че зарежда една версия, но сървърът всъщност работи с различна.

Диагностичен : грешката се появява веднага след актуализацията, изчезва „от само себе си“ няколко часа по-късно или след рестартиране на PHP-FPM.

Фиксирайте Помолете вашия доставчик на хостинг услуги да изчисти OPcache и да рестартира PHP-FPM. От страна на WordPress не можете да направите това насилствено без достъп до сървъра (и ви съветвам да не използвате скриптове "opcache_reset()" в продакшън режим: риск за сигурността, ако са лошо защитени).

Проверки след корекция

Не се задоволявайте само с „изглежда по-добре“. Тествайте по възпроизводим начин.

Фронт-енд тестване Отворете Divi страница в режим на частно сърфиране → CSS кодът трябва да е правилен от първото зареждане.
Конструктор на тестове Отворете Visual Builder, преместете модул, запазете, обновете → промяната трябва да се запази.
REST тест отворен /wp-json/ → Трябва да виждате JSON, а не блокиращ HTML.
Конзоли Няма червени грешки, свързани с липсващи (404) или отхвърлени (403) файлове.
Монитор на заявките Проверете „HTTP API извиквания“ и „PHP грешки“. Нула фатални грешки и никакви повтарящи се грешки 401/403.

Ако използвате Divi 5 с Elementor или Avada на един и същ сайт: проверете страница, създадена с всеки конструктор. Лошо конфигуриран кеш може да повреди единия конструктор, а не другия, давайки неверни улики.

Ако това все още не работи

Процедура за отстраняване на неизправности, която използвам, когато проблемът е „лепкав“. Правете го по ред: така избягвате сляпа промяна на 10 настройки.

1) Изолиране на конфликт между плъгин/тема, без да се нарушава работата на сайта (Проверка на състоянието)

инсталирам Проверка на състоянието и отстраняване на неизправности, Тогава :

Активирайте режим на отстраняване на неизправности (само за теб).
Деактивирайте всички плъгини с изключение на Divi (и тези, които са от съществено значение).
Тествайте конструктора.

Ако работи в режим на отстраняване на неизправности, имате конфликт. Активирайте отново плъгините един по един, като тествате всеки път.

2) Проверете за грешки в PHP и версията на PHP

Препоръчва се PHP минимум 8.1. Ако използвате 8.0 или 7.4: играете си с огъня (сигурност + съвместимост).
Regardez wp-content/debug.log и лог файловете на сървъра.

3) Проверете разрешенията за файлове

Симптом: Грешки 403/404 във файлове в wp-content/themes/ ou wp-content/uploads/.

Файлове: 755 (често)
Файлове: 644 (често)

Ако не сте сигурни, попитайте вашия доставчик на хостинг услуги. Никога не използвайте „chmod 777“: това е риск за сигурността.

4) Проверете пренаписването (Apache/Nginx)

Ако постоянните връзки не се регенерират, може да имате проблем с конфигурацията на сървъра (mod_rewrite, правила на Nginx). Това е често срещано явление след миграция.

Справка: WordPress на Apache.

5) Проверете конзолата на браузъра и мрежовите заявки

Повтарям това, защото спестява часове: ако конструкторът не се зареди, конзолата и мрежата почти винаги ви казват защо (добавят кодове 404, 403 WAF, CORS и т.н.).

Често срещани капани и грешки

Симптом / грешка	Вероятна причина	Препоръчително решение
„Зареждане...“ безкрайно в Divi 5	REST API блокиран (401/403), JS забавен	Изключете /wp-json/ и Divi скриптове от оптимизациите, проверете WAF
CSS липсва след актуализацията	Кеш CDN/плъгинът предоставя по-стара версия	Изчистване на всички кешове (плъгин, сървър, CDN, браузър)
Критична грешка веднага след добавяне на фрагмент	Кодът е поставен на грешното място, забравена е точка и запетая	Възстановяване на резервно копие, коригиране на синтаксиса, използване на персонализиран плъгин
Видими Divi кратки кодове	Конструкторът е деактивиран, конфликт на плъгина, който филтрира the_content	Изолиране чрез проверка на състоянието, деактивиране на дефектния плъгин
„Невалиден еднократен номер“ / 403 admin-ajax	Бисквитките са блокирани, кешът е на лични страници, WAF	Изключване на admin/AJAX от кеша, проверка на https/www домейна, регистрационни файлове за сигурност
Всичко работи локално, но не и в продукцията.	Оптимизация на CDN/WAF/OPcache/сървър	Временно деактивирайте CDN, изчистете OPcache чрез доставчика на хостинг услуги и сравнете заглавките.

Човешки грешки, които често виждам:

Копирайте кода в style.css вместо functions.php (или обратното).
Да объркаш действие et Филтър Действието изпълнява код в даден момент; филтърът променя стойност и трябва връщане нещо.
Твърде ранно използване на hook (напр. манипулиране на скриптове, преди WordPress да ги запише).
Тестване директно в продукцията без запазване или частно сърфиране.

Вариант / алтернатива

Метод без код: започване от „безопасна“ конфигурация по отношение на производителността

Ако сте начинаещ, най-добрият подход често е:

Временно деактивирайте JS минификацията/комбинацията/забавянето.
Проверете дали Divi 5 е стабилен.
Активирайте отново оптимизациите една по една, като изключвате Divi/REST, ако е необходимо.

Това работи и за Elementor и Avada: търсите настройката, която нарушава реда на изпълнение на JS.

Метод за разработчици: изолирайте точните дръжки, които да изключите, чрез Query Monitor

С Query Monitor, в раздела „Скриптове“, можете да видите дръжки действително заявени. Дръжката е вътрешният идентификатор на скрипт в WordPress. След това можете специално да изключите тези дръжки във филтъра script_loader_tag (Решение 1) вместо съвпадащи URL фрагменти.

Официален документ от разследването: wp_enqueue_script ().

Избягвайте този проблем в бъдеще

Избягвайте „магически“ фрагменти Те обещават 100/100 PageSpeed , докато отлагат всичко. Те често са предшественици на съвременните конструктори на страници.
Предпочитайте персонализиран плъгин вместо да поставяте код в functions.phpЗапазвате корекциите си, дори ако сменяте теми.
Документирайте изключенията си от кеша (обикновен текстов файл): /wp-json/, admin-ajax.php, страници за изграждане.
Актуализиране на етапи WordPress, след това Divi, накрая плъгини. Тествайте между всеки от тях.
Следете за грешки : плъгин като Query Monitor в етап на подготовка и чисти лог файлове в продукция.

Ако е необходимо да добавяте постоянни връзки в кода (например, когато плъгинът е активиран), правете го само при активиране, никога при всяко зареждане:

<?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();
} );

за какво: flush_rewrite_rules() е скъпо. Извикването му на всяка страница може значително да забави сайта.

ресурси

Често задавани въпроси

Съвместим ли е Divi 5 с WordPress 6.9.4?

Да, на практика това е често срещана комбинация през 2026 г. Проблемите след инсталацията по-често произтичат от проблеми с кеширането/оптимизацията/сигурността, отколкото от „чиста“ несъвместимост. Поддържайте Divi и WordPress актуални и тествайте в тестова среда.

Трябва ли да деактивирам плъгина за кеширане, за да използвам Divi 5?

Не. Но често ще ви се налага изключвам Избягвайте определени крайни точки (REST/AJAX) и прекалено агресивни опции за „JS забавяне“. Ако активирате опция и конструкторът се повреди, значи сте открили виновника.

Защо получавам грешки 401/403 на /wp-json/, въпреки че съм свързан?

Най-честата причина са блокирани „бисквитки“ (непоследователен www/не-www домейн), кеширане на частни страници или WAF, блокиращ POST заявки. Проверете последователността на URL адресите на сайта и тествайте, като временно деактивирате защитата/CDN.

Мога ли да поставя фрагментите в плъгин „Фрагменти от код“?

Да, но с повишено внимание. Неработещ фрагмент все още може да срине сайта, ако плъгинът го изпълни навсякъде. Предпочитам малък, версиран персонализиран плъгин (дори минимален), защото имате по-добър контрол върху това, което се зарежда.

Конструкторът работи за мен, но не и за друг администратор: защо?

Често причината е кешът на браузъра, разширението или различна политика за „бисквитките“. Опитайте да тествате в режим на частно сърфиране, без разширения, и сравнете мрежовите заявки (401/403).

Получавам грешка 500 само когато отворя Visual Builder.

Това сочи към ограничение на паметта, изтичане на времето или фатална грешка, задействана по определен маршрут (REST/AJAX). Активирайте WP_DEBUG_LOG, възпроизведете грешката и след това прочетете лога. wp-content/debug.log.

Divi 5 + Elementor на същия сайт: това лоша идея ли е?

Не е „забранено“, но увеличава риска от конфликти (глобални скриптове, оптимизация, CSS). Ако трябва да го направите, избягвайте оптимизации, които комбинират/отлагат всичко, и тествайте всеки конструктор след всяка актуализация.

Трябва ли редовно да „прочиствам постоянните връзки“?

Не. Направете го, когато промените структурата на постоянните си връзки, мигрирате сайта или инсталирате плъгин, който добавя маршрути. В кода, само когато активирате/деактивирате плъгин.

Какво е първото нещо, което трябва да проверите, когато Divi 5 „не се зарежда“?

Конзолата и разделът „Мрежа“. Почти винаги ще видите грешка 401/403 (REST/AJAX), грешка 404 на JS/CSS блок или скрипт, блокиран от оптимизация.