Критични грешки в WordPress - причини и решения

Платформата WordPress е най-разпространената и масово използвана за създаване на уеб страници в Интернет. Това се дължи на отворената ѝ система за работа с теми и плъгини.

Но това крие и своите рискове от генериране на грешки, тъй като WordPress не е консистентна система, а е съставена от три отделни елемента – ядро, тема, разширения (плъгини).

Всички тези елементи използват собствени функции и функционалности, създадени от различни автори и това води до несъответствие и конфликти при работата на отделните елементи.

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

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

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

There has been a critical error on your WordPress website!

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

Като всяка многозадачна платформа, WordPress предлага режим на анализиране и структуриране на работата на приложението в така наречения „Дебъг“ режим (Debug).

В тази статия ще покажем кратки примери за решение на най-често срещаните критични грешки, свързани с WordPress и как да открием кой елемент е в конфликт.

1. Log файлове

Нека разгледаме как да използваме log файлове за анализ на причините за възникване на критични грешки:

1.1. PHP Error_log

Цялата налична информация за работата на приложението се съхранява в т.нар. Log файл, който записва всеки елемент от работата на WordPress.

Чрез няколко директиви PHP позволява да се записват грешки и предупреждения на работата на приложението със съответното PHP ядро.

В случай, че не са активирани, тези функции могат да бъдат пуснати със следните редове в index.php:

error_reporting(E_ALL); // Error/Exception engine, always use E_ALL

ini_set('ignore_repeated_errors', TRUE); // always use TRUE

ini_set('display_errors', FALSE); // Error/Exception display, use FALSE only in production environment or real server. Use TRUE in development environment

ini_set('log_errors', TRUE); // Error/Exception file logging engine.

ini_set('error_log', 'your/path/to/errors.log'); // Logging file path

Друг метод за активиране на лог файла е с правила в .htaccess файла, като се ползват следните директиви:

<IfModule mod_php5.c>

php_flag log_errors on

php_value error_log ./path_to_MY_PHP_ERRORS.log

# php_flag display_errors on

</IfModule>

В нашите споделен хостинг планове, тези директиви са зададени по подразбиране и в работната папка на домейна се генерира съответния error_log. Тези настройки са достъпни от полето PHP Select на cPanel, като се избере Options:

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

За целта е необходимо да укажем на WordPress да работи в дебъг режим , като добавим следната директиве във wp-config.php файла:

define('WP_DEBUG', true);

define('WP_DEBUG_DISPLAY', true);

define('WP_DEBUG_LOG', true);

define( 'SCRIPT_DEBUG', false );

Ето и кратка информация за всяка отделна директива и каква е нейната функция:

• WP_DEBUG – включва „дебъг“ режима на WordPress.
• WP_DEBUG_DISPLAY – показва съобщенията за грешки и информацията в HTML кода на страницата.
• WP_DEBUG_LOG – съхранява детайлите за грешките в лог файл.
• SCRIPT_DEBUG – стартира “dev” версиите на ядрото на CSS и JavaScript файловете  вместо оптимизираните (minified) версии.

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

1.2. Web server error log

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

Файлът и записите в него можете да откриете във Вашия cPanel акаунт, категория Metrics, полето Errors. Това реално е логът на уеб сървъра, който показва комуникацията между WP приложението и сървърната среда.

2. Анализиране и проследяване на грешката.

В повечето случай критичната грешка се генерира с код 500 и посоченото по-долу съобщение:

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

Тази грешка възниква, когато един или няколко PHP скрипта са спрели преждевременно работа или не могат да изпълнят до край своите процеси.

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

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

Имейлът съдържа и URL линк, който осигурява достъп до сайта в режим на „възстановяване“, тъй като в повечето случаи грешката засяга и административния панел, който също не е достъпен.

С това решение ще можете да влезете в административния панел и да решите възникналия казус.

2.1. Преглеждане на error_log файла.

Критичната грешка в лог файла е лесна за откриване, тъй като се инициира като Fatal Error. Нека да разгледаме пример за това:

[15-May-2024 10:51:30 UTC] PHP Fatal error:  Uncaught Error: Class 'Elementor\Core\Common\Modules\Connect\Module' not found in /home/cpaneluser/public_html/wp-content/plugins/elementor/core/common/app.php:69

Stack trace:

#0 /home/cpaneluser/public_html/wp-content/plugins/elementor/includes/plugin.php(767): Elementor\Core\Common\App->init_components()

