These are all great answers for redirecting to 404 error, for a single page. Here’s a solution that will allow you to test a condition and redirect for any script on your site.
Write up a .htaccess file, with the rewrite rules, and using [QSA,NC,L] to maintain the page location and the header post/get arguments…
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,NC,L]
This will cause every page to redirect to ./index.php (feel free to rename this if you’re already using an index.php). The URL will not be changed. Then, in index.php, check some condition, and if passes, include the $_SERVER variable indicating the script, otherwise, do a custom 404. This means you can simply control the exception handling in index.php with…
$someNon404Condition = file_exists($_SERVER['PHP_SELF']);
if ($someNon404Condition) {
include($_SERVER['PHP_SELF']); // do the stuff
} else {
print("404! Why are you trying to access " . $_SERVER['PHP_SELF'] . "?");
}
This lets you do tons of other things, too! Forget a static 404.html page, with a dynamic one you can…
- Your condition can be as complicated as you can code: check authentication, check for permanent redirects, maybe you want to expire content automatically? Etc., etc..
- Search your DB for
explode('/', $_SERVER['PHP_SELF']), and then display a list of those matched results under the header «Maybe this is what you were looking for?» - Respond to user-level events: Is it a 404 because the page was moved? Then handle a redirect. Is it a 404 because a moderator deleted it and it was the user’s post? Tell the user a moderator deleted their post. Etc., etc..
- Make API calls, dynamic code, etc., etc., the possibilities are there.
- Главная»
- Уроки»
- PHP»
- Создаем единую страницу для обработки ошибок
- Метки урока:
- php
- кодинг
- разное
Создаем единую страницу для обработки ошибок
В данном уроке представлено очень простое решение для обработки различных ошибок HTTP, таких как 404, 500 и так далее, в одном файле PHP. Нужно создать массив кодов ошибок и установить правила перенаправления на наш PHP файл. То есть, можно использовать одну страницу для обработки нескольких ошибок.
Перенаправление
В файле .htaccess вашего сервера нужно установить правила для обработки ошибок. В нашем случае мы будем перенаправлять все ошибки в наш файл errors.php, который будет формировать страницу HTML для посетителя. Добавляем в файл .htaccess следующие правила:
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
PHP
Теперь создаем файл errors.php, который должен располагаться в корневом каталоге вашего сервера (так как такое его местоположение установлено в заданных нами выше правилах в файле .htaccess).
$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>';
Готово!
Конечно, код PHP может формировать и более информативную страницу для пользователя. При формировании разметки стоит учесть рекомендации для страниц, выводящих информацию об ошибках.
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 сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
2
×
Дополнительные материалы бесплатно предоставляются только зарегистрированным пользователям.
Для скачивания исходных файлов необходимо авторизоваться под своим аккаунтом через соответствующую форму.
Для тех кто не зарегистрирован, можно это сделать на вкладке Регистрация.
⯈
Устанавливаем графический редактор GIMP
- Выбор графического редактора
- Устанавливаем программу GIMP
- Устанавливаем Руководство пользователя
Здравствуйте уважаемый посетитель!
При создании и развитии сайта не обойтись без графического редактора. Этот инструмент необходим для формирования и обработки различных графических элементов, без которых сайт попросту не сможет существовать. Поэтому в наборе инструментов вебмастера графический редактор занимает важнейшее место.
В статье Устанавливаем бесплатный графический редактор GIMP речь пойдет о бесплатной программе GIMP, которая позволяет в полной мере решать вопросы по созданию элементов дизайна веб-страниц. И будет показано, как ее установить на локальный компьютер.
Кроме того здесь можно будет посмотреть, как в этот редактор добавить встроенное «Руководство пользователя», а также приведен бесплатный видеокурс, где можно поближе с ним познакомиться.
Для тех же, кто хочет заниматься дизайном на платном Adobe Photoshop (фотошоп), здесь также упомянут и такой вариант, основанный на использовании продления льготного бесплатного периода фотошопа на неопределенное время…
Cайт на практическом примере
Здесь можно посмотреть текущее состояние сайта, создаваемого в рамках цикла статей Самописный сайт с нуля своими руками.
Исходные файлы данного сайта можно скачать из прилагаемых к статьям дополнительных материалов.
- Предыдующая статья: Делаем выпадающее меню на CSS
2019-10-23
Здравствуйте, уважаемый посетитель!
Этой статьей начинается новый раздел, в котором будет рассматриваться достаточно важный вопрос, без решения чего невозможно обеспечить нормальное функционирование любого сайта. Речь идет об обработке ошибочных ситуаций на стороне веб-сервера при выполнении PHP, а также статуса протокола HTTP с кодом 404.
В частности, здесь мы рассмотрим три, наиболее часто, встречающихся случая возникновения ошибок:
- ошибка 404, возникающая в отсутствии запрашиваемого ресурса на сайте, что соответствует статусу 404 (Not Found) протокола HTTP;
- ошибка 500, которая может быть вызвана, как фатальными ошибками PHP, приводящими к прекращению работы скрипта, так и другими критическими ситуациями, соответствующими внутренней ошибки сервера (Internal Server Error);
- не фатальные (предупреждения) ошибки PHP, которые не останавливают работу скрипта и не оказывают какого-либо существенного влияния формирование страницы, но требуют определенных действий по их перехвату, сохранению и анализу, а также скрытию сообщений об ошибках на страницах сайта.
Существует множество способ обработки ошибок, и наверное, каждый веб-мастер использует свой, исходя из своего опыта и предпочтений.
Здесь же я изложу свой вариант, где на практических примерах покажу, как можно создать достаточно эффективный механизм, который позволит регистрировать ошибки в соответствии с их классификацией, сохранять их логи и в постоянном режиме отслеживать состояние сайта с помощью автоматической отправки почтовых сообщений о возникновении ошибок, серьезно влияющих на его работу.
Ниже будут изложены основные моменты, которые будут учитываться в создаваемой системе обработки ошибок. А в последующих статьях посмотрим, как это можно реализовать практически.
- Ошибка 404 (Not Found) статуса HTTP
- Внутренняя ошибка сервера 500 (Internal Server Error)
- Не фатальные (предупреждающие) ошибки PHP
- Сохранение лог-файлов ошибок
- Автоматическая отправка почтовых сообщений при критических ошибках
Ошибка 404 (Not Found) статуса HTTP
В большинстве случаев ошибка с кодом 404 (Not Found) протокола HTTP может возникать по следующим причинам:
- ошибки в URL, которые допускают пользователи при непосредственном вводе ссылок в адресном поле браузера;
- внешние неверные ссылки, указывающие на несуществующие страницы сайта;
- наличие внутренних битых ссылок на отсутствующие на сайте ресурсы, включая изображения и другие файлы, используемые при формировании веб-страниц;
- неправильный редирект на страницу, которая сменила адрес;
При этом любой веб-сервер при коде 404 статуса HTTP по умолчанию выдает соответствующую техническую страницу. И может показаться, что в этом отношении все хорошо, и нечего с этим вопросом лишний раз заморачиваться.
Однако, в действительности, использовать свою индивидуальную страницу 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.
Рис.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, связанным с битыми внутренними ссылками, то из своего опыта скажу, что это очень полезный инструмент. Так как такое решение позволяет в постоянном режиме выявлять случаи возникновения проблем не только с внутренними ссылками на несуществующие страницы сайта, но и попытки обращения к отсутствующим файлам, включая изображения и видео, которые требуются для формирования веб-страниц.
И при практическом рассмотрении этого вопроса мы посмотрим примеры, как из почтовых сообщений можно увидеть, когда на какой-либо странице возникает битая ссылка на несуществующую страницу. А также случаи с обнаружением переходов на другие ресурсы, которых по каким-либо причинам, в действительности, нет на сайта. Например, при теге , в котором в атрибуте src задан путь к несуществующему файлу изображения.
Ниже показан скриншот такого почтового сообщения из реальной жизни.
Рис.2 Пример почтового сообщения об ошибке 404
Таким образом, здесь перечислены в общем виде все те функциональные возможности, которыми будет обладать рассматриваемая система обработки ошибок. А что использовать, каждый будет волен для себя решить сам.
Далее мы перейдем к практической реализации всего сказанного, и в первую очередь рассмотрим обработку запросов на несуществующие ресурсы сайта, что соответствует коду 404 статуса HTTP.
С уважением,
- Следующая сатья: Делаем собственную страницу ошибки 404
Если у Вас возникли вопросы, или есть какие-либо пожелания по представлению материала, либо заметили какие-нибудь ошибки, а быть может просто хотите выразить свое мнение, пожалуйста, оставьте свои комментарии. Такая обратная связь очень важна для возможности учета мнения посетителей.
Буду Вам за это очень признателен!
Если пользователь вобьет в адресную строку
некорректный URL мы должны показать страницу
с ошибкой. Пусть контент страницы с ошибкой
будет хранится в соответствующем файле:
<div>
page not found
</div>
Для того, чтобы определить некорректность
запроса, нам необходимо проверить существование
файла контента, соответствующего запрошенному URL:
<?php
$path = 'view' . $url . '.php';
if (file_exists($path)) {
// файл есть
} else {
// файла нет
}
?>
Давайте будем отдавать файл контента, если
он есть, и файл с ошибкой, если контента нет:
<?php
$path = 'view' . $url . '.php';
if (file_exists($path)) {
$content = file_get_contents($path);
} else {
$content = file_get_contents('view/404.php');
}
?>
В случае с ошибкой мы должны отправить в
браузер заголовок с 404 ошибкой, чтобы
явно сообщить о том, что страница не найдена.
Сделаем это:
<?php
$path = 'view' . $url . '.php';
if (file_exists($path)) {
$content = file_get_contents($path);
} else {
header('HTTP/1.0 404 Not Found');
$content = file_get_contents('view/404.php');
}
?>
Реализуйте в вашем движке отдачу страницы
с 404 ошибкой.
Essentially, what I am doing is intercepting a 404 using ErrorDocument in .htaccess, and pointing it at getFile.php. getFile then grabs the file name out of the url and searches for it in the mysql database, getting the data and applying appropriate headers.
In my dev environment (up-to-date LAMP server running under ubuntu) everything seems to work fine, but the site is being hosted on GoDaddy, and there seems to be some issue with the headers returned. I think GoDaddy returns a 404, then sends the data anyway.
The result is when I right click on a link that is to be handled in this manner, I can ‘Save As’, and everything works fine. If the file is an image, it opens no problem. But if I just click the link and it is a file that is to be downloaded rather than viewed in a browser, I get ‘File Not Found’ errors, across all browsers. Firebug Console claims it is a 404 error, regardless of whether the file successfully transfers. My code is the following:
$folder = explode( "/" , $_SERVER["REQUEST_URI"] );
$pageName = $folder[sizeof($folder)-1];
$sql = "SELECT data, mimeType, OCTET_LENGTH(data) AS size FROM tblFiles WHERE fileName = '".$pageName."' AND active=1;";
$result = mysql_query("$sql") or die();
$data = mysql_fetch_array($result);
header("HTTP/1.0 200 OK");
header("Content-Type: ".$data['mimeType']);
header("Content-Length: ".$data['size']);
echo $data['data'];
And the .htaccess file:
ErrorDocument 404 /FILES/dbFiles/getFile.php
Now this is the full .htaccess file present at /FILES/dbFiles. I don’t know if GoDaddy is expecting more stuff in there, but it seems to work just as written on my own server.
I’ve tried numerous combinations of header info with no positive effect.
My code apparently works, but I can’t seem to prevent that 404 from happening.
Thanks!
-Jer