Своя система ошибок для сайта

Как кастомизировать стандартные страницы ошибок

В процессе настройки нового веб‑сервера, вы можете захотеть чтобы страницы ошибок отображались в красивом виде, вместо стандартного. Также иногда страницы ошибок должны быть в том же оформлении, что и основной сайт и/или предоставлять пользователям какую‑то дополнительную информацию, такую как, например, контакты, альтернативные способы решения возникшей проблемы или что‑то иное.

Для упрощения процесса, я создал небольшую утилиту (прямая ссылка на проект в GitHub), по сути Node.js скрипт, которая позволяет создавать статические страницы ошибок в собственном дизайне и со своими текстовыми сообщениями. По умолчанию, утилита содержит только один шаблон в минималистичном дизайне (с поддержкой доступности и адаптивности, на сколько это возможно в такой простой странице). Но если вас не устраивает такой дизайн, то вы можете с легкостью изменить его, путем создания собственного: со своими стилями, шрифтами, изображениями и текстами.

Для возможности создания страниц на других языка, утилита позволяет использовать собственные языковые пакеты, включающие свои кастомные текстовые сообщения.

Для упрощения интеграции, утилита автоматически создает сниппет с конфигурацией веб сервера, который легко может быть добавлен в конфигурацию вашего веб сервера. На текущий момент сниппет создается только для Nginx. Другие виды серверов будут добавлены позже (в качестве альтернативы, вы можете создать Pull Request с таким улучшениями, либо оформить Feature Request).

Использование

В базовом сценарии использования, всё что требуется, это лишь склонировать себе на компьютер репозиторий проекта, установить зависимости Node.js, запустить команду сборки, скопировать полученный результат к себе на сервер и обновить конфигурацию сервера.

$ git clone git@github.com:sapachev/error-pages.git
…
$ npm install --production
…
$ npm run build
…
INFO: Start building process
INFO: Flush build directory '/home/error-pages/dist'
INFO: Compile pages from source data:
 • /home/error-pages/dist/400.html
 • /home/error-pages/dist/401.html
 • /home/error-pages/dist/403.html
 • /home/error-pages/dist/404.html
 • /home/error-pages/dist/410.html
 • /home/error-pages/dist/500.html
 • /home/error-pages/dist/502.html
 • /home/error-pages/dist/503.html
 • /home/error-pages/dist/504.html
INFO: Compile web servers config snippets from source data:
 • /home/error-pages/dist/nginx-error-pages.conf
INFO: Build Tailwind CSS styles
INFO: Run 'INPUT="/home/error-pages/themes/minimalistic/@assets/css/main.twnd.css" OUTPUT="/home/error-pages/dist/@assets/css/main.css" npm run build:tailwind' command
INFO: Tailwind CSS styles were built
INFO: Copying assets to '/home/error-pages/dist/@assets' directory
INFO: Building process was completed in 1.727s

Продвинутое использование

В дополнение к шагам базового сценария, вы можете улучшить скомпилированные страницы меняя части, из которых они собираются: шаблоны, стили, тексты, а также сниппеты конфигурации.

Основная конфигурация утилиты хранится в файле config.json в корневой папке, которую можно менять в соответствии со своими требованиями:

{
  "tailwind": true,
  "theme": "minimalistic",
  "locale": "en"
}

Шаблоны

Все шаблоны хранятся в папке themes, где стандартной темой является minimalistic, которую можно изменить или добавить новую. Каких‑то особых требований к шаблонам страниц нет: каждый шаблон является обыкновенным HTML документом, с внедренными переменными, на месте которых будут текстовки из файлов локализации. Для обработки внедренных переменных используется библиотека mustache.js. Таким образом, если нужно реализовать какую‑то особенную логику в своих шаблонах, то вы можете ознакомиться с документацией этой библиотеки для определения имеющихся возможностей шаблонизации.

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

Стили

