Что за файл urlrewrite php как он формируется что содержит зачем

Juggernaut. Новый, шустрый и простой UrlRewrite

Продолжаем лупить статьи на тему «Битрикс не так уж и плох, если его доработать».
На этот раз разговор пойдет на тему «url_rewrite», потому как я считаю, что текущий вариант вообще не идеален.
А идеальным я считаю вариант маршрутизации в микрофреймворках, например Slim (или тот же Lumen), вообщем тех, которые дружат с PSR-7.

25992a7f9f4844af87ab4300fd2bc9e6

INTRO

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

Кстати про Juggernaut

UrlRewrite by Bitrix

Порядок маршрутизации я думаю лучше изобразить схемкой (и понятно, и наглядно):

95272de32a7f4f1cbceef6f9b538d9ca

Что это все значит:

fix request_uri for IIS
Данный пункт, судя по комменту в коде, ответственен за какие то косяки IIS (бедняга MS), за какие я не в курсе, но логика следующая:
если QUERY_STRING имеет вид «wtf=404;http(s)://wtf.ru», то все GET параметры запроса чистятся и данная конструкция убирается из адреса.
На вопрос «что проиходит?» я не могу дать ответа, так что едем дальше.

include dbconn.php
Подключаем базу.
Зачем? Непонятно, т. к. запросов к базе дальше нет и работа идет только с файловой системой.
Я конечно не опускался в реализацию классов для работы с файлами, но если им нужно что-либо от базы, то это не иначе как печально

decode request page (for UTF-8 )
Все понятно из названия, кодирование REQUEST_URI.
Зачем? Зачем Битрикс любит Windows-1251? Без понятия. Но это будет продолжаться вечно (и это инсайдерская информация).

include /urlRewrite.php
Собственно подключаем сами правила маршрутизации.

Много неясностей, зачем сделано так, а не иначе?
Ну и много неясностей, зачем вообще это сделано?
Так что теперь перейдем к идеальному варианту Slim’a.

UrlRewrite by Slim

Как делает этот замечательный фреймворк:

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

UrlRewrite by Juhhernaut

Ну, а теперь пробуем все это миксануть.
Выкидываем из Slim’a указание метода и собственно реализацию действия, вместо нее будет путь до файла.
Для начала обозначим синтаксис привязки маршрутов к реальным физически файлам (по факту это является мануалом использования):

И собственно все. Простой и понятный роутинг у вас в кармане.

Источник

Bitrix — UrlRewrite (feat. Juggernaut)

25992a7f9f4844af87ab4300fd2bc9e6

Продолжаем лупить статьи на тему «Битрикс не так уж и плох, если его доработать».
На этот раз разговор пойдет на тему «url_rewrite», потому как я считаю, что текущий вариант вообще не идеален.
А идеальным я считаю вариант маршрутизации в микрофреймворках, например Slim (или тот же Lumen), вообщем тех, которые дружат с PSR-7.
Кому интересно, го под кат.
Кому не интересно, ну тут уж сами решайте 😉

INTRO

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

Кстати про Juggernaut

Но это как говорить «совсем другая история», поэтому вернемся к тому, о чем собственно данная статья: роутинг.

UrlRewrite by Bitrix

Порядок маршрутизации я думаю лучше изобразить схемкой (и понятно, и наглядно):

image loader

Что это все значит:

include bitrix/urlRewrite.php
Подключаем файл который занимается маршрутизацией (ну это я думаю и так все поняли).
Вообще данный пункт (и все что выше на блок схеме) — это заслуги .htaccess:

fix request_uri for IIS
Данный пункт, судя по комменту в коде, ответственен за какие то косяки IIS (бедняга MS), за какие я не в курсе, но логика следующая:
если QUERY_STRING имеет вид «wtf=404;http(s)://wtf.ru», то все GET параметры запроса чистятся и данная конструкция убирается из адреса.
На вопрос «что проиходит?» я не могу дать ответа, так что едем дальше.

include dbconn.php
Подключаем базу.
Зачем? Непонятно, т. к. запросов к базе дальше нет и работа идет только с файловой системой.
Я конечно не опускался в реализацию классов для работы с файлами, но если им нужно что-либо от базы, то это не иначе как печально 🙁

decode request page (for UTF-8)
Все понятно из названия, кодирование REQUEST_URI.
Зачем? Зачем Битрикс любит Windows-1251? Без понятия. Но это будет продолжаться вечно (и это инсайдерская информация).

include /urlRewrite.php
Собственно подключаем сами правила маршрутизации.

Много неясностей, зачем сделано так, а не иначе?
Ну и много неясностей, зачем вообще это сделано?
Так что теперь перейдем к идеальному варианту Slim’a.

UrlRewrite by Slim

Как делает этот замечательный фреймворк:

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

UrlRewrite by Juhhernaut

