[Plugin] Comlist

Добрый вечер. Интересный плагин. Расскажите как в нем реализовано кэширование.

Понятно. А для чего поиск пробелов в имени записи кэша?

Спасибо за плагин, все замечательно работает. Один главный вопрос: если включаю аякс, пропадает разметка паджинатора. Я изначально переопределяю ее через ресурсы, и при формировании страницы она выводится нормально. Но при аякс-переходе моя разметка теряется, и используется дефолт. Как это исправить?

К вопросу о реализации вывода в зависимости от группы пользователя.

Как это можно сделать

Прежде всего, структура таблицы cot_com:

/* Comments schema */

-- Main comments table
CREATE TABLE IF NOT EXISTS `cot_com` (
	`com_id` int UNSIGNED NOT NULL auto_increment,
	`com_code` varchar(255) NOT NULL,
	`com_area` varchar(64) NOT NULL,
	`com_author` varchar(100) NOT NULL DEFAULT '',
	`com_authorid` int UNSIGNED NOT NULL,
	`com_authorip` varchar(64) NOT NULL DEFAULT '',
	`com_text` text NOT NULL,
	`com_date` int UNSIGNED NOT NULL DEFAULT '0',
	`com_count` mediumint UNSIGNED NOT NULL DEFAULT '0',  -- Not using anywhere
	`com_isspecial` tinyint UNSIGNED NOT NULL DEFAULT '0',
	PRIMARY KEY (`com_id`),
	KEY (`com_area`, `com_code`)
);

Как видим, привязка к объекту идет через условную зону (com_area) и код / ID объекта (com_code). Это означает, что для страницы, например, это может, например, быть page и 20 соответственно, т. е. страница с ID 20. Даже привязка к разделу не предусматривается (я этот вопрос обсуждал с Алексом, но решили что это излишняя информация).

И не забываем о том, что комментарии могут привязываться не только к страницам, но и к разделам и любым другим объектам. 

Также не забываем и то, что групп у пользователя может быть несколько. И права доступа в Cotonti реализуются не на уровне конечных объектов (страниц), а на уровне разделов, в которых они размещаются.

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

Надо ли это делать?

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

В любом случае, указание группы пользователя – не лучший вариант. Скорее в расширении необходимо реализовывать функционал, ограничивающий любому пользователю доступ к любой выводимой информации в соответствии с его правами в системе. А это, к слову, сразу же убьет возможность кэширования.

В данном конкретном случае проще будет все же использовать логику в шаблоне типа:

<!-- IF {PHP.usr.maingrp} == 1 -->
...
<!-- ENDIF  -->

<!-- IF {PHP.usr.maingrp} == 2 -->
...
<!-- ENDIF  -->

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

Если не хочется все это конструировать в шаблоне, можно выводить переменную или даже TPL-тег, который будет сформирован по той же логике, но уже через PHP-код из проектного плагина.

Если я правильно понимаю, твоя задача состоит в том, чтобы:

• для админов и ВИП-группы выводить все комментарии,
• для простых пользователей применять режим “черного списка”.

Небольшим плагином можно сформировать волшебную переменную $viewAllComments и с ее помощью разделить вывод простым способом:

<!-- IF {PHP.viewAllComments} === true -->
// Стандартный вызов sedby_comlist()
<!-- ELSE -->
// Вызов в режиме черного списка
<!-- ENDIF -->

Просто и доступно. И никаких последствий. Я видал конструкции и похлеще.

В качестве альтернативы хуком comments.send.new добавлять в экстраполе комментария признак, с помощью которого формировать запрос. Вообще все просто.

В самой функции sedby_comlist() есть хук для того, чтобы модифицировать SQL-запрос. Пробуй.

Есть еще пара более сложных вариантов, но и трех уже достаточно для того, чтобы за 15 минут или чуть более решить твой вопрос. На оставшиеся деньги – вместо рефлексирования – можно сделать что-то полезное для коммьюнити или для своего сайта. Но мы делаем то, что привыкли делать. К сожалению.

Если в плагине [на твой взгляд] косяк, а его автор не спешит его исправлять, удаляй его все к чертям. Попробуй Wordpress, Drupal, Joomla или что-нибудь более прогрессивное, чем Котонти. Там [наверно] тоже можно плеваться на разрабов и раздавать свои оценки их работе. Прямо как это принято в нашем коммьюнити. А когда @#па заживет, возвращайся к Котонти. Тоже знакомо.

P.S. {PHP.usr.maingroup} – это не тег, а элемент массива $usr. Доступ к нему в функции можно получить без проблем. Проблема шире, и я описал все выше. Выполнимо? Возможно. Но вопрос в том, стоит ли мутить все это ради единственного проекта. В остальных проблем-то нет. Котонти именно так и устроена – всем типовое, которое при желании можно расширить. Если ты промахнулся и вместо форумов решил использовать комменты, корежить коробочный плагин или всю систему доступов в движке из-за этого вряд ли стоит.

P.P.S. Одна ветка – одна истерика. Больше здесь нельзя.

Твоя задача состоит в том, чтобы решать проблемы быстро и просто, а не возбуждаться на якобы “возрастающее количество групп”.

Костыль был во времена LDU, когда для каждой страницы настраивалась система доступов. Возможно и для комментариев. Почему от этого ушли? Потому, что нерационально: предположу, что конфиги в БД раздувались сверх меры для многостраничных сайтов. Система прав для разделов компактнее, проще и – поэтому – эффективнее. Хочешь реализовать свой вариант – никто за уши не держит. Пиши плагин и делись им с коммьюнити.

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

По поводу всех ушедших всепропальщиков: не видел я ни одного сообщения о том, что на WP или J! люди добились чего-то большего, чем на Cotonti. Так что вывод простой: да, народ ушел, но не на другие движки, а в менеджеры среднего звена продавать автопокрышки. И дело здесь далеко не в Котонти. Больше всего сайтов я сделал именно во время исхода, когда “ковыряльщики” сыпали проклятия в адрес девтима за отсутствие обновлений.

И вообще, по поводу альтернатив: в самом-то деле, ты проверь что у них там с комментариями. И, хотя бы теоретически, можно ли на том же WP сделать то, что мы без каких-либо проблем вообще сделали на Котонти? А может там есть хоть один плагин с разделением прав на просмотр комментариев? Тогда или везде косяки или гранаты не той системы.

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

Последнее:

1. Создаем экстраполе com_usermaingrp в таблице комментов
2. Пишем $usr[‘maingrp’] в данное экстраполе через хук comments.send.new
3. Вывод комментов через

   {PHP.usr.maingrp|sedby_comlist(‘comlist’, 5, ‘com_date DESC’, ‘com_usermaingrp = $this’)}

4. Реализация за 15 минут.

Дальше все удаляю.