Модуль комментариев под Битрикс
 

Документация

Логика привязки обсуждения к адресу

Каждое обсуждение привязывается к адресу страницы (урл), который является её наиболее уникальным идентификатором. Так как администрирование в Битриксе производится с помощью дополнительных ключей, реальный урл возможно получить только путём чистки мусорных ключей. Этот набор ключей уже задан в настройках модуля, подробнее о них и принципе определения реального адреса страницы читайте в секции «GET-ключи» документации про параметры модуля.

Итак, у нас есть реальный урл страницы. Когда компонент только размещён и ещё нет ни одного комментария — ничего в инфоблоке не создаётся. Когда на странице уже есть обсуждение, комментарии записываются в разделы конкретного инфоблока по следующей логике: разделы первого уровня — урлы страниц, к которым они привязаны, все вложенные в этот раздел подразделы — комментарии. Элементы разделов были зарезервированы для голосов при голосовании, но уже во второй версии модуля мы отказались от поддержки голосования — оно оказалось практически не востребованным, как мы предполагали вначале. Если среди наших клиентов будет массовый запрос на механизм голосования, мы возобновим разработку и «голоса» как раз будут храниться в элементах инфоблока.

Использование инфоблоков и такая их структура крайне удобна: для инфоблоков в административном разделе целый набор инструментов, стандартное API, с помощью которого комментарии при необходимости и перепарсиваются и переиндексируются и вообще — что угодно с ними можно делать. Технические особенности инфоблоков и разделов для модуля описаны здесь.

Если нужно вывести последние комментарии, например, — используем стандартный компонент в поставке Битрикса «Контент / Каталог / Разделы с top'ом элементов (bitrix:catalog.sections.top)». Разделы сортируем по дате или ID по-убыванию, берём все разделы кроме разделов первого уровня.

Использование разделов первого уровня в качестве привязочного урла имеет свои дополнительные преимущества. Представим, что обсуждение переезжает в другой раздел (на моей практике это случалось уже несколько раз), например: библиотека со статьями переезжает из папки на поддомен или наоборот. И все урлы статей меняются с http://www.site.ru/topic/4445/ на http://library.site.ru/4445/. Достаточно с помощью стандартного API Битрикса перепарсить названия разделов первого уровня и вот, пожалуйста: обсуждение переехало на новые урлы.

Чтобы у читателя было полное понимание механизма привязки осуждений, отмечу, что привязка комментария не одноуровневая, как может показаться вначале — по урлу, а двухуровневая: урл+инфоблок. То есть, если мы разместим на одной странице два компонента, у одного укажем собирать комментарии в Инфоблок-01, а другому — в Инфоблок-02, это будут разные обсуждения. Если комментировать через ветку в первом компоненте — обсуждение будет накапливаться в Инфоблоке-01, а во второй комментарии не будут идти. И наоборот.

Где это может быть полезно? К примеру, на сайте активно ведутся работы по наполнению контентом или программированию. И специалистам по техническим работам необходима удобная и привязанная «к месту» система обсуждения-уточнения, видимая только им. Тогда в сквозном блоке через весь сайт с ограничением доступа запускается техническая ветка обсуждения. Когда на страницу смотрит пользователь «не модератор», он видит лишь обсуждение новости, но когда страницу открывает администратор, он видит дополнительное обсуждение и может дать свои замечания или комментарии по странице. Например: «нужно здесь разместить форму» или «подтянуть текст» или что-то исправить в интерфейсе. Программист получает уведомление, в котором адрес страницы с замечанием, может перейти на неё, ознакомиться с текстом и продолжить диалог с администратором, уведомить про выполнение.

Ещё один пример — если отдельное обсуждение использовать в качестве формы обратной связи. Размещается где-то в боковой колонке или в подвале сайта в сквозной по всему сайту включаемой области. Тогда на странице с новостями будет публиковаться два «обсуждения»: комментарии к самой новости и форма обратной связи. Чтобы второе обсуждение не публиковало сообщения на странице, в настройках компонента указываем, что все новые комментарии публиковать неактивными. Таким образом, пользователь может отправить сообщение, которое уведомлением поступит менеджеру, но на странице не отобразится.

Модуль разработан так, чтобы можно было максимально удобно интегрировать обсуждение под любые нужды. Одним из требований, которые диктуют реалии — необходимость иметь связь с окружением, например: чтобы обсуждение, размещённое на странице со статьёй, уведомляло автора про комментарий или чтобы приходило уведомление менеджеров по работе с клиентами о новом отзыве. Подобие подписки на обсуждение. Для этих случаев существуют специальные переменные, значения которых отслеживает модуль.


Get-ключи

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

/news/777/
/library/topic/45/
/user/4/notebook/

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

/news/777/?lang=ru&mid=itape&mid_menu=1
/library/topic/45/?bitrix_include_areas=Y
/user/4/notebook/?show_page_exec_time=Y&show_sql_stat=Y&bitrix_include_areas=Y

В результате урлы другие, но фактически страницы те же. Чтобы и в этих ситуациях на странице отображалось актуальное обуждение, эти «мусорные» ключи нужно чистить. Чтобы глядя на страницу:
/user/4/notebook/?show_page_exec_time=Y&show_sql_stat=Y&bitrix_include_areas=Y
модуль полноценных комментариев всё-равно понимал её как
/user/4/notebook/

В настройках модуля по умолчанию собраны все известные мне на данный момент мусорные ключи.

Однако есть существенное замечание! Если ваши страницы работают не на ЧПУ, в дополнительных параметрах к запросу могут быть важные переменные, которые отвечают за уникальность каждой страницы. Например, детальные страницы новостей могут выглядеть так:

/news/detail.php?ELEMENT_ID=45
/news/detail.php?ELEMENT_ID=74
/news/detail.php?ELEMENT_ID=76
/news/detail.php?ELEMENT_ID=98
/news/detail.php?ELEMENT_ID=112

Так их видят пользователи, так их видят поисковики и дополнительный параметр ELEMENT_ID является обязательной частью урла. Чтобы все эти урлы модуль не вычистил в один: «/news/detail.php», нужно проследить, чтобы в настройках модуля в списке GET-ключей на чистку отсутствовал «ELEMENT_ID». Тогда урлы будут распознаваться модулем так, как вам нужно.

Стоит также иметь в виду, что в каждом размещённом компоненте можно указать дополнительные ключи на чистку для конкретного обсуждения. Пожалуйста, не забывайте, про особенность размещения компонента в сквозных включаемых областях или на страницах, формирующих типовые динамические страницы (например, детальные страницы новостей): компонент размещается один, и его параметры действуют на все страницы, которые затрагивает включаемая область или типовая страница.

Ещё одну ситуацию опишу, чтобы дать понимание про использование дополнительных ключей в параметре компонента. Предположим у вас есть раздел «Вопрос-ответ»: /ask/

Внутри него есть рубрикатор, который настроен так:

/ask/?TOPIC_ID=3
/ask/?TOPIC_ID=7
/ask/?TOPIC_ID=15

Накапливание новых вопросов происходит так: пользователи просматривают рубрики и если не нашли ответ, в обсуждении, которое даётся тут же, задают свой вопрос. Менеджер отвечает на вопрос, обсуждает разные уточнения и если вопрос оказывается важным, его выносят в рубрикатор, дают полноценный ответ а конкретную ветку из обсуждения чистят. В этом случае нужно, чтобы обсуждение было общим для всех вложенных страниц рубрикатора. Чтобы на любой странице пользователь мог просмотреть обсуждение и задать свой вопрос, если его нет там.

Чтобы этого добиться, нужно, чтобы компонент каждый урл

/ask/?TOPIC_ID=3
/ask/?TOPIC_ID=7
/ask/?TOPIC_ID=15

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

Читать дальше: Технические особенности