 |
摘要 | 将 Discourse 主题转换为一对多的日志，其中一个用户可以发布条目，其他用户可以评论 |
21 个赞
感谢发布！根据我们的实际经验，日记/日志类别是您可以添加到社区中最强大的类别之一。
我们期待该插件的进一步发展。
4 个赞
它只在类别级别上起作用，而不是通过标签起作用？
如果插件被停用，评论会恢复到正常位置吗？
2 个赞
目前是这样。
Discourse 没有像 Wordpress 那样的插件禁用钩子，所以它不会自动发生，但类别设置中有一个按钮可以让您将类别中的帖子恢复到正常顺序。因此，虽然插件仍然启用，但您将：
- 在类别中禁用日志功能。
- 将帖子恢复到正常顺序。
- 禁用插件（如果您想这样做）。
5 个赞
为日记插件可能的 v2.0 版本提供一些潜在的改进点。请将此视为头脑风暴的想法，而非实际的功能请求。我只是想把它们公之于众，看看其他用户怎么想。
更好的或不同的评论“引擎”
评论（又名对日记条目的回复）应该像帖子投票插件中的那样工作，而不是常规帖子。不得不引用老大哥 Facebook，那里的发帖评论体验是最好的例子。
问题在于这些评论是否计入用户活动，或者是否应该被计算在内。
这样一来，时间线也不会像现在这样有 bug，因为它只计算主题所有者的帖子。
规格建议/草案：
- 帖子投票评论“引擎”
- 评论不计入活动（可能是插件的开关设置）
- 在评论旁边显示半尺寸的用户头像和用户名（但隐藏头像的装饰）
共享日记（更像是“有也挺好”）
这有点牵强，也不是非常关键。但我们有一些用户要求日记主题，而你基本上有两个主题所有者。问题是它在第一位有多可行？
规格想法：
- 主题所有者可以添加合著者
- 合著者可以创建新的日记条目
- （如果可行）主题所有者和合著者的头像在主题列表中堆叠显示
1 个赞
我建议对该插件进行一项改进（它很棒！）。评论按钮应该更明显，例如在使用 Reactions 的情况下，除非水平滚动，否则按钮甚至不可见。由于这是新功能，为了 UI/UX 目的，我会将评论按钮以清晰可见的方式放置。
1 个赞
为了确保万无一失……我不允许巨型主题，在第 50 篇帖子之后，该主题将被关闭并创建一个新主题。
- 这种自动创建的主题归系统所有，所以我必须更改所有者，对吗？
- 在我的例子中，50 篇帖子的限制仍然有效，而且因为 Journal 只是一个“加强版”的主题，即使是条目的评论也计入 50 篇帖子的限制，因为从技术上讲，当条目是主题的评论时，它们就是帖子的评论，对吗？
这更多是 Discourse 的领域，但我能否更改一个现在是条目的评论，而不是条目的评论？我在用户界面中找不到这样的选项。如果我必须使用 rails，那我就不 bother 了。因为这样的小事太麻烦了。
我有很多日记类型的主题，我将它们更改为此系统，但每个人都评论了主题，现在它们显示为条目。嗯，旧主题和一些新成员甚至会阅读它们，我完全确定他们不在乎内容是如何显示的。
1 个赞
谢谢你的插件！我刚开始使用它不久，但它有一种“被遗弃”的感觉，所以我不太确定。不过它似乎运行良好！（这里有一个使用它的例子 ，我已经修改了 CSS 来隐藏细节并简化外观）
我认为唯一可以强烈推荐改进的地方是当你重新访问主题时，它跳转到新评论的方式。这很难解释，但有时当你赶上进度时，它会显得卡顿/不清楚新评论在哪里。
3 个赞
您能在这方面更具体一些吗？您认为它应该完全相同吗？
请注意，帖子投票插件最初是问答插件，而日志插件是从问答插件分离出来的（见下文）。将此插件与帖子投票中的评论更改保持同步是可行的。
有趣。不确定这是此插件的问题还是帖子菜单本身的问题，但是的，这需要解决。这是移动端还是桌面端？使用的是什么浏览器？
嗯，你正在进行的系统很有趣。答案将取决于你如何设置这个自动主题分割系统。条目与评论的区别在于帖子是否有 reply_to_post_number，即：
entries = posts.where(reply_to_post_number: nil)
comments = posts.where.not(reply_to_post_number: nil)
所以你可以调整你的主题分割算法来考虑这一点。
要将评论转换为条目，请删除其 reply_to_post_number 值。
嗯，不太确定你的意思，但希望我对条目和评论之间区别的解释能给你答案。
是的，“主题条目”和时间线用户体验需要改进。
待办工作列表
- 改进评论用户体验
- 改进主题条目和时间线用户体验
- 添加全套前端和后端测试
- 解决与其他广泛使用的插件和核心的用户体验冲突
4 个赞
这是一个核心功能
嗯，我正在使用核心的功能，所以可能不会修改任何东西。一如既往 
我只是想了解未来会发生什么。但如果我的理解是正确的，条目会计入最大帖子限制，而评论则不会。如果是这样，那就太棒了。
有点离题，但大型主题通常是普遍接受的规范吗 
对新成员来说阅读起来很费劲，对老成员来说也很难找到东西。现在我开始理解为什么摘要是一个如此受欢迎的功能。不可避免的是，大型主题会导致无休止的重复和大量的离题内容。
我明白了。
目前，帖子和评论都将计入限制。我或许可以调整一下，只计算帖子。但我需要更仔细地研究一下。
2 个赞
我在这里开始失去焦点，并且在问一些 101 级别的问题，但如果 posts.where 和 posts.where.not 做的事情一样，那它们有什么区别呢？但我假设 nil 只是一个例子，实际使用的是真实值 
但不管怎样。这个有限长度的问题并不是什么大问题，所以如果你想看的话，可以在你无聊而且没有更重要的事情做的时候看。因为总有一天我会了解它是如何在实际环境中工作的。
1 个赞
它们的意思不一样。nil 是真实的值。
posts.where(reply_to_post_number: nil)
表示 reply_to_post_number 为 nil 的帖子，这意味着它不是对另一个帖子的回复（即，它是条目）。
posts.where.not(reply_to_post_number: nil)
表示 reply_to_post_number 不为 nil 的帖子，这意味着它是对另一个帖子的回复（即，它是评论）。
无论如何，你可能不需要担心 rails 查询。如果我们为核心自动主题拆分添加了不支持计算评论的功能，我会通知你。
1 个赞
谢谢你的解释，现在我明白了。
1 个赞
我已经成功安装并启用了该插件，但现在有点迷茫？
是否可以更新此帖子，添加一个入门指南？
嘿 @apidevlab，我在上面添加了关于如何开始的简短说明
1 个赞
您好 @angus，非常感谢您的帮助，我已成功找到设置分类时的附加设置，现在可以正常工作了。非常感谢您对这款优秀插件的贡献和辛勤工作 
1 个赞
各位，该插件的工作规范正在制定中。如果您有兴趣扩展/使用此插件并想了解更多信息，请在coop.pavilion.tech上给我发消息。
4 个赞
这个插件很酷。我可以看到它的多种用途。
1 个赞