Как да създадете и получите достъп до Error Logs за WordPress (3 метода)

Журналите за грешки на WordPress са диагностични записи, които улавят PHP грешки, фатални изключения, неуспехи на базата данни, конфликти на плъгини и несъвместимости на теми, докато се появяват на вашия сървър. Достъпът и интерпретирането на тези журнали е най-бързият начин да идентифицирате основната причина за повредена страница, бял екран на смъртта или тихо влошаване на производителността — без да гадаете или да деактивирате плъгини един по един.

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

Защо журналите за грешки на WordPress са важни

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

Без журнал, актуализация на плъгин, която въвежда фатална грешка, произвежда само празен екран. Неправилно конфигурирана SMTP библиотека тихо изпуска имейли. Превишаването на лимита на паметта убива зареждането на страница без видима следа. Журналите за грешки превръщат тези невидими неуспехи в записи с времеви печат, препратка към файл и номер на ред, върху които можете да действате незабавно.

Метод 1: Активиране на режима за отстраняване на грешки на WordPress чрез wp-config.php

WordPress се доставя с вградена подсистема за отстраняване на грешки, контролирана от набор от PHP константи, дефинирани в wp-config.php. Това е най-прецизният метод, защото улавя специфични за WordPress грешки, включително тези, хвърлени от API на плъгините, зареждача на теми и слоя за абстракция на базата данни (wpdb).

Стъпка 1: Намерете и отворете wp-config.php

Свържете се с вашия сървър чрез SFTP (предпочитано пред обикновен FTP за сигурност), използвайки клиент като FileZilla или Cyberduck, или отворете файловия мениджър на вашия хостинг доставчик. Навигирайте до основната директория на WordPress, обикновено /public_html/ или /var/www/html/. Файлът wp-config.php се намира в основата на тази директория.

Ако имате SSH достъп, можете да го редактирате директно:

nano /var/www/html/wp-config.php

Стъпка 2: Конфигурирайте константите за отстраняване на грешки

Намерете съществуващия ред:

define( 'WP_DEBUG', false );

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Какво прави всяка константа:

• WP_DEBUG — активира двигателя за отстраняване на грешки на WordPress и активира отчитането на PHP грешки на ниво E_ALL.
• WP_DEBUG_LOG — записва всички уловени грешки в лог файл вместо (или в допълнение към) екрана.
• WP_DEBUG_DISPLAY — когато е зададено на false, потиска извеждането на екрана. Това е критично за производствени сайтове; без него PHP известията разкриват вътрешни пътища до файлове и имена на променливи на посетителите.
• display_errors — основната PHP директива; задаването й на 0 чрез ini_set осигурява втори слой на потискане в случай, че плъгин или тема замени WP_DEBUG_DISPLAY.

Стъпка 3: Намерете файла с журнала за отстраняване на грешки

С WP_DEBUG_LOG зададено на true, WordPress записва грешки в:

/wp-content/debug.log

Този файл се създава автоматично при първата записана грешка. Можете да го преглеждате чрез SFTP или SSH:

tail -f /var/www/html/wp-content/debug.log

Флагът tail -f предава нови записи в реално време, което е безценно при възпроизвеждане на конкретна грешка интерактивно.

Стъпка 4: Използвайте персонализиран път до журнала (препоръчително за сигурност)

Пътят по подразбиране debug.log е публично достъпен, ако вашият уеб сървър не го блокира изрично. Неправилно конфигуриран сървър ще обслужва https://yourdomain.com/wp-content/debug.log на всеки посетител, излагайки вътрешни пътища, префикси на таблици в базата данни и имена на класове.

Вариант A — Преместете лог файла извън уеб корена:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Създайте целевата директория и задайте разрешения:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Вариант B — Блокирайте пътя по подразбиране чрез .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Вариант C — Еквивалент за Nginx във вашия сървърен блок:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Стъпка 5: Деактивирайте режима за отстраняване на грешки след отстраняването на проблема

Никога не оставяйте WP_DEBUG зададено на true на работещ сайт по-дълго от необходимото. След като проблемът е решен:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Оставянето на режима за отстраняване на грешки активен на производствен сайт влошава производителността (PHP обработва всяко E_ALL известие) и може да разкрие чувствителни проследявания на стека, ако WP_DEBUG_DISPLAY е случайно зададено на true.

Метод 2: Достъп до журнали за грешки на ниво сървър чрез вашия хостинг контролен панел

Грешките на WordPress, които се появяват преди завършването на зареждането на WordPress — като повреден wp-config.php, несъвместимост на версията на PHP или неуспешна връзка с базата данни — никога няма да се появят в debug.log, защото самият WordPress никога не се зарежда. За тях ви е необходим PHP журналът за грешки на сървъра или журналът за грешки на Apache/Nginx.

Хостинг базиран на cPanel

