Бял екран в WordPress: 5 лесни решения

by | WordPress

Ако вашият сайт WordPress изведнъж показва напълно празна страница. без Посланието е, че не сте „прокълнати“: просто сте изправени пред фатална грешка, която WordPress не може да покаже правилно.

Проблемът

„WSOD“ (Бял екран на смъртта) се появява като пълна липса на съдържание. Понякога получавате еквивалент от страна на сървъра, като например грешка 500 или минимално съобщение като:

HTTP ERROR 500

Или, ако хостингът показва PHP грешки (рядко срещани в продакшън), нещо подобно:

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

Къде и кога се появява?

  • Front-End празна начална страница или само определени страници (често страница с кратък код, уиджет, специфичен шаблон).
  • Администратор (/wp-admin) : бял екран при влизане, недостъпно табло за управление или бял екран на определена страница (Разширения, Външен вид, Редактор...).
  • Cron / планирани задачи Сайтът „работи“, но някои действия (имейли, импорт) спират и откривате грешки в лог файловете.
  • REST API / AJAX Elementor/Divi/Avada вече не може да зареди редактора, XHR заявките се провалят или прегледът не се зарежда.

Типични ситуации, които виждам най-често:

  • Веднага след актуализация (WordPress 6.9.4, a плъгин(тема, конструктор).
  • След добавяне на отрязък в functions.php или чрез плъгин за фрагменти.
  • След активирането на „тежък“ плъгин (кеш, сигурност, конструктор, електронна търговия).
  • След промяна от страна на сървъра (PHP версия, OPcache модул, ограничения на паметта).

За кого е това: Ако сте начинаещ, но имате достъп до вашия FTP/файлов мениджър (или поне до администраторския панел), ще можете правилно да диагностицирате и да възстановите сайта. В крайна сметка ще знаете намерете точната грешка, изолирайте виновника (плъгин/тема/фрагмент) и избягвайте фалшиви бели екрани, причинени от кеша.

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

  • Не гадай Активирайте отстраняването на грешки и прочетете грешката (Решение 1).
  • Изолирайте деактивирайте всички плъгини и се върнете към тема по подразбиране (Решение 2).
  • Проверете паметта Много WSOD-и произхождат от Разрешеният размер на паметта е изчерпан (Решение 3).
  • откъси липсваща точка и запетая в functions.php достатъчно, за да избели всичко (Разтвор 4).
  • Кеш Можете да „поправите“ сайта, без да го виждате, ако OPcache/CDN обслужва старата версия (Решение 5).

Симптомите

WSOD не винаги е „просто празна страница“. Ето конкретните признаци, които трябва да търсите (и какво подсказват те).

  • Пълна празна страница (отпред), но / Wp-Admin работи: често проблем в темата, шаблон, шорткод или повреден кеш на страницата.
  • / Wp-Admin бяло също: по-често фатална PHP грешка (плъгин, тема, фрагмент) или ограничение на паметта.
  • 500 грешка в браузъра: често фатална PHP грешка, конфигурация на сървъра или модул (OPcache), който обслужва остарял код.
  • Редакторът Elementor/Divi/Avada вече не се зарежда Грешки в REST API/AJAX, проблеми с паметта, конфликти на плъгини (сигурност/кеширане) или скрити JS грешки.
  • Сайтът работи локално но не и в продукцията: разлики във версията на PHP, PHP разширенията, ограниченията на паметта, кеша на сървъра, разрешенията за файлове.
  • Само определени страници : счупен шорткод, твърде голяма заявка, безкраен цикъл или изображение/ресурс, който препълва паметта.

Бърза диагностика от страна на браузъра: отворете конзолата (F12) и вижте:

  • Конзоли Грешки в JavaScript (особено полезни за разработчици).
  • мрежа XHR заявки към /wp-json/ (REST API) или admin-ajax.php в 500/403.

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

Просто обяснение (за начинаещи)

WordPress изпълнява PHP код (теми + плъгини). Ако PHP срещне фатална грешка, изпълнението спира незабавно. В зависимост от конфигурацията на вашия сървър, грешката може да бъде скрита (от съображения за сигурност) и може да видите само бял екран.

Следователно, Световният ден на света рядко е „мистичен“. Той почти винаги е:

  • un грешка в кода (плъгин/тема/фрагмент),
  • un липса на ресурси (памет/време),
  • където скривалище което ви показва повредена версия, въпреки че сте я поправили.

Техническо обяснение (средно ниво/професионално)

Зад кулисите, грешката често възниква по време на зареждането на WordPress hooks-ове. кука е точка на разширение: a действие изпълнява код в даден момент, a Филтър променя стойност (напр. съдържанието), преди тя да бъде използвана.

Причините (от най-честите до най-редките), заедно с това, което наблюдавам при отстраняване на проблеми с WordPress 6.9.4:

  • Плъгинът е несъвместим с PHP 8.1+ (или грешка след актуализацията).
  • Тема / Детска тема код в functions.phpшаблон или презаписване WooCommerce.
  • Откъс, копиран от стар урок (остаряла функция, неправилен hook или код, изпълнен твърде рано).
  • Недостатъчно PHP памет (конструктори + WooCommerce + плъгини за сигурност = класическа комбинация).
  • Кеш на сървъра (OPcache) / CDN който предлага остаряла версия.
  • Разрешения (по-рядко срещано за истински WSOD, но може да причини 500 грешки).

За да ви помогнем да се ориентирате, ето една диагностична таблица: „симптом → проверка → решение“.

симптом Вероятна причина проверка Решение
Бял екран навсякъде Фатална грешка в PHP Активиране на WP_DEBUG + четене debug.log Решение 1 + 2
500 грешка Фатален PHP / ограничение на паметта / кеш на сървъра Сървърни логове + debug.log Решение 1 + 3 + 5
Администратор ОК, бяла предна част Кеш на тема / кратък код / ​​страница Временна промяна на темата + изчистване на кеша Решение 2 + 5
Elementor/Divi вече не отваря редактора REST/AJAX грешка, памет Конзола + Мрежа (XHR 500/403) Решение 3 + „Ако това все още не работи“
WSOD след добавяне на фрагмент Синтактична грешка / твърде рано се закачи Последна промяна на файла, лог файлове Solution 4

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

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

  • wp-config.php
  • папката wp-content (или поне themes et plugins)

Препоръчителни технически предварителни изисквания (WordPress 6.9.4 към април 2026 г.):

  • PHP 8.1 + (минимално препоръчително). Ако сте под това ниво, значително увеличавате риска от грешки и уязвимости.
  • Достъп до FTP / SFTP или към файловия мениджър на хостинг доставчика.
  • В идеалния случай постановка (тестов сайт). Много доставчици на хостинг предлагат това с едно кликване.

Полезни (безплатни) инструменти:

Златно правило : никога не модифицирайте ядрото (файловете на WordPress в wp-includes / wp-admin). Корекцията се извършва в плъгин, дъщерна тема или конфигурацията.

Решение 1: Активирайте правилно отстраняването на грешки (и намерете точната грешка)

Празен екран без видими грешки ви кара да гадаете. Целта тук е да се получи използваемо съобщение в лог файл.

Къде да се намесите: във файла wp-config.php, в основата на WordPress (на същото ниво като wp-content).

Запазете, преди да правите промени. Печатна грешка в wp-config.php може да направи сайта недостъпен.

ПРЕДИ (типична конфигурация, която скрива всичко)

Много сайтове нямат нищо или имат непълно отстраняване на грешки:

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

СЛЕД (ориентирано към отстраняване на грешки, без показване на посетителите)

Добавете (или коригирайте) тези константи. Поставете ги Avant la ligne /* That's all, stop editing! */ ако съществува във вашия файл.

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

Следващия :

  1. Презаредете празната страница (начална или администраторска).
  2. отворено wp-content/debug.log и потърсете последната грешка.

Примери за грешки, които може да видите:

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

Защо това решава проблема: понякога „WSOD“ не се отстранява от тази стъпка, но вие се възстановявате. информация което позволява бърза корекция (конкретен плъгин, конкретен файл, конкретен ред). Без него губите време.

Когато сте готови: предайте го WP_DEBUG à false на производствен сайт. Поддържането на активен лог може да разкрие пътища до сървъра и чувствителна информация, ако файлът е лошо защитен.

Официален източник: Отстраняване на грешки в WordPress

Решение 2: Изолиране на конфликт между плъгин/тема (метод за начинаещи + метод „без администраторски достъп“)

Според моя опит, WSOD много често произтича от актуализиран плъгин (или конструктор), който задейства фатална грешка. Целта: връщане към минимална конфигурация, след което реактивирането им един по един.

Метод А (за начинаещи): от администраторския панел, ако имате достъп

  1. отивам Разширения> Инсталирани разширения.
  2. Изберете всички, след това деактивирате.
  3. Тествайте сайта.
  4. Активирайте отново едно разширение наведнъж докато WSOD не се възпроизведе.

След това временно превключете към стандартна тема:

  • Външен вид > Теми > активирайте официална тема (често Twenty*).
  • Опитай отново.

Ако използвате Divi 5, Elementor или Avada: тези теми/конструктори добавят много код. Конфликтът с плъгин за кеширане/сигурност е често срещан. Тестът „тема по подразбиране + деактивирани плъгини“ е най-бързият начин да спрете този порочен кръг.

Метод Б (без администраторски достъп): чрез FTP/SFTP

Si /wp-admin е бяло, използвайте FTP/SFTP.

Стъпка 1: Деактивирайте всички плъгини наведнъж

Къде да се намесите: преименувайте папката wp-content/plugins en plugins.offWordPress ще счете плъгините за липсващи и ще ги деактивира.

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

Тествайте сайта. Ако проблемът се появи отново, значи сте потвърдили, че „плъгин(ите) са виновни“. След това преинсталирайте:

wp-content/plugins.off  →  wp-content/plugins

След това, вътре pluginsПреименувайте папките една по една (напр. elementor → elementor.off) за да се намери виновникът.

Стъпка 2: Принудително използване на резервна тема, ако темата се срине

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

Опция прост : Преименувайте папката на активната тема (или дъщерната тема). WordPress ще превключи към друга налична тема.

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

Защо това го поправя: спирате зареждането на сриващия код. Фатална грешка в плъгин/тема пречи на WordPress да продължи по-нататък.

Ако искате официално ръководство за отстраняване на неизправности: ЧЗВ за отстраняване на неизправности (WordPress.org)

Решение 3: Отстраняване на срив поради недостатъчна памет (PHP/WordPress)

Недостатъчната памет е често срещан проблем в сайтове, използващи Elementor/Divi/Avada + WooCommerce + плъгини за сигурност/кеширане. Симптомът понякога е WSOD, понякога грешка 500, а понякога редактор, който отказва да се зареди.

Типичното съобщение в debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

Стъпка 1: Увеличете паметта от страната на WordPress (бързо)

Къде да се намесите: в wp-config.php, преди „спиране на редактирането“.

ПРЕДИ (без изрично ограничение)

<?php
// ...

СЛЕД (иска от WordPress да използва повече памет)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

Защо работи: WP_MEMORY_LIMIT казва на WordPress целевата памет. Но ако вашият сървър наложи по-нисък лимит, WordPress няма да може да го надвиши.

Стъпка 2: Увеличете разпределението на паметта от страна на PHP (често е от съществено значение)

В зависимост от вашия доставчик на хостинг услуги, това се прави чрез:

  • панелът за настаняване (препоръчително),
  • файл php.ini ou .user.ini,
  • или конфигурацията на PHP-FPM (ако администрирате сървъра).

Пример (файл) .user.ini (в много услуги за споделен хостинг):

memory_limit = 512M
max_execution_time = 120

Официална справка за PHP (memory_limit): php.net ограничение_на_паметта

Какво тествам след увеличаване на паметта

  • Зареждане на празна страница.
  • Отваряне на редактора (Elementor/Divi/Avada).
  • Ако WooCommerce: добавете в количката, плащането и страницата на продукта.

Ако сайтът стане отново достъпен, но остане бавен, може да имате заявка, която се увеличава бързо (Query Monitor помага много).

Решение 4: Поправяне на счупен фрагмент (functions.php / snippet plugin) без да се повреди всичко

Най-разочароващият сценарий: добавяте 10 реда код, „за да подобрите WordPress“, запазвате... и всичко става празно. Често съм виждал това в сайтове, където кодът е поставен в грешен файл или с липсваща скоба.

Условия:

  • отрязък : малък фрагмент код, добавен към темата (често functions.php) или чрез плъгин.
  • Синтаксична грешка PHP не може да прочете файла (липсва точка и запетая, допълнителна къдрава скоба...). Това е фатално.

Случай A: Кодът е добавен към functions.php (дъщерна тема)

Къде да се намесите: wp-content/themes/VOTRE-THEME-ENFANT/functions.php

Много реалистична грешка: забравяне на точка и запетая или затваряне на къдрава скоба.

ПРЕДИ (невалидно: липсва точка и запетая)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

СЛЕД (коригирано)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

Защо това го поправя: PHP изисква точка и запетая, за да завърши инструкцията. Без нея, това ще доведе до грешка при парсинг и WordPress вече няма да може да се зареди.

Случай Б: кодът използва кука твърде рано (функцията "няма още заредена")

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

ПРЕДИ (счупено: незабавно изпълнение твърде рано)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

СЛЕД (коригирано: изпълнение чрез действие)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

Защо се коригира: init Изпълнява се след зареждане на WordPress. Това предотвратява преждевременните извиквания.

Случай C: фрагмент чрез плъгин (WPCode, фрагменти от код и др.)

Ако използвате плъгин за snippet код, предимството е, че понякога той може автоматично да деактивира фатален snippet. Но ако администраторският панел е недостъпен, деактивирайте плъгина за snippet код чрез FTP (Решение 2) и след това поправете snippet-а.

Референция (кукички): developer.wordpress.org/plugins/hooks

Решение 5: Премахване на фалшив WSOD, причинен от кеша (кеш на страници, CDN, OPcache)

Това е капан за много начинаещи: поправяте грешката, но все още виждате белия екран. В действителност, кешът обслужва повредена версия.

Често виждам това на:

  • сайтове зад Cloudflare (или друга CDN),
  • Доставчици на хостинг услуги с агресивно кеширане на сървъри
  • сайтове с активиран и неправилно деактивиран OPcache след внедряването.

Стъпка 1: Изчистете „видимите“ кешове

  • Изчистете кеша на плъгините си (LiteSpeed ​​​​Cache, WP Rocket, W3TC…).
  • Изчистете кеша на CDN (Cloudflare: „Purge Everything“ или целенасочено прочистване).
  • Тествайте в режим на частно сърфиране + чрез добавяне на параметър: ?nocache=1

Стъпка 2: OPcache (от страна на сървъра)

Ако имате достъп до сървъра, най-ефективното решение е да рестартирате PHP-FPM (в зависимост от вашия стек). Пример (Linux):

sudo systemctl reload php8.2-fpm

Ако сте на споделен хостинг, няма да имате тази команда. В този случай:

  • Потърсете опцията „изчистване на OPcache“ в панела.
  • или помолете екипа по поддръжка да изчисти OPcache (това често е стандартна заявка).

Защо това го поправя: OPcache може да съхранява по-стара версия на PHP файл в паметта. Вие поправяте файла... но PHP все още изпълнява старата версия.

Официална справка за OPcache: php.net OPcache

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

След като сайтът е отново активен, винаги извършвам едни и същи „основни, но ефективни“ тестове:

  1. преден Начална страница + 2-3 вътрешни страници + търсене.
  2. Admin Табло за управление, Разширения, Външен вид, Редактор (ако се използва).
  3. Строителите :
    • Elementor: отворете редактора + запазете промяната.
    • Divi 5: отворете Visual Builder + проверете адаптивния преглед.
    • Avada: отворете Fusion Builder + проверете редактирането на контейнера.
  4. форми изпратете формуляр (контакт/бюлетин).
  5. REST API бърз тест, като посетите /wp-json/ (трябва да видите JSON, а не празна страница).

Следващия :

  • Прочетете отново wp-content/debug.log : ако продължи да расте, все още имате грешки (дори ако сайтът „работи“).
  • Деактивирайте отстраняването на грешки, ако сте го активирали в производствения режим (Решение 1).

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

Когато 5-те „начинаещи“ решения не са достатъчни, преминавам към по-систематична процедура. Тя все още е достъпна, но изисква малко методичност.

1) Проверете лог файловете на сървъра (често са по-информативни от debug.log)

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

  • PHP Fatal error
  • Premature end of script headers
  • Allowed memory size