#1 /home/cpaneluser/public_html/wp-content/plugins/elementor/includes/plugin.php(691): Elementor\Plugin->init_common()

#2 /home/cpaneluser/public_html/wp-includes/class-wp-hook.php(310): Elementor\Plugin->on_rest_api_init(Object(WP_REST_Server))

#3 /home/cpaneluser/public_html/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters(NULL, Array)

#4 /home/cpaneluser/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)

#5 /home/cpaneluser/public_html/wp-includes/rest-api.php(587): do_action('rest_api_init', Object(WP_REST_Server))

#6 /home/cpaneluser/public_html/wp-content/plugins/woocommerce/packages/woocommerce-blocks/src/BlockTypes/AbstractBlock.php(427): rest_get_server()

#7 /home/cpaneluser/public_html/wp- in /home/cpaneluser/public_html/wp-content/plugins/elementor/core/common/app.php on line 69

Първият ред ни дава информация в колко часа е възникнала грешката и кой файл я е генерирал.

[15-May-2024 10:51:30 UTC] PHP Fatal error:  Uncaught Error: Class 'Elementor\Core\Common\Modules\Connect\Module' not found in /home/cpaneluser/public_html/wp-content/plugins/elementor/core/common/app.php:69

От примера се вижда, че плъгинът Elementor е генерирал грешка във файла app.php на ред 69. Конкретната грешка е за неправилно генериран клас.

Останалите редове показват операциите и процесите, които са се генерирали до възникването на грешката, като броенето започва от 0.

Разчитайки този лог, можем да се насочим конкретно каква е причината, довела до критичната грешка.

2.2. Определяне на елемента, който генерира грешката

Критичната грешка може да се генерира от следните елементи:

• Ядрото на WordPress
• Неуспешна връзка между ядрото и базата данни
• Темата
• Плъгините
• Версията на PHP

Ще разгледаме детайлно всеки един елемент и възможните решения.

2.2.1. Критична грешка в ядрото на  WordPress

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

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

Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "wpse242371_remove_editor_from_some_pages" not found or invalid function name

in /home/cpaneluser/public_html/wp-includes/class-wp-hook.php:308

Нека да анализираме грешката. В началото виждаме, че тя се генерира от системния файл class-wp-hook.php на примерен ред 308.

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

Евентуално решение:

Опция 1: Ако разполагаме с бекъп на системата от преди датата на грешката, можем да го възстановим от архив към последна дата, в която приложението е работило коректно.

В нашата хостинг среда се използва инструмента JetBackup5. Важно е да възстановим както базата данни, така и файловете на приложението.

Опция 2: Възстановяване само на системните файлове от чиста инсталация или конкретния файл, който генерира грешка. За тази опция са ни необходими няколко стъпки:

• Стъпка 1: Проверяваме версията на ядрото, което използваме, например 6.5. От инструмента WordPress Manager by Softaculous правим нова инсталация на версия 6.5. на примерен поддомейн например: test.domainame.tld .
• Стъпка2: През File Manager-a на cPanel можем да копираме файловете от ядрото на чистата инсталация от поддомейна към инсталацията с генерираната грешка. Изключително важно е да запазим конфигурационните файлове и съдържанието на сайта, поради което не трябва да презаписваме следните файлове: wp-config.php, .htaccess както и папка /wp-content/ и всички файлове в нея, тъй като тя съдържа информация за текущият сайт и всички качени към него елементи, теми и плъгини.

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

Друга възможност за качване на системните файлове е, ако разполагате с чиста инсталация на конкретната версия на WordPress локално. Можете да използвате FTP клиент и да качите файловете чрез него, като пак е необходимо да съхраните предварително конфигурационните файлове и папката със съдържанието на приложението.

2.2.2. Критична грешка при неуспешна връзка между ядрото и базата данни

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

• Некоректни входни данни за базата
• Повредена база данни
• Повредени файлове на инсталацията на WP
• Казус със сървъра за базата данни
• Завишен трафик или достигане на лимити на сървъра (хостинг плана)

2.2.2.1. Грешно подадени данни за достъп до базата данни

Най-честата причина за тази грешка се дължи на грешно подадени данни за достъп до базата данни. Можем да проверим с коя база данни е обвързана нашата инсталация, като отворим файла wp-config.php и проверим следните директиви:

// ** Database settings - You can get this info from your web host ** //

/** The name of the database for WordPress */