Ако вашата хостинг среда използва VPS с cPanel, журналът за грешки е достъпен чрез интерфейса на контролния панел:

1. Влезте в cPanel.
2. Навигирайте до Metrics > Errors.
3. Панелът показва последните 300 реда от журнала за грешки на Apache за вашия акаунт.

За пълния лог файл използвайте File Manager на cPanel или се свържете чрез SFTP и навигирайте до:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

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

Хостинг базиран на Plesk

В Plesk навигирайте до Websites & Domains > изберете вашия домейн > Logs. Можете да филтрирате по тип журнал (достъп, грешка, PHP) и да изтеглите пълния лог файл.

Директен достъп до сървъра (VPS или Dedicated)

В среда с VPS Хостинг или Dedicated сървър, където имате root достъп, местоположенията на журналите зависят от вашия стек:

За наблюдение на PHP-FPM журнала в реално време:

tail -f /var/log/php8.2-fpm.log

За търсене на специфични за WordPress фатални грешки в журнала на Apache:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Конфигуриране на записването на PHP грешки на ниво сървър

Ако PHP грешките не се записват в журнал, проверете вашата php.ini конфигурация:

php --ini | grep "Loaded Configuration"

Отворете идентифицирания php.ini файл и проверете или задайте:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Рестартирайте PHP-FPM след промените:

systemctl restart php8.2-fpm

