Введение
Laravel: Когда вы используете любое приложение в “реальном мире”, вы чувствуете себя более уверенным когда знаете как оно работает. Разработка программного обеспечения не исключение. Когда вы понимаете как работает та или иная система, вы чувствуете себя комфортнее.
Жизненный цикл запроса
В отличии от многих современных MVC-фреймворков, продукт Битрикс24 не использует концепцию единой точки входа. Это дает преимущество в гибкости построения маршрутов и не накладывает искусственных ограничений на разработчика.
Как выполняется запрос?
- Проверяется физическое существование файла.
- если существует файл, он будет исполнен
- Проверяется является ли директория символьной ссылкой.
- если искомая директория является символьной ссылкой то физически будет подключен ссылаемый на нее файл.
- Проверяется физическое существование папки.
- если папку существует, будет подключен index.php
- Происходит подключение файла с ЧПУ
/bitrix/urlrewrite.php
Исторически битрикс отрабатывает все правила переадресации через 404 ошибку, учитывайте это при разработке вашего программного обеспечения.
Структура urlrewrite.php
На момент написания статьи платформа использует аналог роутов
(маршрутов) - правила адресации. Все существующие в системе правила описываются в переменной $arUrlRewrite
внутри urlrewrite.php
.
Каждое правило состоит из нескольких полей, описывающих его:
CONDITION
- регулярное выражение для проверки $_SERVER["REQUEST_URI"]
на соответствии правилу.
RULE
- правила замены переменных для строки переменных.
ID
- имя компонента добавившего правило.
PATH
- физический файл, который будет подключен.
SORT
- приоритет правила для сортировки.
Правила располагаются в файле в порядке приоритетов сортировки, однако при одинаковой сортировке правила будут отсортированы по длинне поля
CONDITION
.
Необходимым минимумом для описания маршрута являются ключи CONDITION
и PATH
.
Пример маршрутов, описанных в файле:
$arUrlRewrite = [
[
'CONDITION' => '#^/pub/form/([0-9a-z_]+?)/([0-9a-z]+?)/.*#',
'RULE' => 'form_code=$1&sec=$2',
'ID' => NULL,
'PATH' => '/pub/form.php',
'SORT' => 100,
],
[
'CONDITION' => '#^/crm/configs/deal_category/#',
'RULE' => '',
'ID' => 'bitrix:crm.deal_category',
'PATH' => '/crm/configs/deal_category/index.php',
'SORT' => 100,
]
];
Давайте остановимся разберем эти правила подробнее.
Предположим мы хотим открыть страницу: /pub/form/some_test/somesec/dome_file.php?qparam=qvalue
в федолтной структуре битрикса.
Полный алгоритм будет выглядеть так:
- Проверяется физическое существование файла.
Физического файла
/pub/form/some_test/some_sec/dome_file.php
не сущестивует. Шаг пропущен. - Проверяется является ли директория символьной ссылкой. Символьной ссылки тоже нет. Шаг пропущен
- Проверяется физическое существование папки. Происходит подключение папки, а не физ.файла. Шаг пропущен.
- Происходит подключение файла с ЧПУ
/bitrix/urlrewrite.php
- В файле
urlrewrite.php
определены правила. Обработаем первое правило. - Правило подходит, подключим страницу /pub/form.php
Давайте посмотрим внимательно, что реально мы получим на странице и зачем нужно правило RULE
: при открытии страницы мы указали QUERY_STRING = ?test=123
, однако если мы выведем значение $_SERVER['QUERY_STRING]
на экран, мы не увидим нашего параметра, а увидим указанное в PATH
ключе заполненное правило form_code=some_test&sec=somesec
. Однако это вовсе не означает что оно не доступно теперь, если попробовать обратиться к $_GET
или $_POST
мы можем получить значения и qparam
и form_code
и sec
.
Как работает RULE-параметр
Параметр RULE
является необязательным для описания маршрута, однако именно он открывает много возможностей для управления ЧПУ.
Именно на его основе формируется реальный используемый URL путем выполнения preg_replace функции с аргументами CONDITION
, PATH
.RULE
на REQUEST_URL
.
Таким образом битрикс обработает наш запрос как если бы он сразу поступил на адрес /pub/form.php?form_code=some_test&sec=somesec
.
Перерасчет правил
Не стоит слепо полагаться на этот файл и порядок внутри него. Механизмы платформы зачастую изменяют этот файл при любом редактировании в публичной части и правила могут быть рассчитаны.
Роутинг
Не смотря на то, что правила маршрутизации закрывают основную потребность в обработке ссылок они не являются удобными для разработки в целом. На момент написания статьи комманда core-разработчиков платформы готовит введение механизма замещающего правила обработки, однако на данный момент она не реализована.