Стилизация шаблонов базируется на фреймворке Tailwind CSS. С помощью этого фреймворка, можно быстро описывать стили страниц без необходимости писать отдельный CSS код. Точкой входа для стилей Tailwind должен быть файл themes/<name>/@assets/css/main.twnd.css. Из него в дальнейшем будет создан файл main.css, который содержит скомпилированные и минифицированные стили. В дополнение, можно настроить Tailwind с помощью создания кастомной конфигурации, расположенной в файле theme.tailwind.config.js в корне папки с темой, и описать в ней любые опции Tailwind. Полный список опций Tailwind доступен в документации самого Tailwind.

Однако, если по каким-то причинам использование Tailwind не требуется (например, стили уже описаны ранее в CSS), компиляцию стилей Tailwind можно отключить в основной конфигурации утилиты (файл config.json). В этом случае шаг сборки стилей будет просто пропущен без какого-либо влияния на финальный результат.

Текстовые сообщения и Локализация

Все текстовые сообщения хранятся в JSON файлах, разделенных по признаку языка, и расположены в папке src. Каждая страница создается из соответствующего ей файла локализации вида <Код HTTP>.json (<Код HTTP> – это число, соответствующее коду ошибки HTTP). Таким образом, если нужно создать страницу для кода, который еще не описан, то просто создайте соответствующий JSON файл, содержащий описание этого статуса в соответствующих свойствах.

Любой файл локализации может быть расширен любым количеством дополнительных свойств, которые вам нужно отобразить на странице. Для определения общих свойств, вы можете использовать файл common.json – свойства из этого файла будут применены к каждой странице.

Для локализации страниц, просто создайте новую папку в директории src, содержащую JSON файлы с текстами страниц. Создавая JSON файлы, вы можете описать любой набор HTTP кодов (например, только для 400-ых ошибок) – просто следуйте конвенции именования, и не забывайте выделять общие тексты в файл common.json.

Конфигурации сервера

В процессе работы, Утилита автоматически создаст сниппет для вашего сервера, который будет содержать лишь те страницы, которые были созданы. Данный сниппет будет содержать настройки обрабатываемых ошибок, и указывать на страницы, которые будут их представлять. Как было сказано ранее, на данный момент только Nginx поддерживается.

Для использования полученных страниц, остается только скопировать на сервер все файлы из папки dist и включить использование сниппета в уже существующей конфигурации сервера. В соответствии с шаблоном сниппета, все страницы должны быть расположены в папке /usr/share/nginx/html/error-pages. В случае если настройки в снипетта не подходят, то вы можете отредактировать шаблон сниппета в папке snippets. Так же как и для тем оформления, шаблоны конфигураций поддерживают mustache.js, тем позволяя реализовать в шаблоне любую логику (списки, условия и т. д.).

Сам по себе конфиг, я рекомендую располагать в папке /etc/nginx/snippets/, а для его подключения использовать строчку конфигурации: include /etc/nginx/snippets/nginx-error-pages.conf;. Разумеется, это не более чем рекомендация, т.к. в реальности всё может быть иначе или сложнее.

Ниже приведен простой пример конфигурации веб‑сервера с включенным в нее сниппетом кастомных ошибок:

server {
    server_name example.com;
    access_log /var/log/nginx/example.access.log;

    include /etc/nginx/snippets/nginx-error-pages.conf;

    location / {
        root /data/www;
    }
}

Демо

Посмотреть как выглядят страницы ошибок можно на моем сайте по следующим ссылкам:

• 400 Bad Request

• 401 Unauthorized

• 403 Forbidden

• 404 Not Found

• 410 Gone

• 500 Internal Server Error

• 502 Bad Gateway

• 503 Service Unavailable

• 504 Gateway Timeout

Сообщение об ошибках и запрос новых функций

Код утилиты нельзя назвать каким‑то сложным, однако, несмотря на этот факт, все значимые части покрыты юнит‑тестами. Впрочем, это не является гарантией отсутствия каких‑либо ошибок, поэтому если вы столкнетесь с какими‑то проблемами, то, пожалуйста, сообщите мне о них, через создание Issue в репозитории проекта: https://github.com/sapachev/error‑pages/issues

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

