Есть в Битрикс места, за которые местами стыдно. Одно из них - это ПОСТРАНИЧКА (оттакенными буквами, ага). Это даже отличительная черта Битрикс - PAGEN_ - все, Битрикс. Избавляемся от этого
Идея проста - мы буферизируем вывод шаблона system.pagenavigation (да, поработать ручками придется). В начале ставим ob_start();, в конце небольшие махинации с preg_replace, и на выходе имеем красивые ссылки. Но это пока только ссылки. Код я разбиратьне буду, скачать вы сможете его в конце сего поста. Замечу только, что внутри колбека можно вырезать ненужные get-параметры. Как вариант, эту обработку можно вынести в функцию, которую дополнять теми параметрами, которые вы хотите удалять постоянно. Место очистки отмечено красным. И еще момент - используется анонимная функция, что требует PHP минимум 5.3 (можете переписать на старый вызов колбека).
Да, хочу сразу предупредить - получилось не совсем универсально, я сделал только для PAGEN_1 (а есть еще PAGEN_2 и так далее), цифра в конце увеличивается при каждом новом вызове постранички на странице. Но это бывает крайне редко. И в этом случае ЧПУ-постраничка, как правило, одна.
Значит, шаблон красивый вывели
Алгоритм не накладывает требования на шаблон. Более того, вы можете взять и применить его на ваши текущие шаблоны. Старые PAGEN продолжат работать также.
Так, далее надо поместить в htaccess волшебную строчку в секцию IfModule mod_rewrite.c:
Остался последний штрих. Нам нужно GetCurPage и GetCurDir оставить неизменными, чтобы получилось абсолютно безболезненно (и незаметно) для Битрикс. Для этого мы делаем финт таким обработчиком:
AddEventHandler('main', 'OnPageStart', array('CMainhandlers', 'OnPageStartHandler'));
class CMainhandlers {
public static function OnPageStartHandler() {
$newUri = preg_replace('#(pagen[\d]+/)#is', '', $_SERVER['REQUEST_URI']);
if (!CHTTP::isPathTraversalUri($newUri)) {
$_SERVER['REQUEST_URI'] = $newUri;
$GLOBALS['APPLICATION']->reinitPath();
}
}
}
Вот собственно и вся магия. Комментарии подробные считаю излишними, разработчики разберутся.
UPD:
Спросили - а как убрать PAGEN_, но не ЧПУ делать, а просто приятные параметры. К примеру, page=xxx. Тут все проще.
Шаблон - все то же самое, кроме строчки
$newUrl .= 'pagen'.intval($v).'/';
ее меняем на
$arQuery['page'] = intval($v);
htaccess - вообще не трогаем.
Код обработчика - выглядит совершенно иначе:
public static function OnPageStartHandler() {
if (isset($_GET['page']) && intval($_GET['page'])>0) {
$GLOBALS['PAGEN_1'] = $_REQUEST['PAGEN_1'] = $_GET['PAGEN_1'] = $_GET['page'];
unset($_GET['page'], $_REQUEST['page'], $GLOBALS['page']);
}
$GLOBALS['APPLICATION']->reinitPath();
}
Антон, спасибо, хорошее решение, насколько я помню наличие PAGEN_2 итд зависит от наличия второго компонента с постраничкой на одной странице. PS: Битрикс уже осилил полный ЧПУ для инфоблоков, ток что может через пару лет, нас "из коробки" избавят от PAGEN_X
не очень удачный момент с этим: RewriteRule ^(.*)/pagen([\d]+)/ /$1/?PAGEN_1=$2 [L,QSA]
выходит по всему сайту можно сделать много дублей с pagen[\d] и сайт не будет возвращать 404ю ошибку для таких "ошибочных" страниц. Это правило нужно менее общим делать, только для тех разделов, где постаничка уместна.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».