Убрать get параметр из url 1с битрикс
Продолжаем лупить статьи на тему «Битрикс не так уж и плох, если его доработать».
На этот раз разговор пойдет на тему «url_rewrite», потому как я считаю, что текущий вариант вообще не идеален.
А идеальным я считаю вариант маршрутизации в микрофреймворках, например Slim (или тот же Lumen), вообщем тех, которые дружат с PSR-7.
Кому интересно, го под кат.
Кому не интересно, ну тут уж сами решайте ;-)
INTRO
На самом деле мои предыдущие статьи носили более менее абстрактный характер (ну кроме статьи про Juggernaut пожалуй), поэтому в данном посте постараюсь меньше писать теории и побольше кода.
Кстати про Juggernaut
- время
- рефакторинг
- мне полюбился TDD, так что рефакторинг остановился до тех пор пока не напишу тесты
- направление развитие библиотеки как оказалось я не совсем еще до конца определил
Но это как говорить «совсем другая история», поэтому вернемся к тому, о чем собственно данная статья: роутинг.
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 параметр page. Однако, текущий URL может быть уже с параметром page. В итоге, получится, например, такой URL: "/?page=5&page=7". Тогда как правильный должен быть: "/?page=7". Таким образом, необходимо сначала удалить параметр page, а уже потом скрипт создания навигации по страницам сделает своё дело.
Привожу сразу код функции, которая это делает:
<?php
function deleteGET($url, $name, $amp = true) $url = str_replace("&", "&", $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("&", "&", $url); // Заменяем амперсанды обратно на сущности, если требуется
>
else $url = $url_part; // Если параметров не осталось, то просто берём всё, что идёт до знака ?
return $url; // Возвращаем итоговый URL
>
echo deleteGET("http://mysite.ru/?view=category&page=5&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 (можете переписать на старый вызов колбека).
Да, хочу сразу предупредить - получилось не совсем универсально, я сделал только для PAGEN_1 (а есть еще PAGEN_2 и так далее), цифра в конце увеличивается при каждом новом вызове постранички на странице. Но это бывает крайне редко. И в этом случае ЧПУ-постраничка, как правило, одна.
Значит, шаблон красивый вывели
Алгоритм не накладывает требования на шаблон. Более того, вы можете взять и применить его на ваши текущие шаблоны. Старые PAGEN продолжат работать также.
Так, далее надо поместить в htaccess волшебную строчку в секцию IfModule mod_rewrite.c:
Остался последний штрих. Нам нужно GetCurPage и GetCurDir оставить неизменными, чтобы получилось абсолютно безболезненно (и незаметно) для Битрикс. Для этого мы делаем финт таким обработчиком:Вот собственно и вся магия. Комментарии подробные считаю излишними, разработчики разберутся.
Спросили - а как убрать PAGEN_, но не ЧПУ делать, а просто приятные параметры. К примеру, page=xxx. Тут все проще.
Читайте также: