Внимание! Сайт переехал на новый домен sayt-sozdat.ru. Пожалуйста, обновите страницы закладок с новыми URL
×
Закрытие
×

Дополнительные материалы бесплатно предоставляются только зарегистрированным пользователям.

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

Для тех кто не зарегистрирован, можно это сделать на вкладке Регистрация.

Устанавливаем графический редактор GIMP

  1. Выбор графического редактора
  2. Устанавливаем программу GIMP
  3. Устанавливаем Руководство пользователя

Здравствуйте уважаемый посетитель!

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

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

Кроме того здесь можно будет посмотреть, как в этот редактор добавить встроенное "Руководство пользователя", а также приведен бесплатный видеокурс, где можно поближе с ним познакомиться.

Для тех же, кто хочет заниматься дизайном на платном Adobe Photoshop (фотошоп), здесь также упомянут и такой вариант, основанный на использовании продления льготного бесплатного периода фотошопа на неопределенное время...

Cайт на практическом примере

Текущее состояние создаваемого сайта

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

Исходные файлы данного сайта можно скачать из прилагаемых к статьям дополнительных материалов.

Вы здесь: Главная → Сборник статей → Обработка ошибок → Обработка ошибок PHP и статуса 404 HTTP


Автор: / Дата:

Обработка ошибок PHP и статуса 404 HTTP

Обработка ошибок PHP и статуса 404 HTTP

Здравствуйте, уважаемый посетитель!

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

В частности, здесь мы рассмотрим три, наиболее часто, встречающихся случая возникновения ошибок:

  1. ошибка 404, возникающая в отсутствии запрашиваемого ресурса на сайте, что соответствует статусу 404 (Not Found) протокола HTTP;
  2. ошибка 500, которая может быть вызвана, как фатальными ошибками PHP, приводящими к прекращению работы скрипта, так и другими критическими ситуациями, соответствующими внутренней ошибки сервера (Internal Server Error);
  3. не фатальные (предупреждения) ошибки PHP, которые не останавливают работу скрипта и не оказывают какого-либо существенного влияния формирование страницы, но требуют определенных действий по их перехвату, сохранению и анализу, а также скрытию сообщений об ошибках на страницах сайта.

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

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

Ниже будут изложены основные моменты, которые будут учитываться в создаваемой системе обработки ошибок. А в последующих статьях посмотрим, как это можно реализовать практически.

Содержание


  • Ошибка 404 (Not Found) статуса HTTP
  • Внутренняя ошибка сервера 500 (Internal Server Error)
  • Не фатальные (предупреждающие) ошибки PHP
  • Сохранение лог-файлов ошибок
  • Автоматическая отправка почтовых сообщений при критических ошибках

Ошибка 404 (Not Found) статуса HTTP


В большинстве случаев ошибка с кодом 404 (Not Found) протокола HTTP может возникать по следующим причинам:

  • ошибки в URL, которые допускают пользователи при непосредственном вводе ссылок в адресном поле браузера;
  • внешние неверные ссылки, указывающие на несуществующие страницы сайта;
  • наличие внутренних битых ссылок на отсутствующие на сайте ресурсы, включая изображения и другие файлы, используемые при формировании веб-страниц;
  • неправильный редирект на страницу, которая сменила адрес;

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

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

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

Для примера ниже показана скриншот страницы 404, которая используется здесь на сайте. Где видно, что попав на нее, пользователь с легкостью сможет и дальше пользоваться сайтом не покидая его.

Пример страницы 404

Рис.1 Пример страницы 404

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

Помимо этого, для поисковой оптимизации, необходимо правильно обрабатывать такого вида ошибки, отправляя в ответах сервера код, соответствующий статусу протокола HTTP 404 (Not Found), а не 200 (OK) или какой-либо другой.

В противном случае, при переходе по ссылке на несуществующую страницу в отсутствии кода 404, (тем более, если при этом используется редирект сразу на главную или какую-либо другую, заведомо определенную для этих целей страницу), будут возникать многочисленные дубли с одинаковым контентом. Что негативно будет сказываться на лояльность к сайту поисковых систем.

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

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

Внутренняя ошибка сервера 500 (Internal Server Error)


Внутренняя ошибка сервера 500 (Internal Server Error) - второй вид ошибок, которому здесь будет уделено внимание. В основном это фатальные ошибки PHP, при которых работа скрипта прекращается, что вызывает невозможность полноценного отображения и функционирования страницы. К этой категории можно отнести следующие виды:

  • E_ERROR - ошибка при невозможности выполнения скрипта, например, вызов несуществующей функции, ошибка распределения памяти и т.п.;
  • E_PARSE - в случае грубой ошибки синтаксиса, при которой интерпретатор PHP не может определить, какие действия требуется выполнить;
  • E_CORE_ERROR - ошибки, которые происходят во время запуска РНР;
  • E_COMPILE_ERROR - ошибки на этапе компиляции.

Кроме этого ошибка 500 может возникать и в других случаях, относящихся к внутренней ошибке сервера. Например, причиной, при котором сервер выдает статус 500 может быть и простая ошибка синтаксиса файла .htaccess.

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

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

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

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

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

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

Пример страницы 500

Рис.2 Пример страницы ошибки 500

Можно обратить внимание, что страница ошибки 500 отличается от предыдущей тем, что в ней отсутствуют некоторые блоки сайта. Обусловлено это тем, что она намерена создана с использованием только элементов HTML без какого-либо использования кода PHP.

Не фатальные (предупреждающие) ошибки PHP


Другой вид ошибок PHP - не фатальные при которых не происходит прекращение работы скрипта. К этой категории относятся такие предопределенные константы, как: E_WARNING, E_NOTICE, E_CORE_WARNING, E_COMPILE_WARNING, E_USER_WARNING, E_USER_NOTICE, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED, с описанием которых можно ознакомиться здесь.

скриншот 76

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

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

Обработка данного вида ошибок наиболее проста по сравнению с предыдущими случаями. Их перехват и сохранение будет обеспечиваться через функцию set_error_handler() пользовательским обработчиком, который мы в дальнейшем для этого создадим.

Остальные же действия по задание их уровня и запрещению вывода сообщений на страницу будут определяться настройкой конфигурации протоколирования ошибок во время выполнения, которую можно изменить с помощью использования функции ini_set() с нужными параметрами, либо соответствующими директивами файла .htaccess.

Сохранение лог-файлов ошибок


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

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

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

  • запрос к несуществующим ресурсам сайта (ошибка 404) при переходе с внутренних ссылок;
  • все остальные случаи ошибки 404 при запросах с внешних ссылок;
  • фатальные ошибки PHP;
  • не фатальные ошибки PHP;

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

Автоматическая отправка почтовых сообщений при критических ошибках


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

К таким случаям будут отнесены два, наиболее значимых вида ошибок:

  • фатальные ошибки PHP;
  • запрос к несуществующим ресурсам сайта (ошибка 404) при переходе с внутренних ссылок;

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

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

И при практическом рассмотрении этого вопроса мы посмотрим примеры, как из почтовых сообщений можно увидеть, когда на какой-либо странице возникает битая ссылка на несуществующую страницу. А также случаи с обнаружением переходов на другие ресурсы, которых по каким-либо причинам, в действительности, нет на сайта. Например, при теге <img>, в котором в атрибуте src задан путь к несуществующему файлу изображения.

Ниже показан скриншот такого почтового сообщения из реальной жизни.

Пример почтового сообщения об ошибке 404

Рис.2 Пример почтового сообщения об ошибке 404


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

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

С уважением, Николай Гришин


Комментарии


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

Буду Вам за это очень признателен!