Участие в разработке

Проект открыт для всех желающих, и если у вас есть идеи, а главное желание и возможности их реализовать, то с радостью рассмотрю их в виде Pull Request. Со своей стороны готов предоставить вам поддержку в реализации вашей задумки. Не стесняйтесь спрашивать меня о коде, и возможных решениях вашей идеи.

Опубликовано 27.04.2023 14:00

Язык программирования PHP имеет уникальный вид отчетов об ошибках, в котором проще разобраться, чем в Python или C++. При этом у разработчиков есть возможность настроить отображение проблем в коде. В статье рассмотрим 3 способа проверить программу на сбои и отключить эту функцию.

Классификация ошибок

В PHP существует несколько обозначений ошибок, которые позволяют быстро определить источник и угрозу ошибки для стабильной работы скрипта. Их стоит знать, чтобы понимать, какие уведомления можно проигнорировать, а какие — нельзя. Классификация сбоев:

• E_ERROR — фатальные проблемы, из-за которых скрипт прекращает работу. Причиной может быть нехватка памяти, вызов несуществующего класса объектов, битая ссылка на подключаемый файл;
• E_WARNING — предупреждения об ошибке, которая не относится к фатальным, из-за чего программа продолжает работу. Однако она может выполнять программы не так, как запланировано. Распространенный вид ошибки, который чаще всего вызван неправильным аргументом при вызове функции;
• E_PARSE — компилятор не понимает, что написано в коде, т. к. разработчик допустил ошибки синтаксиса, например: незакрытые скобки, нет знаков препинания, перепутаны латинские символы и кириллица;
• E_NOTICE — мелкое нарушение во время выполнения скрипта. Возникает из-за обращения к несуществующим переменным, массивам, неопределенным константам;
• E_CORE_ERROR — фатальная ошибка обработчика, сгенерированная ядром языка программирования в момент запуска скрипта;
• E_CORE_WARNING — предупреждения о проблемах с ядром;
• E_COMPILE_ERROR — сбои, происходящие на этапе компиляции, которые приводят к остановке выполнения программы. Они генерируются скриптовым движком Zend;
• E_COMPILE_WARNING — уведомления о некритичных сбоях компилятора;
• E_DEPRECATED — предупреждение о том, что программист использует устаревшие конструкции, которые не будут работать после обновления среды разработки.

Способы вывода ошибок

Есть 3 актуальных способа настроить вывод ошибок, которые по задаче и сложности похожи, но различаются в деталях.

Через .htaccess

Используя файл .htaccess в каталоге, можно контролировать отображение программных сбоев. Чтобы активировать вывод проблем с кодом, нужно добавить в конфигурацию следующие строки:

php_flag display_startup_errors on

php_flag display_errors on

php_flag html_errors on

А для отключения отображения проблем разработчики используют похожие команды:

php_flag display_startup_errors off

php_flag display_errors off

php_flag html_errors off

В файле .htaccess можно создать редактируемый журнал программных ошибок, если он доступен для записи. Указав место расположения каталога или ссылку на него, программист автоматизирует сохранение истории всех сбоев.

Через логи PHP

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

Чаще всего программисты используют команду error_reporting. Режим вывода всех обнаруженных сбоев включается следующим образом:

error_reporting(E_ALL)

Для отключения вывода ошибок необходимо подставить 0 в скобки — error_reporting(0). Если же нужно убрать логирование только повторов ошибок, рекомендуется воспользоваться командами:

php_flag ignore_repeated_errors on

php_flag ignore_repeated_source on

Это удобный вариант для проверки файлов на ошибки, однако он работает непосредственно на устройстве разработчика. Можно сделать вывод с логированием через веб-сервер. В зависимости от платформы программисты пишут:

• для Apache — ErrorLog «/var/log/apache2/my-website-error.log»;
• для Nginx — error_log /var/log/nginx/my-website-error.log.

Если разработчик пользуется другим софтом, он может найти нужные аргументы на официальном сайте PHP.

Через файл php.ini