2) Използвайте „Проверка на състоянието“ (режим за отстраняване на неизправности)

Ако имате администраторски достъп, плъгинът Health Check ви позволява да деактивирате плъгини/теми. само за теббез да се отразява на посетителите. Това е много практично на действащ уебсайт.

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

3) Проверете актуалната версия на PHP

Даден уебсайт може да „мисли“, че работи с PHP 8.1, но поддомейн или cron задача може да работи с 7.4 (виждал съм го да се случва). Регистрирайте се:

  • Инструменти > Състояние на сайта
  • или панела на доставчика на хостинг услуги

4) Временно деактивирайте mu-плъгините

Les mu-плъгини (задължителните плъгини) се зареждат автоматично от wp-content/mu-pluginsТе са невидими в списъка със стандартни разширения. Някои доставчици на хостинг използват кешове/мерки за сигурност.

тест: преименувам mu-plugins en mu-plugins.off чрез FTP, след което тествайте.

5) Постоянни връзки / правила за пренаписване („admin OK, страници 404/500“)

Това не е най-чистият WSOD, но често се обърква след миграция или плъгин. Отидете на:

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

Официален документ: WP-CLI (за професионалисти) (полезно, ако имате SSH достъп, но тук е по избор).

6) Проверете разрешенията за файлове (рядко, но е реално)