define( 'DB_NAME', 'database_name_here' );

/** Database username */

define( 'DB_USER', 'username_here' );

/** Database password */

define( 'DB_PASSWORD', 'password_here' );

/** Database hostname */

define( 'DB_HOST', 'localhost' );

/** Database charset to use in creating database tables. */

define( 'DB_CHARSET', 'utf8' );

/** The database collate type. Don't change this if in doubt. */

define( 'DB_COLLATE', '' );

Чрез тези директиви се описват името на базата данни, потребителя за нея, който има пълни права, както и паролата му.

Те трябва да съвпадат напълно с информацията за базата данни в cPanel, полето MyDataBases. След като сме проверили тази опция, можем да създадем един допълнителен файл в инсталацията, например с името dbtest.php. Той трябва да съдържа следния код:

<?php

$test = mysqli_connect('localhost', 'db_user', 'db_password');

if (!$test) { die('MySQL Error: ' . mysqli_error()); }

echo 'Database connection is working properly!';

mysqli_close($testConnection);

Изпълнението на този файл става чрез https://yourdomain.com/dbtest.php. Ако след изпълнението се върне грешка от вида:

MySQL Error: Access denied for user 'db_user'@'localhost'(using pasword: YES)

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

2.2.2.2. Липса на пълни права върху базата данни

Втора причина за грешката е ако потребителят няма пълни права върху базата данни, като пак от cPanel - полето MyDataBases можем да проверим какви права има потребителя и дали е обвързан коректно с базата данни.

След като се убедим , че всичко е коректно, отново тестваме базата и ако всичко е наред, трябва да получим съобщението:

Database connection is working properly!

Не забравяйте след тестовете да премахнете файла dbtest.php от инсталацията.

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

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

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

“One or more database tables are unavailable. The database may need to be repaired“

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

Има няколко метода за това, като ще опишем накратко няколко лесни стъпки за проверка и поправка.

Поправка на базата данни с директива в wp-config.php

WordPress разполага с режим за поправка на базата данни , като за да се активира е необходимо да се добави следната директива в wp-config.php:

define('WP_ALLOW_REPAIR', true);

Директивата се добавя след последният ред във файла и се извиква с директен линк от следният адрес:

https://yourdomain.com/wp-admin/maint/repair.php

От полето, което ще Ви се отвори, ще имате опции да поправите базата данни или да я поправите и едновременно с това да я оптимизирате.

След като премине процеса по поправяне на базата, е необходимо да премахнете добавената директива в wp-config.php , за да спрете режимът на поправка.

Поправка на базата данни в cPanel от полето MyDataBases

Друга възможност за поправка и оптимизация на базата данни предлага cPanel от полето MyDataBases.

Можете да оптимизирате и да поправите базата, като използвате и възможностите на PHPMyAdmin.

Поправка на базата данни с WP-CLI команда

Последният метод, който ще предложим е използването на WP-CLI команда, която има идентично действие с посочените - wp db repair.

В началото на тази статия посочихме, че грешките, свързани с базата данни, могат да се генерират и от корумпирани (хакнати) файлове на ядрото на платформата WordPress.

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

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

Горещо препоръчваме, ако откриете, че казусът не е във Вашето приложение и сте направили всички останали проверки, да се свържете с нашия технически екип.

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

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

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

2.2.3. Критична грешка в темата на WordPress

Много често при обновяването на темата на WordPress е възможно да възникне критична грешка. Тя се генерира във файловете на темата, което стопира работата на приложението. Обикновено тези грешки изглеждат по следният начин в error_log файла:

Fatal Error: Uncaught Error: Call to undefined function tonda_core_is_theme_registered() in /home/cpanelUser/public_html/wp-content/themes/tonda/framework/modules/blog/shortcodes/shortcodes-functions.php:8 

Ако разгледаме внимателно пътя на файла, ще видим, че той се намира в папка /wp-content/themes/tonda/. Това е работната папка на активната тема на приложението, в случая Tonda.

Ето няколко възможности как да разрешим казуса:

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

Когато отворим полето избираме новата тема – например Twenty-Twenty-Four (която е темата по подразбиране през 2024 г.) и я активираме.

Когато обаче нямаме достъп до административното табло в следствие на грешката, най-бързият метод за смяна на темата е да я преименуваме през FileManager на cPanel или от команден ред папката на темата, от посоченият пример /home/cpanelUser/public_html/wp-content/themes/tonda/ може да се преименува на /home/cpanelUser/public_html/wp-content/themes/tonda_stop/

