Превратите тему Discourse в журнал с одним автором и множеством читателей, где один пользователь может публиковать записи, а другие оставлять комментарии
Сначала включите ведение журналов для категории в настройках категории. Нажмите «Настройки» слева, прокрутите вниз до самого низа, отметьте галочкой «Включить ведение журналов в этой категории», нажмите «Сохранить категорию» и обновите страницу. Теперь кнопка «Создать тему» в категории будет отображаться как «Создать журнал» — нажмите её, чтобы создать свой первый журнал.
Спасибо за публикацию! Из нашего практического опыта, формат категорий «журнал/дневник/лог» — одна из самых мощных категорий, которую вы можете добавить в своё сообщество.
Мы с нетерпением ждём дальнейшего развития плагина.
В Discourse нет механизмов отключения плагинов, как в WordPress, поэтому это не произойдет автоматически. Однако в настройках категории есть кнопка, которая позволяет восстановить порядок публикаций в категории. Таким образом, пока плагин активен, вам нужно будет:
Несколько идей для возможного будущего обновления v2.0 плагина «Журнал». Рассматривайте это как свободное обсуждение, а не как официальные запросы на новые функции. Я просто хочу обсудить их публично и узнать мнение других пользователей.
Улучшенный или альтернативный «движок» комментариев
Вместо обычных постов комментарии (то есть ответы на записи журнала) должны работать аналогично плагину голосования за посты. Здесь стоит упомянуть Facebook, где опыт комментирования является одним из лучших примеров.
Вопрос в том, должны ли такие комментарии учитываться в показателях активности пользователя и вообще стоит ли их учитывать.
Также это позволит избежать багов в ленте времени, когда в ней учитываются только посты владельца темы.
Предложение/черновик спецификации:
Использование движка голосования за посты для комментариев
Комментарии не учитываются в показателях активности (возможна настройка включения/выключения в плагине)
Отображение уменьшенной аватарки и имени пользователя рядом с комментарием (но скрытие значков статуса аватарки)
Общие журналы (скорее приятное дополнение)
Это скорее идея на будущее и не является критически важной. Однако некоторые пользователи просили возможность создания тем журнала с двумя владельцами темы. Вопрос в том, насколько это вообще реализуемо?
Идеи для спецификации:
Владелец темы может добавлять соавторов
Соавтор может создавать новые записи журнала
(если это реализуемо) аватарки владельца темы и соавтора отображаются друг над другом в списке тем
Я рекомендую одно улучшение для этого замечательного плагина! Кнопка комментариев должна быть более заметной. Например, в разделе «Реакции» её вообще не видно, если не прокрутить горизонтально. Поскольку это новая функция, с точки зрения UI/UX я бы разместил кнопку комментариев в более заметном месте.
Просто для уверенности… Я не разрешаю мега-темы, и после 50-го поста тема должна закрываться, а создаётся новая.
Такие автоматически созданные темы принадлежат системе, поэтому мне нужно изменить владельца, верно?
В моём случае ограничение в 50 постов всё ещё действует, и поскольку «Журнал» — это просто тема на стероидах, даже комментарии к записям учитываются в лимите 50, потому что технически они являются комментариями к посту, когда записи — это комментарии к теме, верно?
Это больше относится к Discourse, но могу ли я изменить комментарий, который сейчас является записью, чтобы он стал комментарием к записи? В интерфейсе я не нашёл такой опции. Если мне придётся использовать Rails, то я не буду этим заниматься. Слишком много хлопот из-за такой мелочи.
У меня много тем типа «Журнал», и я перенёс их в эту систему, но все комментировали саму тему, и теперь они отображаются как записи. Ну, старая тема и несколько новых участников даже читают их, и я совершенно уверен, что им всё равно, как отображается контент.
Спасибо за плагин! Я начал использовать его не так давно, но у него было ощущение «заброшенности», поэтому я сомневался в нём. Однако, похоже, он работает отлично! (Вот пример его использования, я изменил CSS, чтобы скрыть детали и упростить внешний вид)
Единственное, что я бы очень рекомендовал улучшить, — это то, как он прокручивается к новым комментариям при повторном открытии темы. Трудно объяснить, но иногда это работает нестабильно/непонятно, где находятся новые комментарии, когда вы догоняете обсуждение.
Можете ли вы уточнить этот момент? Вы считаете, что они должны быть идентичны?
Обратите внимание, что плагин голосования за посты изначально был плагином «Вопрос-ответ», от которого был отделён плагин «Журнал» (см. далее). Приведение его в соответствие с изменениями в комментариях в плагине голосования за посты выполнимо.
Интересно. Не уверен, является ли это проблемой этого плагина или самого меню поста, но да, это нужно решить. Это на мобильном устройстве или на компьютере? Какой браузер используется?
хм, интересная у вас система. Ответ зависит от того, как вы настроили автоматическую систему разделения тем. Записи отличаются от комментариев на основе наличия у поста атрибута reply_to_post_number, то есть
Что ж, я использую стандартную функцию ядра, так что, вероятно, ничего не буду менять. Как обычно
Я просто пытаюсь понять, что будет в будущем. Но если я правильно понял, записи учитываются в пределе максимального количества постов, а комментарии — нет. Если так, то это прекрасно.
Внезапно, но не по теме: принято ли вообще создавать мега-темы Их ужасно читать новым участникам, а старым — трудно найти что-то нужное. Теперь я начинаю понимать, почему функция краткого содержания так востребована. Неизбежно, что мега-темы приведут к бесконечным повторениям и большому количеству отклонений от темы.
На данный момент в лимит засчитываются и записи, и комментарии. Возможно, я смогу настроить так, чтобы учитывались только записи. Но мне нужно будет изучить этот вопрос подробнее.
Я начинаю терять концентрацию и задаю вопросы уровня «101», но если posts.where и posts.where.not делают одно и то же, то в чём тогда разница? Хотя я предполагаю, что nil был просто примером, а на самом деле используется реальное значение
В любом случае. Этот вопрос о ограниченной длине не является критичным, так что, если захотите, посмотрите его, когда вам будет скучно и не будет ничего более важного. Потому что в какой-то момент я сам разберусь, как это работает в реальной среде.
означает посты, у которых reply_to_post_number равен nil, то есть это посты, не являющиеся ответами на другие посты (то есть это вступительные сообщения).
posts.where.not(reply_to_post_number: nil)
означает посты, у которых reply_to_post_number не равен nil, то есть это посты, являющиеся ответами на другие посты (то есть комментарии).
В любом случае, вам, вероятно, не стоит беспокоиться о запросах Rails. Я сообщу вам, если мы добавим поддержку исключения комментариев из автоматического разделения тем в ядре.
Привет, @angus, большое спасибо, очень ценю. Мне удалось найти дополнительные настройки при создании категории, и теперь всё работает как ожидалось. Ещё раз спасибо за ваше дополнение и работу над этим отличным плагином
Всем привет, сейчас прорабатывается техническое задание для этого плагина. Если вы заинтересованы в расширении или использовании этого плагина и хотите узнать больше, пожалуйста, отправьте мне сообщение на coop.pavilion.tech.