Как правило, при попытке обращения к объекту, который не существует или более неактивен, стандартный компонент Битрикс выводит надпись "Элемент не найден".
Иногда вместо указанной надписи заказчик просит выводить содержимое страницы 404:
При этом, требуется соблюдение следующих условий: сохранение оригинального адреса обращения, установка правильного кода ответа (404) и отсутствие дополнительных перенаправлений (301 или 302). По мнению некоторых специалистов по продвижению, перечисленные требования необходимы для корректной обработки страницы поисковыми роботами.
Существует несколько решений данной задачи. Далее будет рассмотрено, пожалуй, наиболее лаконичное из всех. Единственным обязательным требованием, которое определяет работоспособность результата, является наличие сервера nginx "на входе". При этом, доступ к файлам конфигурации веб-сервера не требуется.
Решение
В файле с обработчиками событий (например, /bitrix/php_interface/init.php) следует разместить следующий обработчик:
Примечания:
Первое условие проверяет наличие и значение константы ERROR_404. Данная константа определяется большинством стандартных компонентов Битрикс в том случае, если не удалось найти объект, к которому произошло обращение. В качестве объекта может выступать, например, элемент информационного блока.
Второе услове позволяет избежать бесконечного зацикливания — как правило, скрипт, отвечающий за вывод страницы 404, тоже устанавливает вышеупомянутую константу.
Следующая строка определяет внутреннее перенаправление для nginx. При этом, все происходящее остается незаметным для клиента.
Особое внимание стоит обратить на служебный заголовок "X-Accel-Redirect". Этот заголовок ожидается исключительно веб-сервером nginx и позволяет организовать внутреннее перенаправление из PHP. Как ни странно, информации об этом заголовке в Сети незаслуженно мало: из разумных примеров мне удавалось найти лишь способ построения системы контролируемых скачиваний. На деле же, данный функционал предоставляет возможность для элегантного решения широкого класса задач.
Дополнение:
В начало файла 404.php, до включения urlrewrite.php, разумно добавить следующее условие:
Данный блок кода позволит избежать бесконечной цикличной переадресации (и ошибки 500) в случаях, когда PHP работает в режиме FastCGI с типовыми настройками, например, через php-fpm. В случае работы через proxy_pass – наиболее частый вариант – проблема не возникает.
Иногда вместо указанной надписи заказчик просит выводить содержимое страницы 404:
При этом, требуется соблюдение следующих условий: сохранение оригинального адреса обращения, установка правильного кода ответа (404) и отсутствие дополнительных перенаправлений (301 или 302). По мнению некоторых специалистов по продвижению, перечисленные требования необходимы для корректной обработки страницы поисковыми роботами.
Существует несколько решений данной задачи. Далее будет рассмотрено, пожалуй, наиболее лаконичное из всех. Единственным обязательным требованием, которое определяет работоспособность результата, является наличие сервера nginx "на входе". При этом, доступ к файлам конфигурации веб-сервера не требуется.
Решение
В файле с обработчиками событий (например, /bitrix/php_interface/init.php) следует разместить следующий обработчик:
define("PREFIX_PATH_404", "/404.php");
AddEventHandler("main", "OnAfterEpilog", "Prefix_FunctionName");
function Prefix_FunctionName() {
global $APPLICATION;
// Check if we need to show the content of the 404 page
if (!defined('ERROR_404') || ERROR_404 != 'Y') {
return;
}
// Display the 404 page unless it is already being displayed
if ($APPLICATION->GetCurPage() != PREFIX_PATH_404) {
header('X-Accel-Redirect: '.PREFIX_PATH_404);
exit();
}
} |
Примечания:
- Имя функции обработчика следует изменить согласно правилам наименования функций в вашем проекте;
- Определение константы, содержащий путь к странице 404 также стоит заменить подходящими значениями.
Первое условие проверяет наличие и значение константы ERROR_404. Данная константа определяется большинством стандартных компонентов Битрикс в том случае, если не удалось найти объект, к которому произошло обращение. В качестве объекта может выступать, например, элемент информационного блока.
Второе услове позволяет избежать бесконечного зацикливания — как правило, скрипт, отвечающий за вывод страницы 404, тоже устанавливает вышеупомянутую константу.
Следующая строка определяет внутреннее перенаправление для nginx. При этом, все происходящее остается незаметным для клиента.
Особое внимание стоит обратить на служебный заголовок "X-Accel-Redirect". Этот заголовок ожидается исключительно веб-сервером nginx и позволяет организовать внутреннее перенаправление из PHP. Как ни странно, информации об этом заголовке в Сети незаслуженно мало: из разумных примеров мне удавалось найти лишь способ построения системы контролируемых скачиваний. На деле же, данный функционал предоставляет возможность для элегантного решения широкого класса задач.
Дополнение:
В начало файла 404.php, до включения urlrewrite.php, разумно добавить следующее условие:
if ($_SERVER['DOCUMENT_URI'] == "/404.php") {
$_SERVER['REQUEST_URI'] = $_SERVER['DOCUMENT_URI'];
} |
Данный блок кода позволит избежать бесконечной цикличной переадресации (и ошибки 500) в случаях, когда PHP работает в режиме FastCGI с типовыми настройками, например, через php-fpm. В случае работы через proxy_pass – наиболее частый вариант – проблема не возникает.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