Твърде ограничените разрешения могат да причинят грешки на сървъра. В споделени Linux среди често виждаме:

  • Файлове: 755
  • Файлове: 644

Ако вашият доставчик на хостинг услуги има различни препоръки, следвайте ги.

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

симптом Вероятна причина Препоръчително решение
Активирали сте WP_DEBUG, но debug.log не се появи wp-content Не е възможно да се записва / Неправилна конфигурация / Грешка преди зареждане Проверете разрешенията, след което вижте лог файловете на сървъра
WSOD веднага след поставяне на код Липсва точка и запетая/скоба, кодът е поставен на грешното място Решение 4 (коригиране на фрагмента), в идеалния случай в персонализиран плъгин
Работи в режим на частно сърфиране, но не „нормално“. Кеш на браузъра / плъгин / CDN Решение 5 (почистване) + временно деактивиране на минификацията
Elementor/Divi/Avada вече не отваря редактора Памет, REST/AJAX блокирани от сигурността, конфликт на плъгини Решение 3 + проверка на конзолата + деактивиране на плъгина за сигурност
Следвал си стар урок Несъвместим код WordPress 6.9.4 / PHP 8.1 Заменете с подход, използващ текущи куки, тествайте в етап на подготовка
Променихте родителската тема Загуба на модификации при актуализация, риск от повреда Връщане към дъщерна тема или персонализиран плъгин (вижте раздела „Избягване“)
WSOD се завръща след „поправяне“ OPcache/CDN все още използва старата версия Решение 5 (изчистване + презареждане на PHP-FPM, ако е възможно)

