Убрать get параметр из url 1с битрикс

Обновлено: 07.07.2024


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

INTRO

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

Кстати про Juggernaut

  1. время
  2. рефакторинг
  3. мне полюбился TDD, так что рефакторинг остановился до тех пор пока не напишу тесты
  4. направление развитие библиотеки как оказалось я не совсем еще до конца определил

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

UrlRewrite by Bitrix

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


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

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

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

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

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

process Url
Немного странные действия, но все же происходит следующее:
Если есть GET параметр SEF_APPLICATION_CUR_PAGE_URL, то приравниваем REQUEST_URI к его значению, а затем переписываем все зависимые переменные и глобальные массивы ($_GET, $_SERVER, …)

  • Парсим параметр CONDITION.
  • Заменяем параметр CONDITION на RULE в REQUEST_URI
  • Добавляет в $_GET и $_REQUEST переменные из правила маршрутизации.
  • Проверяем существует ли указанный файл, валидный ли у него путь и не является ли он административным (upload, bitrix, bitrix/services, bitrix/groupdavphp).
  • Если все ок, то подключаем.

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

UrlRewrite by Slim

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


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

UrlRewrite by Juhhernaut

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


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

Удаление GET-параметра из URL

В сегодняшней статье я решил разобрать весьма полезную функцию, удаляющую любой GET-параметр из строки. Где это может быть нужно? Допустим, Вы делаете навигацию по страницам. И Вам необходимо сделать универсальный скрипт её создания, добавляя к текущему URL параметр page. Однако, текущий URL может быть уже с параметром page. В итоге, получится, например, такой URL: "/?page=5&page=7". Тогда как правильный должен быть: "/?page=7". Таким образом, необходимо сначала удалить параметр page, а уже потом скрипт создания навигации по страницам сделает своё дело.

Привожу сразу код функции, которая это делает:

<?php
function deleteGET($url, $name, $amp = true) $url = str_replace("&amp;", "&", $url); // Заменяем сущности на амперсанд, если требуется
list($url_part, $qs_part) = array_pad(explode("?", $url), 2, ""); // Разбиваем URL на 2 части: до знака ? и после
parse_str($qs_part, $qs_vars); // Разбиваем строку с запросом на массив с параметрами и их значениями
unset($qs_vars[$name]); // Удаляем необходимый параметр
if (count($qs_vars) > 0) < // Если есть параметры
$url = $url_part."?".http_build_query($qs_vars); // Собираем URL обратно
if ($amp) $url = str_replace("&", "&amp;", $url); // Заменяем амперсанды обратно на сущности, если требуется
>
else $url = $url_part; // Если параметров не осталось, то просто берём всё, что идёт до знака ?
return $url; // Возвращаем итоговый URL
>
echo deleteGET("http://mysite.ru/?view=category&amp;page=5&amp;id=5", "page");
?>

Не очень сложный скрипт, однако, он выполняет весьма сложную задачу - удаление GET-параметра из URL. Ведь тут имеется огромное количество нюансов. Просто удалить строку - легко, но ведь нужно, чтобы исчез "?", если не осталось больше параметров. Нужно, чтобы исчез "&" перед удалённым параметром, но при условии, что он был не первый в строке запроса. Нужно, чтобы удалился & после параметра, но при условии, что он был не последний. Но при этом нельзя удалить сразу и спереди, и сзади амперсанд, иначе пострадают параметры до и после удаляемого. Видите, сколько нюансов, в казалось бы простой задаче? Данная же функция всё это учитывает.

Вот так можно легко удалить GET-параметр из URL, вызвав функцию из этой статьи.


Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

Комментарии ( 5 ):

Зачем такие сложности с разделением ссылки на 2 части? Есть же pparse_url

А ещё есть $_SERVER['QUERY_STRING']. Ну, это если сокращаемый URL и URL текущей страницы совпадают.

А еще есть strTok(), которая "отсекает" все вместе переданным токеном.

Делаем красивую универсальную ЧПУ-постраничку в Битрикс (а также выкидываем мусор из постранички)

:)

Есть в Битрикс места, за которые местами стыдно. Одно из них - это ПОСТРАНИЧКА (оттакенными буквами, ага). Это даже отличительная черта Битрикс - PAGEN_ - все, Битрикс. Избавляемся от этого

Идея проста - мы буферизируем вывод шаблона system.pagenavigation (да, поработать ручками придется). В начале ставим ob_start();, в конце небольшие махинации с preg_replace, и на выходе имеем красивые ссылки. Но это пока только ссылки. Код я разбиратьне буду, скачать вы сможете его в конце сего поста. Замечу только, что внутри колбека можно вырезать ненужные get-параметры. Как вариант, эту обработку можно вынести в функцию, которую дополнять теми параметрами, которые вы хотите удалять постоянно. Место очистки отмечено красным. И еще момент - используется анонимная функция, что требует PHP минимум 5.3 (можете переписать на старый вызов колбека).

2013_04_22_00_25_netbeans_ide.jpg

Да, хочу сразу предупредить - получилось не совсем универсально, я сделал только для PAGEN_1 (а есть еще PAGEN_2 и так далее), цифра в конце увеличивается при каждом новом вызове постранички на странице. Но это бывает крайне редко. И в этом случае ЧПУ-постраничка, как правило, одна.

Значит, шаблон красивый вывели

2013_04_21_17_43.jpg

Алгоритм не накладывает требования на шаблон. Более того, вы можете взять и применить его на ваши текущие шаблоны. Старые PAGEN продолжат работать также.

Так, далее надо поместить в htaccess волшебную строчку в секцию IfModule mod_rewrite.c:

Остался последний штрих. Нам нужно GetCurPage и GetCurDir оставить неизменными, чтобы получилось абсолютно безболезненно (и незаметно) для Битрикс. Для этого мы делаем финт таким обработчиком:

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

Спросили - а как убрать PAGEN_, но не ЧПУ делать, а просто приятные параметры. К примеру, page=xxx. Тут все проще.

Читайте также: