Неприятно когда красивый вид ЧПУ-ссылок на вашем сайте портит огромный PAGEN_N. Вот как от этого можно избавиться. [spoiler] Можно конечно подумать как все это дело сделать универсальным, но есть ряд моментов, который легко можно не учесть и полезут глюки. Так что рассмотрим просто отдельный компонент (раздел). И попытаемся сделать постраничку вида index{1,2,3,...}.php
Есть, допустим новости. Переходим в раздел новостей (адрес /content/news/) и кликаем на какую-либо страницу, чтобы узнать формат PAGEN_. Видим что-то типа PAGEN_1 (а также может быть и PAGEN_2 / PAGEN_3).
Переходим в "Рабочий стол / Настройки / Настройки продукта / Обработка адресов", добавляем новое правило:
В "правило" как раз и меняется наш PAGEN_N (вместо единички может быть двойка, и так далее).
Осталась мелочь - в /bitrix/templates/.default/components/bitrix/system.pagenavigation/ копируем этот шаблон. И в настройках компонента новостей ставим имя шаблона навигации ufu. Все должно работать.
При желании вы можете подправить и другой шаблон постраничной навигации под формат ЧПУ, но занятие это нудное. Да, еще, при включении обратной постраничной навигации ЧПУ выглядят довольно нелогично (наоборот).
Повторюсь - компонент лишь пример, заточенный в лоб. Может быть его поведение не всегда вас устроит.
А как вы откомментировали запись? Без JavaScript вы бы это не сделали.
Далее. Какая практическая польза от блокирования JS? Если браузер не оснащен разного рода фишками (типа "прекратить использование javascript после второго alert", или "страница пытается загрузить файл/frame"), тогда да, нужны эти, скорее заглушки.
Ну а счетчик в миллионы загрузок расширения: - веб-мастеры, львиная доля, чтобы отлаживать сайты под "тех, кто не использует JS" (бога ради, без обид) - реально олдскул, кто ностальгирует по 90-м, когда сайты грузились пока дымится сигарета - и те и другие, кто переустанавливает браузер/ОСь
Давайте, коллеги, лучше тратить время на создание красивых и удобных веб-приложений, чем тратить время на поддержку веб-приложений на случай "если отключен JS" (как вот данное окошко комментов, например).
PS: Если сможете дать реальный аргумент в защиту блокирования JS (при постоянном серфинге) скажу спасибо.
И вы доверяете блокировщику JS, что он не пропустит заразу (точнее его производителю), но не доверяете антивирусу, который попросту не даст запуститься пропущенному трояну?
Вы также постоянно думаете, можно ли доверять какому-то сайту на разрешение исполнения JS?
Я просто пытаюсь понять философию "я отключаю JS".
Кстати, реальный случай очень хорошо посещаемого сайта (которому явно много доверяли на исполнение JS). Один из редакторов сделал выход по FTP с компа, полного троянов.
Так что, "кирпич на голову может и дома упасть" (с).
ну да, так и есть, блокировщику доверяю, антивирусу нет. Это не есть какое-то постоянное думание, напряжение мозгов и прочее.. я много лет так делаю, привык, все на автопилоте и как можно жить по другому просто не представляю.
ну на кирпич закладываться, конечно, перебор, а вот представление хотяб начальное о том, как фунциклирует отрасль, есть. Т.е. то, что есть в антивирусах, это..как бы сказать.. уже "третий передел". Сначала эксплойт эксплуатируется в один ствол, кто сделал - тот и снял сливки. На втором этапе продается за огромные тыщщи скажем десятку "бизнесменов", снимают свои сливки. Ну а по прошествии года/лет уходит "в паблик".. вот тут то и подключаются антивирусы. Как-то так имхо..
Мы реализуем ЧПУ "постранички" способом аналогичным описанному Антоном. Только еще обратную навигацию включаем, чтобы в глазах поисковиков элементы не прыгали со страницы на страницу. То есть, если элемент появился на /page1.html то он всегда уже будет на ней находиться, в отличии от прямой навигации. В комплексном компоненте каталога осталось два компонента без ЧПУ -- "постраничка" и фильтр.
Что то я не очень понял смысл этой "обратной навигации" Расскажите что это и с чем едят? в справке непонятно принцип описан. PS попробовал включить у себя обратную навигацию у компонента news.list так он стал на 1й страничке показывать вместо 4 элементов (ограничение стоит 4 - элемента на странице) - 7 штук аж..
Это нужно для снижения нагрузки на сайт, путем как можно дОльшего кеширования ленты новостей (в частности).
При обычном методе кеширования после добавления каждого элемента идет перестраивание всей ленты. Фактически по слепку кеша на каждую страницы ленты.
В методе обратной постранички применяется хитрость. Первая страница выступает неким буфером, куда накапливает 1.5 (полторы) страницы новостей), и только после этого идет перестройка всей ленты новостей.
Это актуально при очень большом количестве элементов в ленте (и частом их добавлении). Хотя мне, как и Роману, этот метод не нравится в силу скачков элементов. Бывает что проще вообще кеш на ленте отключить, пусть с базы постоянно тягает, чем файлы мучать.
Хоть я и несовсем понял смысл этого дела, но в документации написано что меняется только 1я страничка при обратной навигации, а остальные страницы кэшируются. Допустим: 1 у нас есть 4 страницы: pagen_1=1 pagen_1=2 pagen_1=3 pagen_1=4 2 на каждой странице выводятся максимум 10 элементов 3 всего мы имеем 37 элементов 4 если включена обратная постраничка, тогда на pagen_1=4 будет выводиться 10 элементов а на 1й - 7, и наоборот - если отключена - то на 1й 10 а на последней - 7. 5 если включена, то получается если мы добавим новый элемент инфоблока, то он добавится на 1ю страницу, и обновится только кэш 1й страницы.
т.о. получается что старые элементы все остались на своих местах в своих страничках и новый добавленный не сдвинул их.
Но мне непонятно, при включенной обратной навигации получается что кэш компонента уже не работает или как?
и не понимаю почему при отключенной обратной навигации у меня на 1 страницу меньше получается чем с включенной и на 1й странице элементов выводится больше указанного количества максимального
Понятно) я так и думал. Но почему именно 1.5 (полторы) страницы новостей? ведь это не комильфо когда на всех страничках скажем по 10 новостей а на 1й - 14. Ладно бы если количество было меньше указанного, но когда уже больше - не очень хорошо. Можно ли это где-то настроить через ПУ? При включенной обратной навигации получается ее кэш уже играет роль кэша компонента? Кэш компонента ведь в таком случае уже не нужен?
Мне, кстати, нравится режим обратной навигации для постранички. Стараюсь его всегда включать, так как это полезно и в плане кэша и в плане SEO. Смысл в том что, по идеи, если элемент появился на странице , к примеру на /index.php?PAGE_1=1 то он уже всегда будет на ней оставаться, а значит переходы по запросам с поисковиков всегда будут попадать точно в цель. В случае же прямой навигации посетители часто переходят на траницу где искомого элемента уже давно нет.
Это по идеи, а в реализации этого дела в Битрикс есть изъян -- один раз все же жлемент сменит свой адрес (о чем рассказал Антон). Писал об этом в ТП и вот что она ответила:
Мы полагаем, что количество сообщений на первой странице при обратной постраничной навигации должно бють "плавающим", но - в разумных , по нашему мнению, границах. Если не ошибаюсь, речь идет от N до N+N*0.5 элементов списка.
Иного механизма реализации постраничной навигации мы пока не планируем реализовывать.
Роман, если у Вас есть своя точка зрения по этому вопросу, и Вы считаете, что наша точка зрения - ошибочна, лучше поднять данный вопрос на форуме, т.к. он явно не относится к компетенции техподдержки.
До сих пор (в течение нескольких лет) мы еще не сталкивались с негативным мнением относительно реализации алгоритма обратной постраничной навигации, что, как мы считаем, говорит в пользу выбранного решения.
Думал что меня одного это напрягает оказывается что нет
Они не сталкивались, потому что народ в большинстве своем этим и не интересуется... обычно стандартных "штук" хватает без всяких "фич"... и я вот тоже только недавно начал вкуривать всю эту тему. Эти чтуки на самом деле идейно клевые, но отсутствие их гибкой настройки и подробного мануала отталкивает... Роман, если не сложно, ответьтье на мои вопросы, обозначенные выше. Уж очень это интересно, а у вас, как я вижу, есть опыт в подобных делах.
Но мне непонятно, при включенной обратной навигации получается что кэш компонента уже не работает или как?
Должен работать. Включите режим отладки и посмотрите есть ли у компонента запросы к БД.
и не понимаю почему при отключенной обратной навигации у меня на 1 страницу меньше получается чем с включенной и на 1й странице элементов выводится больше указанного количества максимального
В случаем 37 элементов по 10 на странице -- количество страниц должно быть одинаковое и при прямой и при обратной. В вот в случае если бы элементов было к примеру 34, то при обратной навигации страниц было бы только 3-и, а не 4-е как при прямой: PAGE1_=1 - 10 элементов PAGE1_=2 - 10 элементов PAGE1_=3 - 14 (!) элементов (четвертая страница появится когда элементов на данной странице наберется более чем n*0,5 -- т.е. 16. Это-то мне и не нравится.)
PS: Про 0,5 не уверен, говорю со слов ТП (которая тоже не уверена) может там и другое значение -- надо в исходниках посмотреть
к сожалению (счастью?) это интернет-магазин. Не представляю что он мог бы продавать при такой тематике... (js???) Поэтому он торгует детскими игрушками... Если предположить, что игрушки через инет закупают домохозяки, то странно что в стандартный настройках браузера у них выключена ява... С другой стороны более 50 уников в сутки и все роботы?.. =)
Это отключена Java - т.е. нет возможности запускать всякие доп.приложения типа Банк-Клиентов. А вот java-script у них включен, иначе по-моему их и гугловский счетчик, который тоже java-script, не посчитал бы.
PAGE1_=3 - 14 (!) элементов (четвертая страница появится когда элементов на данной странице наберется более чем n*0,5 -- т.е. 16. Это-то мне и не нравится.)
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».