Ну, а теперь пробуем все это миксануть.
Выкидываем из Slim’a указание метода и собственно реализацию действия, вместо нее будет путь до файла.
Для начала обозначим синтаксис привязки маршрутов к реальным физически файлам (по факту это является мануалом использования):

По факту, если реализацию маршрутов оставить на совести компонентов, то достаточно будет прописать следующую конструкцию (да, так тоже можно 😉 ):

И собственно все. Простой и понятный роутинг у вас в кармане.

Источник

Обработка адресов

Понятие обработки адресов

Обработка адресов (UrlRewrite) применяется для того, чтобы скрипт мог отвечать не только по своему физическому, но и по любому другому указаному адресу. Например, можно задать настройки обработки адресов, чтобы скрипт в файле /fld/c.php, отвечающий по адресу

отвечал также по адресу

Адрес, по которому будет отвечать скрипт, не должен физически существовать на сервере. Если такой адрес физически существует, то будет вызван скрипт по этому адресу. Система обработки адресов запущена в этом случае не будет.

Правила обработки

Правила обработки адресов настраиваются отдельно для каждого сайта и хранятся в корне сайта в файле urlrewrite.php. Файл содержит массив $arUrlRewrite, каждая запись которого является правилом обработки адреса. Файл urlrewrite.php имеет следующий вид:

Каждое правило должно содержать уникальное в рамках сайта условие выполнения правила. Условие выполнения записывается в ключ «CONDITION» массива и является шаблоном Perl-совместимого регулярного выражения. Например, условие:

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

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

и пользователь запросил страницу:

которая физически не существует, то система обработки адресов подключит скрипт:

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

и пользователем запрошена страница:

то для формирования адреса скрипта, который будет подключен, выполнится код:

и будет подключен скрипт:

Если в системе обработки адресов зарегистрировано правило:

и пользователем запрошена страница:

то для формирования адреса скрипта, который будет подключен, выполнится код:

и будет подключен скрипт:

Правило может содержать имя компонента, который создал это правило. Это имя записывается в ключ «ID«. При автоматическом пересоздании файла правил urlrewrite.php с помощью средств административной части сайта пересоздаются только правила, у которых заполнен ключ «ID«. Эти правила пересоздаются на основании анализа физических файлов в папке сайта. Правила с пустым ключом «ID» при автоматическом пересоздании файла правил не изменяются.

Подключение системы обработки адресов

Перед началом использования система обработки адресов должна быть подключена на сайте. Для этого необходимо:

Примеры правил и условий для модуля mod_rewrite

Поддержка компонентов 2.0

При добавлении на страницу компонента с поддержкой ЧПУ («человеко-понятный URL«) (если файл сохраняется с помощью API), автоматически создаётся правило обработки адреса. Если страница создаётся не с помощью API, а, например, записывается через FTP, то необходимо выполнить пересоздание правил (кнопка на панели инструментов на странице настройки правил обработки адресов).

Поддержка ЧПУ включается в компоненте с помощью предопределённого входного параметра SEF_MODE. При этом в предопределённом входном параметре SEF_FOLDER устанавливается папка, в которой работает компонент. Папка может быть виртуальной (т.е. физически может не существовать). При сохранении страницы с размещённым на ней компонентом, переключенным в режим ЧПУ (параметр SEF_MODE равен Y), через стандартный интерфейс правило обработки адресов создаётся следующим образом: в ключ условия применения шаблона («CONDITION«) записывается регулярное выражение, полученое из папки в параметре SEF_FOLDER, в ключ «ID» записывается имя компонента, в ключ пути («PATH«) записывается физический адрес страницы.

Источник

Список правил обработки адресов

Управление правилами преобразования адресов производится на странице Обработка адресов (Настройки > Настройки продукта > Обработка адресов).

Обработка адресов (UrlRewrite) применяется для того, чтобы скрипт мог отвечать не только по своему физическому, но и по любому другому указанному адресу. Например, можно задать такие настройки обработки адресов, что скрипт, лежащий в файле /fld/c.php и отвечающий по адресу /fld/c.php?id=15 будет отвечать также по адресу /catalog/15.php.

Адрес, по которому будет отвечать скрипт, не должен физически существовать на сервере. Если такой адрес физически существует, то будет вызван скрипт по этому адресу. Система обработки адресов запущена в этом случае не будет.

Фильтр

Форма фильтра используется для выбора из списка правил обработки в соответствии с указанными условиями. Нижеследующая таблица описывает параметры, по которым может выполняться поиск.

Поле Описание
Путь Поиск правила по пути к файлу.
Сайт Поиск правил для указанного сайта.
Условие Поиск правил обработки адресов по условию применения.
Компонент Поиск правил по полному имени компонента (пространство_имен:имя_компонента).

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

Контекстная панель

Кнопка Описание
Новая запись Переход к форме создания нового правила обработки адресов.
Пересоздание Переход к странице Пересоздание правил обработки адресов.
Настроить Переход к диалогу настройки внешнего вида отчетной формы.
Excel Экспорт данных из отображаемой таблицы в формат MS Excel.