„Човешките“ грешки, които виждам най-често:

  • Поставете фрагмент в лош файл (напр. в шаблон вместо functions.php).
  • Забравяйки скоби където точка и запетая.
  • Да объркаш действие et Филтър (напр. употреба) add_action вместо add_filter).
  • Тествайте директно върху производство без резервно копие.
  • Забравете да изпразнете кеша след корекция.

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

Метод без код (препоръчително, ако сте начинаещ)

Ако имате достъп до администраторския панел, инсталирайте:

  • Здравен преглед За да деактивирате плъгини/теми само за вашата сесия: wordpress.org/plugins/health-check
  • Монитор на заявките За да прочетете грешките и да идентифицирате дефектния hook или плъгин: wordpress.org/plugins/query-monitor

Това е най-безопасният начин в онлайн сайт: проучвате, без да нарушавате потребителското изживяване.

По-напреднал метод (за разработчици): архивиране с mu-plugin

Ако често отстранявате неизправности (или управлявате множество сайтове), можете да създадете mu-плъгин (Автоматично зарежда се), за да се наложи минимално регистриране и да се избегне показването на грешки.

Къде да поставите кода: създайте файла wp-content/mu-plugins/00-rescue.php (създайте папката, ако не съществува).

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

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

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

Рискове: Записването на твърде много данни в лог файловете може да ги запълни. Поддържайте този файл минимален и го изтрийте след отстраняване на неизправности.