Однако если программный код длинный, а настроить отображение нужно только для отдельного фрагмента, подойдет другая команда. Она выглядит следующим образом:

ini_set('display_errors', 'On')

error_reporting(E_ALL)

Чтобы отключить вывод программных сбоев, необходимо изменить команду на: ini_set(‘display_errors’, ‘Off’).

Также стоит вызвать директиву display_errors = on. Она позволит посмотреть все существующие ошибки, включая мелкие синтаксические недочеты, которые не отображаются простой функцией ini_set.

Найти актуальный INI-файл легко найти, вызвав функцию phpinfo (). Он будет помечен, как файл конфигурации — loaded configuration file.

Какой способ выбрать

Для разработчиков, которые пользуются программным обеспечением для веб-серверов, подойдет метод вызова ошибок через логи. Это позволяет настроить отображение через конфигурации платформы. При этом проверка будет касаться не всех файлов без разбора, а только выбранных программистом.

Команда .htaccess имеет две директивы: display_startup_errors и display_errors. С их помощью можно легко настроить вывод информации о программных сбоях и синтаксических проблемах.

PHP.ini также удобен в работе и подойдет для проверки кода всего сайта. Однако не все провайдеры позволяют редактировать этот файл, что важно учитывать. Рекомендуется выбирать хостинги, которые не блокируют эту возможность.

Заключение

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

Начинающим разработчикам, которые работают в одном файле и не пользуются веб-серверами, подойдет первый метод отображения. Продвинутым программистам стоит пользоваться логами PHP, которые позволяют управлять выводом, не затрагивая другие скрипты. А администраторам серверов нужно освоить php.ini, т. к. его действие распространяется на все ресурсы, размещенные на одном веб-сервере.

• Главная»
• Уроки»

• PHP»

• Создаем единую страницу для обработки ошибок

• Метки урока:
• php
• кодинг
• разное

ErrorDocument 400 /errors.php
ErrorDocument 403 /errors.php
ErrorDocument 404 /errors.php
ErrorDocument 405 /errors.php
ErrorDocument 408 /errors.php
ErrorDocument 500 /errors.php
ErrorDocument 502 /errors.php
ErrorDocument 504 /errors.php

$status = $_SERVER['REDIRECT_STATUS'];
$codes = array(
       400 => array('400 Плохой запрос', 'Запрос не может быть обработан из-за синтаксической ошибки.'),
       403 => array('403 Запрещено', 'Сервер отказывает в выполнении вашего запроса.'),
       404 => array('404 Не найдено', 'Запрашиваемая страница не найдена на сервере.'),
       405 => array('405 Метод не допускается', 'Указанный в запросе метод не допускается для заданного ресурса.'),
       408 => array('408 Время ожидания истекло', 'Ваш браузер не отправил информацию на сервер за отведенное время.'),
       500 => array('500 Внутренняя ошибка сервера', 'Запрос не может быть обработан из-за внутренней ошибки сервера.'),
       502 => array('502 Плохой шлюз', 'Сервер получил неправильный ответ при попытке передачи запроса.'),
       504 => array('504 Истекло время ожидания шлюза', 'Вышестоящий сервер не ответил за установленное время.'),
);
 
$title = $codes[$status][0];
$message = $codes[$status][1];
if ($title == false || strlen($status) != 3) {
       $message = 'Код ошибки HTTP не правильный.';
}
 
echo '<h1>Внимание! Обнаружена ошибка '.$title.'!</h1>
<p>'.$message.'</p>';

5 последних уроков рубрики «PHP»

• 

  Фильтрация данных с помощью zend-filter

  Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

• 

  Контекстное экранирование с помощью zend-escaper

  Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

• 

  Подключение Zend модулей к Expressive

  Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

• 

  Совет: отправка информации в Google Analytics через API

  Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

• 

  Подборка PHP песочниц

  Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

1. Кнопка:

   Она выглядит вот так:
2. Текстовая ссылка:

   Она выглядит вот так: Как создать свой сайт

3. BB-код ссылки для форумов (например, можете поставить её в подписи):