Список правил

Смотрите также

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

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

Источник

Обработка адресов

Понятие обработки адресов

Обработка адресов (UrlRewrite) применяется для того, чтобы скрипт мог отвечать не только по своему физическому, но и по любому другому указаному адресу. Например, можно задать настройки обработки адресов, чтобы скрипт в файле /fld/c.php, отвечающий по адресу

отвечал также по адресу

Адрес, по которому будет отвечать скрипт, не должен физически существовать на сервере. Если такой адрес физически существует, то будет вызван скрипт по этому адресу. Система обработки адресов запущена в этом случае не будет.

Правила обработки

Правила обработки адресов настраиваются отдельно для каждого сайта и хранятся в корне сайта в файле urlrewrite.php. Файл содержит массив $arUrlRewrite, каждая запись которого является правилом обработки адреса. Файл urlrewrite.php имеет следующий вид:

Каждое правило должно содержать уникальное в рамках сайта условие выполнения правила. Условие выполнения записывается в ключ «CONDITION» массива и является шаблоном Perl-совместимого регулярного выражения. Например, условие:

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

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

и пользователь запросил страницу:

которая физически не существует, то система обработки адресов подключит скрипт:

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

и пользователем запрошена страница:

то для формирования адреса скрипта, который будет подключен, выполнится код:

и будет подключен скрипт:

Если в системе обработки адресов зарегистрировано правило:

и пользователем запрошена страница:

то для формирования адреса скрипта, который будет подключен, выполнится код:

и будет подключен скрипт:

Правило может содержать имя компонента, который создал это правило. Это имя записывается в ключ «ID«. При автоматическом пересоздании файла правил urlrewrite.php с помощью средств административной части сайта пересоздаются только правила, у которых заполнен ключ «ID«. Эти правила пересоздаются на основании анализа физических файлов в папке сайта. Правила с пустым ключом «ID» при автоматическом пересоздании файла правил не изменяются.

Подключение системы обработки адресов

Перед началом использования система обработки адресов должна быть подключена на сайте. Для этого необходимо:

Примеры правил и условий для модуля mod_rewrite

Поддержка компонентов 2.0

При добавлении на страницу компонента с поддержкой ЧПУ («человеко-понятный URL«) (если файл сохраняется с помощью API), автоматически создаётся правило обработки адреса. Если страница создаётся не с помощью API, а, например, записывается через FTP, то необходимо выполнить пересоздание правил (кнопка на панели инструментов на странице настройки правил обработки адресов).

Поддержка ЧПУ включается в компоненте с помощью предопределённого входного параметра SEF_MODE. При этом в предопределённом входном параметре SEF_FOLDER устанавливается папка, в которой работает компонент. Папка может быть виртуальной (т.е. физически может не существовать). При сохранении страницы с размещённым на ней компонентом, переключенным в режим ЧПУ (параметр SEF_MODE равен Y), через стандартный интерфейс правило обработки адресов создаётся следующим образом: в ключ условия применения шаблона («CONDITION«) записывается регулярное выражение, полученое из папки в параметре SEF_FOLDER, в ключ «ID» записывается имя компонента, в ключ пути («PATH«) записывается физический адрес страницы.

Например, пусть компонент «bitrix:catalog» размещён на странице /fld/c.php и его подключение выглядит следующим образом:

Тогда при сохранении страницы /fld/c.php в системе обработки адресов добавится запись:

Таким образом, при запросе адресов, начинающихся со строки /mycatalog/, будет подключаться скрипт /fld/c.php. В этом скрипте запрошенный адрес может быть проанализирован и выполнены требуемые действия.

Смотрите также

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

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

noavatar

Цитата
Борис Байзулаев пишет:
Адрес физического файла, подключенного в результате обработки адреса записывается в
Код
$_SERVER[«REAL_FILE_PATH»]

noavatar

noavatar

noavatar

av 1425

av3

eleph 130

Упрощенный вариант правила, решающий проблему, описанную Денисом Мальцевым в предыдущем комментарии.

noavatar

Одна интересная особенность, которую надо учитывать.

Допустим вам надо сделать преобразование такого вида, чтобы при открытии страницы /news/445.php происходило преобразование в /news/detail.php?ID=445
Можно использовать такое правило

Оно даже будет работать, но ровно до тех пор пока в строке не появятся дополнительные параметры. Например пользователь перешел с внешнего ресурса и в URL была добавлена метка для Google Analitics, запрошенный URL получился примерно такой /news/445.php?utm_source=google. Вместо текста новости вы увидите сообщение «Элемент не найден», потому что в результате преобразования получился такой адрес /news/detail.php?ID=445?utm_source=google.

Ниже приведен код, решающий эту проблему:

basyrov

Задача : Выполнить 301 редирект с одного домена на другой, чтобы любой адрес домена olddomain вёл на тот же адрес, но в домене newdomain.

Источник

Справочник по обустройству дома и дачи
Adblock
detector