Алтернативно, заменете PHP настройките за всеки сайт, използвайки .htaccess файл (само Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Метод 3: Използвайте плъгин за записване на грешки на WordPress

За среди, където директният достъп до сървъра е ограничен — като Споделен уеб хостинг — или за екипи, където нетехнически администратори трябва да преглеждат грешки без SSH достъп, плъгин за WordPress предоставя жизнеспособна алтернатива.

Препоръчани плъгини

• WP Log Viewer — чете съществуващия debug.log файл и го показва в администраторския панел на WordPress с филтриране и търсене.
• Error Log Monitor — добавя джаджа на таблото за управление, показваща скорошни грешки, и може да изпраща имейл сигнали при записване на нови грешки.
• Query Monitor — надхвърля записването на грешки, за да профилира заявки към базата данни, HTTP API извиквания, куки и условни тагове. Незаменим за отстраняване на проблеми с производителността.
• Health Check & Troubleshooting — официалният плъгин на WordPress.org; активира режим за отстраняване на проблеми, който активира тема по подразбиране и деактивира всички плъгини само за вашата сесия, без да засяга другите посетители.

Инсталиране и конфигуриране на Error Log Monitor

1. В администраторския панел на WordPress отидете на Plugins > Add New.
2. Потърсете Error Log Monitor и кликнете Install Now, след това Activate.
3. Навигирайте до Settings > Error Log Monitor.
4. Задайте пътя до лог файла. Ако сте преместили debug.log извън уеб корена, въведете абсолютния път на сървъра тук.
5. Конфигурирайте честотата на имейл сигналите, ако искате известия за нови типове грешки.

Плъгинът чете същия debug.log файл, в който WP_DEBUG_LOG записва. Той не създава отделен механизъм за записване — той е прегледач. Това означава, че WP_DEBUG и WP_DEBUG_LOG трябва все още да са активирани в wp-config.php, за да може плъгинът да показва нещо.

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

Сравнение: Три метода за записване на грешки на WordPress

Четене и интерпретиране на записи в журнала за грешки на WordPress

Необработен запис в debug.log изглежда така:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Как да четете това:

• Времевият печат е в UTC — конвертирайте към местната часова зона на вашия сървър, ако е необходимо.
• PHP Fatal error означава, че изпълнението е спряло. Страницата, която е задействала това, е върнала грешка 500 или празен екран.
• Call to undefined function get_field() означава, че плъгинът Advanced Custom Fields е или деактивиран, или зареден след като functions.php на темата е опитал да го извика.
• Проследяването на стека показва точния файл и номер на ред. Започнете отстраняването на грешки на ред 47 от functions.php.

Чести модели на грешки и техните причини:

• PHP Warning: require(): Failed opening required — пътят до файл е грешен или файлът липсва. Често причинено от плъгин, препращащ към файл, който е бил изтрит.
• PHP Deprecated: Function _register_controls is deprecated — плъгин или тема използва остарял API. Не е фатално, но указва плъгин, който не е актуализиран за текущата версия на WordPress/Elementor.
• WordPress database error ... for query — заявка wpdb е неуспешна. Проверете за несъответствия в префикса на таблицата или повредени таблици.
• Maximum execution time of 30 seconds exceeded — скрипт е работил твърде дълго. Често срещано при големи импорти, неоптимизирани заявки или извиквания към външни API, които изтичат по време.
• Allowed memory size of X bytes exhausted — PHP е достигнал лимита на паметта. Увеличете memory_limit в php.ini или идентифицирайте плъгина, причиняващ изтичане на памет.

Най-добри практики за управление на журнали за грешки на WordPress

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

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Никога не добавяйте debug.log към системата за контрол на версиите. Добавете го към .gitignore:

wp-content/debug.log

Проверявайте вашия wp-config.php след всяка миграция на сървъра. Миграциите на хостинг често нулират WP_DEBUG до false или въвеждат нов шаблон wp-config.php, който презаписва вашите константи.

Използвайте SAVEQUERIES за отстраняване на грешки на ниво база данни. Добавете тази константа заедно с WP_DEBUG, за да записвате всяка SQL заявка, изпълнявана от WordPress:

define( 'SAVEQUERIES', true );

След това проверете $wpdb->queries в персонализиран шаблон или чрез Query Monitor. Деактивирайте го незабавно след употреба — той съхранява всяка заявка в паметта и значително увеличава потреблението на RAM.

Съпоставяйте времевите печати на журналите със събитията при внедряване. Ако се появи нов тип грешка, проверете дали съвпада с актуализация на плъгин, актуализация на основата на WordPress или промяна на версията на PHP на сървъра. Повечето хостинг контролни панели записват промените на версията на PHP в отделен одитен журнал.

Матрица за решения: Кой метод да използвате

Технически контролен списък с ключови изводи

• Задайте WP_DEBUG_DISPLAY на false преди активиране на WP_DEBUG_LOG на всеки сайт с живи посетители.
• Преместете debug.log извън уеб корена или го блокирайте чрез правила на сървъра — пътят по подразбиране е публично достъпен.
• Използвайте tail -f върху лог файла при интерактивно възпроизвеждане на грешки; елиминира необходимостта от ръчно обновяване на файла.
• PHP и Apache/Nginx журналите на ниво сървър са единственият достоверен източник за грешки, възникващи преди зареждането на WordPress.
• Базираните на плъгини прегледачи на журнали изискват WP_DEBUG_LOG да е активен — те са четци, не писачи.
• Внедрете ротация на журналите на всеки сървър, където WP_DEBUG_LOG е активиран за повече от няколко часа.
• Никога не оставяйте SAVEQUERIES активиран в производствена среда; той е отговорност за паметта и производителността.
• След решаване на проблем, задайте всички константи за отстраняване на грешки обратно на false и проверете с браузърна заявка, че в изходния код на страницата не се появяват PHP известия.

—

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

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

WordPress записва журнала за отстраняване на грешки в /wp-content/debug.log спрямо основната директория на WordPress. Този път се създава само след записването на първата грешка и само когато и WP_DEBUG, и WP_DEBUG_LOG са зададени на true в wp-config.php. Можете да замените пътя, като подадете абсолютен низ с пътя до файла като стойност на WP_DEBUG_LOG вместо true.

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

Безопасно е само ако WP_DEBUG_DISPLAY е изрично зададено на false и display_errors е зададено на 0. Без тези две настройки, PHP грешките — включително вътрешни пътища до файлове и имена на таблици в базата данни — се изобразяват директно в HTML изходния код на всяка страница. Винаги съчетавайте WP_DEBUG true с WP_DEBUG_DISPLAY false на всеки сайт с публичен трафик.

Защо моят debug.log файл е празен, въпреки че WP_DEBUG е активиран?

Най-честите причини са: процесът на уеб сървъра няма разрешение за запис в директорията /wp-content/; WP_DEBUG_LOG е зададено на false или липсва от wp-config.php; или грешката се появява на ниво сървър преди зареждането на WordPress, което означава, че ще се появи в журнала на Apache или PHP-FPM, а не в debug.log. Проверете разрешенията на директорията с ls -la wp-content/ и проверете дали константите са дефинирани в правилния ред в wp-config.php.

Каква е разликата между WP_DEBUG_LOG и PHP журнала за грешки на сървъра?

WP_DEBUG_LOG е константа на ниво WordPress, която насочва грешките, уловени от персонализирания обработчик на грешки на WordPress, към debug.log. PHP журналът за грешки на сървъра (конфигуриран чрез error_log в php.ini) улавя всички PHP грешки на ниво интерпретатор, включително тези, които се появяват преди инициализирането на WordPress. На правилно конфигуриран сървър и двата журнала са активни едновременно и се допълват взаимно.

Мога ли да активирам записването на грешки на споделен хостинг без SSH достъп?

Да. Можете да редактирате wp-config.php чрез File Manager на вашия хостинг доставчик в cPanel или Plesk, да активирате WP_DEBUG и WP_DEBUG_LOG, и след това да четете debug.log чрез същия интерфейс на File Manager. За журнали на ниво сървър на Споделен уеб хостинг, използвайте секцията Errors под Metrics в cPanel. Ако ви е необходим по-детайлен контрол върху конфигурацията на PHP и пътищата до журналите, надграждането до план с VPS Хостинг ви дава директен достъп до php.ini и пълен SSH достъп до всички лог файлове.