Така при отварянето на сайта, той ще се зареди с темата по подразбиране Twenty-Twenty-Four. Това ще елиминира грешката и ще ни осигури достъп до админ панела. От там можем отново да преинсталираме темата, в нашия пример  – Tonda.

Можем да използваме и метода, който показахме за смяна на файловете на ядрото на WordPress. Ако разполагаме с архив на самата тема, можем от него да копираме файловете в работната папка /home/cpanelUser/public_html/wp-content/themes/tonda/

За тази цел можем да използваме FTP или FileManager на cPanel. Важното при тази операция е да активирате темата, след като приключи копирането на файловете.

2.2.4. Критична грешка в плъгините на WordPress.

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

Грешка, свързана с работата на даден плъгин, би изглеждала по следния начин в error_log файла:

Fatal error: Cannot declare class Less_Version, because the name is already in use in /home/cPanelUser/public_html/wp-content/plugins/ameliabooking/vendor/oyejorge/less.php/lib/Less/Version.php on line 9

Както в описаните методи за разрешаване на грешката в темата, така и за плъгините, трябва да проверим дали в следствие на грешката все още имаме достъп до административния панел на сайта.

Ако разполагаме с такъв, от грешката виждаме, че /wp-content/plugins/ameliabooking/ е плъгинът, който причинява проблемите. Директно от административния панел го деактивираме, изтриваме и инсталираме последната налична версия.

Но ако грешката спира достъпа ни до административния панел на сайта, можем отново да използваме опцията за преименуване на папката от FileManager-a на cPanel, като променяме папката от /home/cPanelUser/public_html/wp-content/plugins/ameliabooking/ на /home/cPanelUser/public_html/wp-content/plugins/ameliabooking_stop/

Това ще ни позволи да стигнем до административния панел на сайта и да преинсталираме дадения плъгин.

Командният интерпретатор на WordPress (WP CLI) също дава възможност да деактивираме дадения плъгин със следната команда:

wp plugin deactivate ameliabooking

Така изпълнената командата ще деактивира само  посочения плъгин.

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

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

Ето и няколко метода за спиране на плъгините:

• Преименуване на папка /wp-content/plugins/ например във /wp-content/plugins_stop/ посредством FileManager на cPanel.
• Използване на команден ред със следната команда: wp plugin deactivate --all
• Деактивиране от административния панел на сайта

2.2.5. Версията на PHP

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

Когато се генерира грешка, първата опция, която можете да тествате, е да промените версията на PHP. Обновеното ядро на WordPress версия 6.5. вече не позволява да използвате по-ниска версия на PHP от 7.4. и когато в инсталацията има плъгин или тема, които вече нямат поддръжка и обновяване, е твърде вероятно те да влязат в конфликт с версията на PHP.

Препоръчваме, когато обновявате версията, да направите update на всички теми и плъгини до последна версия, за да премахнете старите версии, които могат да използват стари дефиниции и функции.

Една от най-често срещаните грешки, е свързана с параметрите на PHP. В лога тя има следния вид:

Fatal error: Allowed memory size of 104857600 bytes exhausted (tried to allocate 495616 bytes) in /home/cPanelUser/public_html/wp-includes/class-wpdb.php on line 1533

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

Първият метод е чрез директива във wp-config.php файла, като се добавя следният ред  в началото или в средата на файла:

define( 'WP_MEMORY_LIMIT', '512M' );

Първата част на функцията показва, че променяме стойността на  WP_MEMORY_LIMIT, а втората част, че заделяме както е показано в примера лимит от 512МБ.

Вторият метод е - да използваме директива във .htaccess файла, като там добавяме следният ред:

php_value memory_limit 256M

Важното е да са включени и допълнителните модули на PHP за съответната версия, като обикновено в самата грешка се изписва кой модул липсва и е необходимо да бъде активиран през cPanel --> PHP Selection полето.

3. Обобщение.

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

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

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

Като всяка отворена система и WordPress има своите недостатъци , но с всяка грешка, която отстраняваме ще видим, че платформата осигурява много гъвкавост и логичност в своето функциониране.

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

Ако се нуждаете от помощ за своя WordPress сайт, разгледайте нашата услуга - WordPress Support! Екип от професионалисти с богат опит ще се грижат за Вашия проект 24/7 с мониторинг и реакция в критични ситуации.