Сайт показывает PHP Fatal Error или перестал открываться после обновления? Разбираем основные виды критических ошибок PHP, учимся читать Stack Trace, находить проблемные файлы и исправлять сбои на WordPress, OpenCart и других CMS.
Сообщение PHP Fatal Error означает, что при выполнении PHP-кода возникла критическая ошибка, после которой текущий скрипт не может нормально продолжить работу. В результате сайт может показать подробное сообщение об ошибке, белую страницу, уведомление о технической неисправности или HTTP 500.
Самая важная часть диагностики - не слова Fatal error, а сообщение после них: Uncaught Error, Failed opening required, Class not found, Allowed memory size exhausted, Maximum execution time exceeded, PDOException или другой текст. Именно оно помогает понять, почему выполнение программы остановилось.
В этой инструкции разберём, что означает PHP Fatal Error, как правильно читать сообщение и stack trace, где искать журналы ошибок на сервере, WordPress и OpenCart, а также как исправить наиболее распространённые фатальные ошибки PHP. Инструкция подойдёт владельцам сайтов, начинающим разработчикам и специалистам, которые занимаются обслуживанием веб-проектов.
PHP - язык программирования, на котором работают WordPress, OpenCart, Joomla, Drupal, MODX, DLE, многие интернет-магазины и самописные сайты. Когда посетитель открывает страницу, сервер запускает PHP-код, который получает необходимые данные, обрабатывает их и формирует ответ браузеру.
Если во время выполнения возникает критическая ошибка, скрипт может завершиться раньше, чем страница будет сформирована. В зависимости от конфигурации сервера посетитель увидит текст ошибки, пустую страницу или сообщение о временной неисправности.
Например:
PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /var/www/site/index.php:25Это сообщение означает, что PHP попытался вызвать функцию example_function(), но не смог её найти. Ошибка произошла в файле index.php на строке 25.
В данном случае причина не в самом PHP как языке программирования. Необходимо выяснить, почему функция недоступна: файл с её объявлением не подключён, необходимое расширение отсутствует, функция была удалена при обновлении или в её названии допущена ошибка.
PHP Fatal Error и HTTP 500 - разные понятия. Fatal Error относится к выполнению PHP-кода, а HTTP 500 означает, что сервер столкнулся с внутренней ошибкой при обработке запроса.
Фатальная ошибка PHP может стать причиной HTTP 500, но фактический статус ответа зависит от настроек сервера и приложения.
Если вывод ошибок отключён, посетитель может увидеть только белую страницу. В таком случае подробности необходимо искать в журнале PHP. О диагностике этой ситуации можно подробнее прочитать в статье «Сайт показывает белую страницу: что проверить».
Не каждое сообщение PHP приводит к остановке сайта. Например, предупреждение Warning обычно позволяет программе продолжить выполнение, хотя определённая функция может не сработать.
Критические ошибки могут полностью остановить выполнение текущего скрипта.
В современных версиях PHP многие ошибки представлены объектами классов Error и Exception. Оба класса реализуют интерфейс Throwable. Если такой объект не был обработан, выполнение скрипта завершается, а в журнале может появиться сообщение PHP Fatal error.
Поэтому важно читать полный текст сообщения, а не ориентироваться только на его первую часть.
Если сайт показывает PHP Fatal Error, не начинайте с переустановки CMS, удаления файлов или изменения настроек PHP наугад. Сначала определите, где и почему возникает неисправность.
Скопируйте сообщение целиком или сделайте скриншот. Особое внимание уделите типу ошибки, названию функции или класса, пути к файлу и номеру строки.
Если сообщение слишком длинное, сохраните его в текстовом файле. Не публикуйте полный журнал в открытом доступе: он может содержать внутренние пути сервера, SQL-запросы и другие технические сведения.
Вспомните, что изменилось непосредственно перед возникновением неисправности. Например, обновлялась ли CMS, устанавливался ли новый плагин, изменялась ли версия PHP, выполнялся ли перенос сайта или редактировался ли собственный программный код.
Последнее изменение не обязательно является причиной ошибки, однако его проверка позволяет быстрее сузить круг возможных проблем.
Попробуйте открыть главную страницу, внутренние разделы и административную панель. Если сайт является интернет-магазином, проверьте карточку товара и корзину.
Если ошибка появляется только на одной странице, вероятно, она связана с кодом, который выполняется при её загрузке. Если сайт полностью недоступен, проверьте общие файлы загрузки CMS, конфигурацию PHP и системные компоненты.
Перед изменением файлов, отключением модулей или редактированием базы данных сохраните резервную копию сайта. Желательно скопировать и текущее неисправное состояние: оно может понадобиться для дальнейшей диагностики.
Если сообщение в браузере отсутствует или содержит недостаточно информации, найдите соответствующую запись в журнале PHP. Он обычно содержит полный текст ошибки, путь к файлу, номер строки и stack trace.
Stack trace, или трассировка стека, показывает последовательность вызовов функций и методов, которая привела программу к месту возникновения ошибки.
Рассмотрим пример:
PHP Fatal error: Uncaught Error: Call to undefined method OrderService::send() in /var/www/site/app/Controller/Checkout.php:87
Stack trace:
#0 /var/www/site/public/index.php(24): CheckoutController->confirm()
#1 {main}
thrown in /var/www/site/app/Controller/Checkout.php on line 87В начале сообщения указано:
Uncaught Error: Call to undefined method OrderService::send()Это означает, что PHP попытался вызвать метод send() класса OrderService, но не обнаружил его в используемом объекте.
Следующая часть сообщения:
/var/www/site/app/Controller/Checkout.php:87Она указывает, что ошибка возникла в файле Checkout.php на строке 87.
Откройте этот файл и изучите не только указанную строку, но и несколько строк до и после неё. Проверьте, какой объект используется, каким способом он создаётся и откуда загружается его класс.
Записи с обозначениями #0, #1 и далее показывают, как программа дошла до проблемного участка.
В приведённом примере метод confirm() был вызван из основного файла приложения. Внутри него возникла ошибка при обращении к методу send().
Чем сложнее сайт, тем длиннее может быть stack trace. Например, он может содержать десятки вызовов из ядра CMS, плагинов, шаблона и сторонних библиотек.
Файл, указанный в сообщении, не всегда является источником проблемы. Например, ошибка может возникнуть в ядре WordPress, потому что сторонний плагин передал туда неправильные данные.
В таком случае исправление системного файла не устранит первопричину. Необходимо изучить цепочку вызовов и найти компонент, который вызвал проблемный метод или функцию.
При диагностике последовательно проверяйте текст ошибки, файл и строку, первые записи stack trace, пользовательский код в цепочке вызовов и последние изменения соответствующего компонента.
На рабочем сайте подробные сообщения PHP обычно не показывают посетителям. Поэтому основной инструмент диагностики - журнал ошибок, или error log.
В панели управления хостингом найдите раздел «Логи», «Журналы», «Журнал ошибок», «PHP errors» или «Error log». Его название зависит от хостинг-провайдера.
Если журнал отображает много записей, ищите сообщения PHP Fatal error, Uncaught Error, Uncaught Exception и другие ошибки, соответствующие неисправности.
Путь к журналу PHP может задаваться параметром error_log в конфигурации PHP. Единого расположения для всех серверов не существует.
На одном хостинге журнал может находиться в отдельном каталоге домена, на другом - в системном каталоге логов, а на собственном сервере сообщения могут передаваться в журнал PHP-FPM или веб-сервера.
Для проверки активного значения параметра можно использовать:
echo ini_get('error_log');Если значение пустое, это не означает, что журналирование отсутствует. Ошибки могут передаваться обработчику логирования веб-сервера, PHP-FPM или системной службе журналирования.
Если у вас есть доступ к конфигурации PHP, для рабочего сайта обычно используют следующие настройки:
log_errors = On
display_errors = Off
error_reporting = E_ALLЕсли необходимо указать отдельный файл журнала:
error_log = /path/to/php-error.logЗамените пример пути на существующий защищённый каталог, доступный PHP для записи.
Для отдельных сценариев диагностики можно включить журналирование из кода:
error_reporting(E_ALL);
ini_set('log_errors', '1');
ini_set('display_errors', '0');Однако эти команды выполняются только после начала работы самого PHP-файла. Если ошибка возникает раньше их выполнения, например из-за неправильного синтаксиса в том же файле, настройки необходимо задавать на уровне конфигурации PHP или сервера.
На собственном сервере дополнительно проверьте журналы Nginx, Apache и PHP-FPM.
В зависимости от операционной системы и конфигурации могут использоваться следующие пути:
/var/log/nginx/error.log
/var/log/apache2/error.log
/var/log/php8.x-fpm.logЭто только примеры. Фактический путь может отличаться, а для каждого сайта или пула PHP-FPM может использоваться отдельный журнал.
Если основной журнал PHP пустой, проверьте журналы конкретного виртуального хоста, PHP-FPM и системную службу журналирования.
Сообщение PHP Fatal Error: Uncaught Error означает, что при выполнении кода возник объект класса Error или его наследника, который не был обработан до завершения текущего стека вызовов.
Например:
PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /var/www/site/index.php:15В данном случае проблема связана с вызовом несуществующей или недоступной функции.
Другой пример:
PHP Fatal error: Uncaught Error: Class "App\Service\Mailer" not found in /var/www/site/send.php:20Здесь PHP не смог найти класс Mailer.
Само выражение Uncaught Error не определяет способ исправления. Необходимо читать текст после двоеточия и проверять соответствующий файл.
В современных версиях PHP объекты Error и Exception реализуют общий интерфейс Throwable. Это позволяет перехватывать их с помощью конструкции try/catch.
Пример:
try {
$result = $service->send();
} catch (Throwable $e) {
error_log($e->getMessage());
// Обработка ошибки приложения
}Но добавление try/catch не устраняет саму неисправность. Если функция отсутствует, файл не найден или приложение обращается к несуществующему классу, необходимо исправить соответствующий код или конфигурацию.
Перехват исключения полезен, когда приложение действительно способно восстановить выполнение либо корректно зарегистрировать ошибку и вернуть пользователю контролируемый ответ.
Не следует оборачивать весь сайт в обработчик, который просто подавляет любые ошибки и продолжает работу с некорректными данными.
Ошибка PHP Fatal Error: Failed opening required возникает, когда PHP не может подключить обязательный файл.
Например:
PHP Fatal error: Uncaught Error: Failed opening required '/var/www/site/config.php'Это означает, что PHP попытался загрузить файл config.php, но операция завершилась неудачно.
Откройте файловый менеджер хостинга или подключитесь к серверу по SFTP. Перейдите по пути, указанному в сообщении, и проверьте существование файла.
Он мог быть удалён при обновлении, не попасть в архив, не загрузиться при переносе или отсутствовать после неполной установки модуля.
Если файл действительно отсутствует, восстановите его из резервной копии или проверенного установочного пакета соответствующей версии приложения.
Не создавайте пустой файл только ради исчезновения сообщения. Если приложение ожидает внутри него функции, классы или настройки, следующая ошибка возникнет сразу после подключения.
Рассмотрим пример:
require 'config.php';Такое подключение может зависеть от текущего рабочего каталога и настроек include_path.
Если файл находится в том же каталоге, что и выполняемый PHP-файл, часто надёжнее явно указать путь относительно текущего файла:
require __DIR__ . '/config.php';Если файл находится уровнем выше:
require dirname(__DIR__) . '/config.php';Перед изменением убедитесь, что файл действительно расположен по указанному пути.
Например, на старом сервере сайт находился по адресу:
/home/olduser/public_html/После переноса он оказался в другом каталоге, но старый абсолютный путь сохранился в конфигурации.
В таком случае проверьте настройки путей CMS, собственные PHP-файлы и конфигурацию подключаемых библиотек.
Не заменяйте пути массово без понимания их назначения. В некоторых CMS системные каталоги располагаются за пределами публичной директории.
PHP-процесс должен иметь возможность читать подключаемый файл и проходить по родительским каталогам.
Если журнал указывает на проблему доступа, проверьте владельца файла и права на него и соответствующие каталоги.
Не устанавливайте права 777 на весь сайт. Это не является безопасным универсальным решением.
На некоторых хостингах PHP запрещено обращаться к файлам за пределами определённых каталогов.
Если путь находится за пределами разрешённой области, в журнале может появиться дополнительное сообщение об ограничении open_basedir.
Проверьте настройки PHP и правильность расположения подключаемого файла. Если изменение разрешённых каталогов недоступно в панели хостинга, обратитесь к провайдеру.
Оба оператора используются для обязательного подключения PHP-файла. require_once дополнительно проверяет, не был ли этот файл уже подключён в текущем запросе, и не выполняет его повторное подключение.
Однако require_once не исправляет неправильный путь, отсутствие файла или ограничения доступа.
Сообщение PHP Fatal Error: Class not found означает, что PHP не смог найти класс, к которому обращается программа.
Например:
PHP Fatal error: Uncaught Error: Class "App\Service\Mailer" not foundЧаще всего ошибка возникает из-за неправильного имени класса, отсутствующего файла, проблем с автозагрузкой или несовместимых версий библиотек.
Найдите файл, в котором должен быть объявлен указанный класс. Убедитесь, что файл существует и содержит нужное объявление.
Если класс относится к стороннему модулю, проверьте, полностью ли установлен соответствующий пакет.
Например, класс может быть объявлен следующим образом:
namespace App\Service;
class Mailer
{
// ...
}При обращении к нему необходимо учитывать пространство имён. Если вызывающий код расположен в другом namespace, может потребоваться импорт класса:
use App\Service\Mailer;Либо использование полного имени класса.
Если проект использует Composer, обычно файл автозагрузки подключается следующим образом:
require __DIR__ . '/vendor/autoload.php';Проверьте, существует ли каталог vendor и установлен ли пакет, содержащий нужный класс.
После переноса сайта каталог зависимостей иногда отсутствует, потому что не был включён в архив или должен устанавливаться отдельно при развёртывании проекта.
Если проект содержит composer.json и composer.lock, восстановите зависимости с учётом зафиксированных версий.
Обычно для этого используют:
composer installЕсли зависимости уже установлены, но изменились правила автозагрузки, может потребоваться:
composer dump-autoloadНе выполняйте composer update на рабочем сервере наугад. Эта команда может изменить версии пакетов и добавить новые проблемы совместимости.
На Linux имена файлов обычно чувствительны к регистру. Поэтому Mailer.php и mailer.php могут восприниматься как разные файлы.
Если код работал на локальном компьютере с Windows, но перестал работать после переноса на Linux-сервер, проверьте соответствие имени файла, названия класса и правил автозагрузки.
Сообщение:
PHP Fatal error: Uncaught Error: Call to undefined function mb_strlen()означает, что PHP не смог найти указанную функцию.
Причины могут быть следующими:
Например, недоступность функции mb_strlen() может указывать на отсутствие расширения mbstring, а ошибка вызова curl_init() - на недоступность cURL.
Проверьте, включены ли необходимые расширения для той версии PHP, на которой работает сайт.
Если у вас есть доступ к командной строке, список подключённых модулей можно посмотреть командой:
php -mНо учтите, что PHP в командной строке и PHP, обрабатывающий запросы сайта, могут использовать разные версии и конфигурационные файлы. Поэтому отсутствие ошибки при запуске из CLI не доказывает, что веб-сайт использует такое же окружение.
Если ошибка указывает на пользовательскую функцию, найдите файл, в котором она объявлена. Проверьте, подключается ли он до момента вызова.
После обновления библиотеки убедитесь, что функция не была переименована или удалена.
Если сообщение выглядит следующим образом:
Call to undefined method ProductModel::getNewPrice()это означает, что PHP нашёл класс, но не обнаружил вызываемый метод.
Проверьте название метода, используемую версию класса, наследование, подключённые библиотеки и совместимость вызывающего кода с установленной версией модуля.
Ошибка Cannot redeclare возникает, когда программа пытается повторно объявить функцию или другой идентификатор, который уже существует.
Например:
PHP Fatal error: Cannot redeclare calculatePrice()Такое сообщение может появиться после подключения одного файла несколько раз или установки двух расширений с конфликтующими функциями.
Если причина действительно заключается в повторном подключении одного и того же файла, использование require_once может устранить проблему:
require_once __DIR__ . '/functions.php';Но если два разных файла содержат одинаковые объявления функций, такая замена не поможет. Необходимо устранить конфликт между компонентами.
Не добавляйте проверки function_exists() и class_exists() только ради подавления ошибки, если приложение не предполагает условное объявление соответствующих функций или классов.
Ошибка Allowed memory size exhausted означает, что PHP-скрипт достиг установленного ограничения на использование памяти.
Например:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes)В приведённом примере установленный лимит составляет 128 МБ. PHP попытался выделить дополнительную память, но доступный лимит уже был исчерпан.
Основные причины:
В PHP текущее значение можно получить так:
echo ini_get('memory_limit');Если сайт работает на виртуальном хостинге, проверьте настройки PHP для конкретного домена в панели управления.
Откройте файл и строку, указанные в сообщении об ошибке, и изучите stack trace.
Если ошибка возникает при импорте товаров, проверьте объём загружаемых данных и способ их обработки. Если при создании миниатюр изображений - размер исходных файлов и используемую библиотеку.
Обратите внимание, что строка, на которой PHP исчерпал память, не обязательно содержит первопричину. Например, память могла постепенно заполняться в цикле, а окончательное превышение лимита произошло при выделении очередного небольшого массива.
Если приложение обрабатывает большой объём данных, постарайтесь исключить их одновременную загрузку в память.
Например, большой CSV-файл можно читать построчно, выборку из базы данных - обрабатывать пакетами, а изображения - предварительно уменьшать до необходимого разрешения.
При обработке массивов проверьте, не сохраняются ли повторно одни и те же данные и не создаются ли лишние копии больших структур.
Если операция действительно требует больше памяти, а сервер располагает необходимыми ресурсами, лимит можно увеличить.
Пример настройки PHP:
memory_limit = 256MВ некоторых конфигурациях параметр можно изменить непосредственно из кода:
ini_set('memory_limit', '256M');Но это не универсальное исправление. Если скрипт бесконтрольно потребляет память, повышение лимита лишь отсрочит следующую ошибку и может увеличить нагрузку на сервер.
Также хостинг или конфигурация PHP могут ограничивать возможность изменения лимитов приложением.
Ошибка Maximum execution time exceeded означает, что выполнение PHP-скрипта превысило установленное ограничение времени.
Например:
PHP Fatal error: Maximum execution time of 30 seconds exceededВ данном примере PHP завершил выполнение скрипта после достижения установленного ограничения.
Изучите путь к файлу, строку и stack trace. Проверьте, какой код выполнялся перед достижением ограничения.
Если скрипт обрабатывает десятки тысяч товаров, попробуйте определить, сколько времени занимает обработка одной партии данных.
Если ошибка возникает при обращении к внешнему сервису, проверьте тайм-ауты подключения и получения ответа.
Если выполнение останавливается при работе с базой, проверьте используемый SQL-запрос, наличие необходимых индексов и размер выборки.
Не всегда нужно увеличивать время выполнения PHP. Иногда оптимизация одного запроса позволяет сократить работу скрипта с десятков секунд до значительно меньшего времени.
Если необходимо импортировать большой каталог товаров, сформировать отчёт или обработать множество изображений, разумнее разбить операцию на небольшие партии.
Для длительных операций можно использовать очередь задач или cron, чтобы не заставлять посетителя ждать завершения всей обработки в рамках одного HTTP-запроса.
Если задача действительно должна выполняться дольше, ограничение можно изменить в конфигурации:
max_execution_time = 120Или непосредственно в PHP-коде, если серверная конфигурация позволяет:
set_time_limit(120);Однако не устанавливайте неограниченное время выполнения только ради исчезновения ошибки. Это может привести к зависшим процессам и дополнительной нагрузке на сервер.
Сообщение PHP Fatal Error: Uncaught Exception означает, что приложение выбросило исключение, которое не было обработано.
Например:
PHP Fatal error: Uncaught RuntimeException: Unable to save file ...В данном случае приложение сообщает, что не смогло сохранить файл.
Причиной могут быть неправильный путь, недостаточные права доступа, заполненный диск или другая неисправность файловой системы.
Добавление обработчика catch не устранит отсутствие доступа к каталогу. Сначала необходимо разобраться с конкретной причиной исключения.
Пример:
try {
$result = $service->send();
} catch (RuntimeException $e) {
error_log($e->getMessage());
// Вернуть контролируемый ответ приложения
}Обработчик должен выполнять осмысленное действие: регистрировать проблему, восстанавливать корректное состояние приложения или сообщать пользователю о невозможности выполнить операцию.
Если исключение не может быть корректно обработано на текущем уровне, иногда правильнее передать его глобальному обработчику приложения.
Если сайт использует PDO для работы с базой данных, в журнале может появиться сообщение:
PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000] ...Это означает, что при выполнении операции с базой данных возникло исключение, которое не было обработано.
Ключевая часть сообщения - код SQLSTATE и следующий за ним текст. Именно они позволяют определить характер неисправности.
Если сообщение указывает на невозможность подключения, проверьте адрес сервера базы данных, имя пользователя, пароль, порт и доступность MySQL или MariaDB.
После переноса сайта убедитесь, что конфигурация указывает на новую базу данных, а не на старый сервер.
Это сообщение обычно указывает на проблему с учётными данными или правами пользователя базы данных.
Проверьте, существует ли нужный пользователь и имеет ли он необходимые разрешения для работы с соответствующей базой.
Если приложение не может найти таблицу, проверьте её существование и правильность имени.
На сайтах с CMS обратите внимание на префиксы таблиц. Например, после переноса базы данных в конфигурации может остаться старый префикс.
Если сообщение содержит ошибку синтаксиса SQL или несовместимость типов данных, изучите запрос, который выполнялся в момент возникновения неисправности.
Проблема может появиться после обновления CMS, изменения структуры таблиц или перехода на другую версию MySQL или MariaDB.
Важно: не публикуйте полные сообщения PDOException на рабочем сайте. Они могут содержать SQL-запросы, внутренние пути и другие технические сведения.
Также не запускайте повторно запросы на изменение данных, не убедившись, что операция безопасна. Некоторые запросы могут создавать дублирующиеся записи или приводить к повторной обработке заказов.
После обновления PHP или сторонней библиотеки могут появляться ошибки, связанные с типами данных и количеством аргументов.
Например:
PHP Fatal error: Uncaught TypeError: ...Или:
PHP Fatal error: Uncaught ArgumentCountError: ...Ошибка TypeError может возникнуть, когда функция получает значение неподходящего типа или возвращает значение, которое не соответствует объявленному типу результата.
Например, код ожидает строку, но получает массив или объект.
Проверьте текст ошибки: обычно он указывает имя функции, ожидаемый тип и фактически переданное значение.
Эта ошибка связана с неправильным количеством аргументов при вызове функции или метода.
Например, после обновления библиотеки метод может требовать дополнительный обязательный аргумент, а старый код продолжает вызывать его прежним способом.
Не рекомендуется произвольно отключать проверку типов или заменять все значения на строки ради устранения ошибки. Необходимо понять, какие данные должна получать функция и почему ей передаётся неправильное значение.
На WordPress фатальная ошибка PHP часто появляется после обновления плагина, темы оформления, ядра CMS или изменения версии PHP.
В современных версиях WordPress предусмотрен механизм обработки некоторых критических ошибок. Вместо подробного сообщения посетитель может увидеть уведомление о технической неисправности, а администратор - получить письмо с информацией о проблемном компоненте и ссылкой для режима восстановления.
Попробуйте открыть:
https://example.com/wp-admin/Замените example.com на адрес своего сайта.
Если административная панель недоступна, проверьте почту администратора WordPress, включая папку «Спам».
Если пришло письмо о критической ошибке, изучите указанный в нём компонент и воспользуйтесь режимом восстановления, если он доступен.
Отсутствие письма не исключает фатальную ошибку: отправка почты с сервера тоже может не работать.
Откройте файловый менеджер хостинга или подключитесь к серверу через SFTP.
Найдите файл wp-config.php и создайте его резервную копию.
Проверьте существующие параметры отладки и настройте их следующим образом:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Если WP_DEBUG уже определён в файле, измените существующее значение, а не добавляйте вторую строку с тем же параметром.
Размещайте определения до подключения wp-settings.php, в разделе настроек WordPress.
После сохранения конфигурации снова откройте страницу, на которой возникает ошибка.
При стандартном значении WP_DEBUG_LOG WordPress записывает сообщения в файл:
wp-content/debug.logНайдите записи, время которых совпадает с возникновением неисправности.
Например:
PHP Fatal error: Uncaught Error: Call to undefined function example() in /var/www/site/wp-content/plugins/my-plugin/includes/class-example.php:73В данном случае ошибка проявилась внутри плагина my-plugin. Проверьте его версию, совместимость с PHP и WordPress, а также последние изменения.
Если файл debug.log не появился, проверьте права на запись и общий PHP error log. Сбой может происходить до запуска механизма отладки WordPress.
Если журнал достаточно определённо указывает на конкретное расширение, временно отключите его через административную панель WordPress.
Если административная панель недоступна, подключитесь к серверу через SFTP и откройте каталог:
wp-content/plugins/Найдите папку предполагаемого проблемного плагина и временно переименуйте её:
my-plugin
↓
my-plugin-disabledПосле этого повторно откройте сайт.
Если ошибка исчезла, проверьте совместимость расширения, наличие обновлений и изменения в его коде. Не ограничивайтесь постоянным отключением плагина, если он обеспечивает важные функции сайта.
На работающем интернет-магазине массовое отключение плагинов без предварительной проверки может нарушить корзину, оплату и оформление заказов.
Если журнал указывает на файл активной темы, проверьте functions.php, шаблоны страниц, подключаемые классы и собственные доработки.
При наличии тестовой копии можно временно переключиться на совместимую стандартную тему WordPress и проверить, исчезает ли ошибка.
На рабочем сайте не следует бездумно менять тему, особенно если она содержит собственные шаблоны WooCommerce и важные настройки оформления.
Если проблема появилась после перехода на новую версию PHP, проверьте требования WordPress, активной темы и установленных плагинов.
Не следует автоматически возвращать старую версию PHP только потому, что на ней сайт работал раньше. Сначала определите несовместимый компонент и проверьте возможность его обновления.
Когда сайт снова работает, верните рабочую конфигурацию отладки, если постоянное журналирование WordPress не предусмотрено настройками проекта.
Проверьте, что debug.log не доступен посторонним пользователям по прямому URL. При необходимости сохраните нужные диагностические записи в защищённом месте и удалите временный журнал из публичной директории.
На OpenCart фатальные ошибки PHP часто связаны с модулями, модификаторами OCMOD, шаблонами, изменением версии PHP, отсутствующими файлами и неправильными системными путями.
Особенности диагностики зависят от версии OpenCart. Структура каталогов и система расширений OpenCart 1.5, 2.x, 3.x и 4.x различаются, поэтому не следует использовать одни и те же инструкции по изменению системных файлов для всех версий.
Попробуйте открыть главную страницу, категорию, карточку товара, корзину, оформление заказа и административную панель.
Если ошибка появляется только на карточках товаров, проверьте связанные с ними контроллеры, модели, шаблоны и модули.
Если не работает только административная панель, начните с компонентов административной части.
Если PHP Fatal Error появляется на всех страницах, проверьте общие файлы загрузки движка, конфигурацию и серверное окружение.
Если административная панель доступна, откройте раздел просмотра журнала ошибок. Его расположение зависит от версии OpenCart и локализации.
Если панель не открывается, подключитесь к серверу через SFTP или файловый менеджер хостинга.
В OpenCart 1.5 стандартный журнал часто находится по пути:
system/logs/error.txtВ более новых установках OpenCart журнал может находиться в каталоге:
system/storage/logs/Однако системный каталог storage может быть вынесен за пределы публичной директории сайта. Поэтому фактический путь необходимо определять по конфигурации конкретной установки, в том числе по значению DIR_STORAGE, если оно используется данной версией движка.
Если журнал OpenCart пустой, проверьте общий PHP error log. Критическая ошибка может возникнуть ещё до того, как движок успеет запустить собственный механизм журналирования.
Если stack trace указывает на конкретное расширение, проверьте его совместимость с установленной версией OpenCart и PHP.
Убедитесь, что все файлы модуля загружены корректно и после обновления не остались компоненты старой версии.
Если расширение использует OCMOD, проверьте, не конфликтуют ли его модификации с другими установленными дополнениями.
Если ошибка появилась после установки или обновления расширения, проверьте связанные с ним модификаторы. При доступной административной панели используйте предусмотренный вашей версией OpenCart механизм обновления модификаторов и очистки кеша.
Не удаляйте наугад содержимое каталогов system, storage или других системных директорий. На разных версиях OpenCart они могут содержать необходимые рабочие файлы.
Если сообщение содержит Failed opening required или указывает на отсутствующие файлы, проверьте системные пути в конфигурации движка.
После переноса сайта на новый хостинг старые абсолютные пути могут перестать соответствовать фактическому расположению файлов.
Сверьте значения с текущей структурой каталогов и исправьте только неправильные параметры.
Если журнал указывает на ошибку подключения или выполнения SQL-запроса, проверьте доступность MySQL или MariaDB, параметры соединения, существование нужных таблиц и их префиксы.
Если ошибка возникла после обновления OpenCart, убедитесь, что необходимые изменения структуры базы данных были выполнены корректно.
Перед изменением таблиц создайте резервную копию базы данных.
Общий порядок диагностики фатальных ошибок PHP одинаков для большинства CMS: необходимо получить полный текст сообщения, найти соответствующую запись в журнале, изучить stack trace и определить неисправный компонент.
Проверьте совместимость установленных расширений и шаблона с текущей версией Joomla и PHP. Изучите журнал ошибок, конфигурацию сайта и компоненты, которые выполняются при загрузке проблемной страницы.
Помимо PHP error log проверьте журналы Drupal и состояние установленных модулей. Если ошибка возникла после обновления, изучите совместимость зависимостей, собственных модулей и темы оформления.
Проверьте журнал ошибок MODX, работу плагинов, сниппетов, шаблонов и подключаемых PHP-файлов. Если проблема возникла после переноса, проверьте системные пути и конфигурацию.
Проверьте совместимость шаблона и сторонних модулей с установленной версией DLE и PHP. Если ошибка возникла после обновления, убедитесь, что файлы движка заменены полностью и не остались несовместимые изменения.
На самописном сайте начните с журнала PHP, точки входа приложения и stack trace. Проверьте подключение Composer-зависимостей, конфигурацию, обработку исключений и используемые классы.
Если проект построен на PHP-фреймворке, изучите также его собственные журналы и механизм обработки ошибок.
Не переносите инструкции по отключению модулей и изменению системных файлов из одной CMS в другую. У разных движков свои механизмы загрузки компонентов.
Если сайт работал нормально, но сразу после обновления появился PHP Fatal Error, необходимо проверить совместимость программного кода и полноту установки обновления.
Сам факт появления ошибки после обновления не доказывает, что неисправно само обновление. Новая версия может проявить ранее существовавшую несовместимость или ошибку в стороннем компоненте.
Проверьте использование устаревших или удалённых функций, несовместимых расширений PHP и изменений в обработке типов данных.
Сравните установленную версию PHP с требованиями CMS, темы, модулей и Composer-зависимостей.
Проверьте, завершилось ли обновление полностью. Убедитесь, что все необходимые файлы заменены и выполнены предусмотренные разработчиком обновления базы данных.
Если Fatal Error указывает на сторонний плагин или модуль, проверьте его совместимость с новой версией движка.
Проверьте, не остались ли файлы старой версии. При неполном обновлении один файл может обращаться к функции или классу из новой версии, а соответствующий компонент ещё отсутствует на сервере.
Если доступна резервная копия, сравните файлы до и после обновления.
Проверьте абсолютные пути, права доступа, расширения PHP, Composer-зависимости, параметры подключения к базе данных и расположение системных каталогов.
Если сайт переносился между Windows и Linux, дополнительно проверьте регистр имён файлов и каталогов.
При обслуживании действующего сайта необходимо не только исправить ошибку, но и не раскрыть посетителям конфиденциальные технические сведения.
На рабочем сервере обычно рекомендуется записывать подробные сообщения в защищённый журнал, отключив их публичный вывод:
display_errors = Off
log_errors = On
error_reporting = E_ALLЭти настройки позволяют получать диагностическую информацию, не показывая её посетителям непосредственно на странице.
Сообщение PHP Fatal Error может содержать полные пути файлов, названия классов, внутреннюю структуру проекта, SQL-запросы и другую служебную информацию.
Например:
PHP Fatal error: Uncaught PDOException ... in /home/account/domains/example.com/private/config/database.php on line 42Даже если сообщение не содержит пароля, оно раскрывает часть внутренней структуры сайта.
Для подробной диагностики используйте тестовую копию с ограниченным доступом или защищённые серверные журналы.
Если ошибки не записываются в журнал, проверьте, есть ли свободное место на сервере и разрешена ли запись в каталог логов.
Полностью заполненный диск может вызывать дополнительные неисправности: PHP перестаёт создавать временные файлы, сохранять сессии и записывать диагностическую информацию.
Если PHP не может записать файл журнала, проверьте владельца и необходимые права доступа. Сам журнал желательно хранить за пределами публичной директории сайта либо защищать от прямого скачивания через браузер.
При длительной работе журналы могут занимать значительный объём диска. На собственном сервере настройте ротацию, а на виртуальном хостинге уточните правила хранения у провайдера.
Отключение вывода сообщений полезно для безопасности рабочего сайта, но оно не устраняет причину Fatal Error. Необходимо сохранить журналирование и исправить проблемный код.
Подавление сообщений оператором @ не исправляет неправильные пути, отсутствующие классы и другие неисправности. Оно может лишь затруднить диагностику.
Если файл недоступен для чтения, определите необходимые права и правильного владельца. Массовая установка прав 777 может создать серьёзные проблемы безопасности.
Если скрипт бесконтрольно накапливает данные, увеличение лимита памяти лишь позволит ему занять больше ресурсов перед следующей ошибкой.
Установка неограниченного времени выполнения может привести к зависшим PHP-процессам и дополнительной нагрузке. Сначала выясните, почему операция выполняется слишком долго.
Команда composer update может изменить множество пакетов сразу. Если проблема связана с одним отсутствующим классом, сначала проверьте конкретную зависимость и правила автозагрузки.
Если ошибка появляется в системном файле WordPress или OpenCart, это ещё не означает, что именно он содержит первопричину. Изучите stack trace и проверьте сторонние модули, которые вызывают соответствующий код.
Сохраните необходимые диагностические записи в защищённом месте и повторно проверьте работу сайта. Некоторые ошибки возникают только при определённом действии, например при оформлении заказа или запуске автоматической задачи.
Это сообщение о критической ошибке, после которой выполнение текущего PHP-скрипта завершилось. Для определения причины необходимо прочитать полный текст сообщения, включая тип ошибки, файл, номер строки и stack trace.
Это означает, что возник объект ошибки, который не был обработан до завершения стека вызовов. Конкретная причина указывается дальше: например, Class not found или Call to undefined function.
Stack trace - это последовательность вызовов функций и методов, которая привела к возникновению ошибки. Она помогает определить, какой компонент приложения вызвал проблемный участок кода.
PHP не смог загрузить обязательный файл через require или require_once. Проверьте существование файла, путь к нему, права доступа и ограничения конфигурации PHP.
Оба оператора используются для обязательного подключения PHP-файла. require_once дополнительно проверяет, не был ли этот файл уже подключён в текущем запросе, и не выполняет повторное подключение.
Проверьте название класса, namespace, существование файла, настройки автозагрузки и Composer-зависимости. После переноса сайта дополнительно убедитесь, что все файлы и библиотеки присутствуют на новом сервере.
PHP обнаружил повторное объявление функции или другого идентификатора. Причиной может быть двойное подключение файла, конфликт расширений или наличие нескольких версий одного компонента.
Определите операцию, которая потребляет слишком много памяти. Проверьте циклы, массивы, обработку файлов и запросы к базе данных. Увеличивайте memory_limit только после оценки фактических потребностей приложения и ресурсов сервера.
Найдите операцию, выполнение которой превышает установленное время. Проверьте циклы, SQL-запросы, обращения к внешним сервисам и объём обрабатываемых данных. При необходимости оптимизируйте код или разделите задачу на части.
При работе с базой данных через PDO возникло исключение, которое не было обработано. Код SQLSTATE и текст сообщения помогают определить причину: проблему подключения, недостаточные права, отсутствующую таблицу или ошибку SQL-запроса.
Старый код может использовать удалённые функции, несовместимые библиотеки или поведение, изменившееся в новой версии PHP. Проверьте требования CMS, темы, модулей и Composer-зависимостей.
Единого пути нет. Расположение журнала зависит от конфигурации PHP, веб-сервера и хостинга. На WordPress дополнительно можно включить debug.log, а на OpenCart - проверить собственный журнал движка.
Да, если у вас есть доступ к файловому менеджеру хостинга, SFTP, базе данных или серверным журналам. Например, на WordPress можно проверить wp-config.php, включить журналирование и временно отключить конкретный проблемный плагин переименованием его каталога.
Нет. Fatal Error относится к выполнению PHP-кода, а 500 - HTTP-статус ответа сервера. Фатальная ошибка может привести к HTTP 500, но эти понятия не являются синонимами.
Если вывод ошибок отключён, а приложение не формирует собственную страницу ошибки, выполнение PHP может завершиться без видимого сообщения. В таком случае подробности необходимо искать в журнале PHP.
Обычно нет. Если причина заключается в несовместимом плагине, неправильной конфигурации PHP, отсутствующем файле или ошибке пользовательского кода, переустановка ядра CMS может не помочь. Сначала определите первопричину по журналу и stack trace.
Если сайт показывает PHP Fatal Error, не пытайтесь исправлять сообщение целиком. Разберите его на части: тип ошибки, основной текст, файл, номер строки и stack trace. Именно эта информация показывает направление диагностики.
Failed opening required требует проверки файла и пути, Class not found - автозагрузки и зависимостей, Allowed memory size exhausted - потребления памяти, Maximum execution time exceeded - длительной операции, а PDOException - конкретной ошибки базы данных.
На WordPress проверяйте журнал debug.log, плагины и тему оформления. На OpenCart - журнал движка, модификаторы, системные пути и совместимость расширений. При собственном сервере дополнительно анализируйте журналы PHP-FPM, Nginx и Apache.
Главный принцип - не скрывать Fatal Error и не увеличивать лимиты наугад, а найти конкретную причину, изучить цепочку вызовов и устранить неисправность.
Не получается найти источник PHP Fatal Error самостоятельно? Я занимаюсь диагностикой и исправлением ошибок PHP на WordPress, OpenCart, Joomla, Drupal, MODX, DLE и самописных проектах. Могу найти проблемный модуль или участок кода, разобраться со stack trace, настройками PHP, зависимостями и сервером, восстановить работу сайта и проверить связанные функции. Подробнее об услуге - на странице исправления ошибок сайтов.
Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.
Переработал страницы онлайн-оплаты туров: убрал устаревшие даты и служебные элементы, сделал кнопку оплаты заметнее и создал единый шаблон для всех направлений.
Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.