Официална справка за mu-плъгините: developer.wordpress.org/advanced-administration/plugins/mu-plugins

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

WSOD-ите се появяват отново, когато правите бързи решения, без да променяте навиците си. Ето какво всъщност намалява риска.

1) Направете промените си в персонализиран плъгин, а не във functions.php

За многократно използваеми фрагменти предпочитам малък, персонализиран плъгин. Предимството е, че можете да го деактивирате с едно щракване, без да се засяга темата.

Къде да поставите кода: създавам wp-content/plugins/mon-plugin-custom/mon-plugin-custom.php, след което го активирайте.

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

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

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) Приложете план за поетапно изпълнение

Тествайте актуализации (WordPress, плъгини, теми, конструктори) в тестова среда. Това е разликата между „5 минути стрес“ и „2 часа паника“.

3) Проверете за съвместимост с PHP 8.1+

Неподдържан плъгин може да се повреди след надграждане на версията на PHP. Проверете съвместимостта на страницата на плъгина (wordpress.org) и следете дневника на промените.

4) Поддържайте достъп за аварийни ситуации

  • Функционален SFTP/FTP достъп
  • Достъп до контролния панел на хостинга (логове, версия на PHP, кеш)
  • Ежедневно архивиране (в идеалния случай външно)

5) Кеш: документирайте вашия „път за прочистване“

В сайтове с CDN + кеш на плъгини + кеш на сървъра, ясно посочете къде да се изчисти. В противен случай ще „поправите“ нещо, без реално да видите решението.

ресурси

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

WSOD задължително ли идва от плъгин?

Не. Тема, дъщерна тема, фрагмент, недостатъчна памет или кеш на сървъра могат да доведат до абсолютно един и същ симптом. Най-бързият метод остава: debug.log + групово деактивиране (Решение 1 + 2).

Защо не получавам никакви съобщения за грешки?

Защото повечето сървъри крият PHP грешки в продукцията. Това е нормално (заради сигурността). Активирайте регистрирането чрез WP_DEBUG_LOG за да извлечете грешката, без да я показвате на посетителите.

Мога ли да поправя това без FTP?

Да, ако имате администраторски достъп: Проверка на състоянието + деактивиране на плъгини често е достатъчно. Без администраторски достъп, достъпът до файлове (FTP/SFTP) е най-прекият път.

Моят уебсайт е бял само на една страница, не навсякъде. Защо?

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

Elementor показва бял екран в редактора: същото ли е?

Често да, но проблемът може да е от страна на REST API/AJAX. Проверете раздела „Мрежа“: ако заявките към /wp-json/ ou admin-ajax.php върнете 500, потърсете PHP грешка (Решение 1) или липса на памет (Решение 3).

След като го коригирах, все още виждам бял екран. Какво да правя?

Помислете за кеширане: частно сърфиране, почистване на плъгини, почистване на CDN и, ако е възможно, почистване на OPcache (Решение 5). Това е много често срещан капан.

Опасно ли е да се активира WP_DEBUG на производствен сайт?

Ако показвате грешки на екрана, да (може да разкриете чувствителна информация). Ако само регистрирате (WP_DEBUG_DISPLAY à falseОсновният риск е генерирането на голям лог файл. Деактивирайте го след отстраняване на неизправности.

Кой файл трябва да променя: functions.php, wp-config.php или .htaccess?

За диагностициране: wp-config.php (Решение 1). За да коригирате фрагмент: functions.php от дъщерната тема или още по-добре персонализиран плъгин (Решение 4 / „Избягвайте“). .htaccess е по-скоро за проблеми с пренаписването/постоянните връзки, не за повечето WSOD-и.

Сайтът се възстановява, когато деактивирам плъгин, но той ми е нужен. Какво трябва да направя?

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

Статии

Коментирай

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани *

Този сайт използва Akismet за намаляване на спама. Научете как се обработват вашите коментарни данни.