收藏

:information_source: 摘要 用户创建链接主题的集合
:hammer_and_wrench: 存储库链接 https://github.com/Alteras1/discourse-collections
:open_book: 安装指南 如何在 Discourse 中安装插件

预览

移动端

集合

这允许用户创建主题的集合,这些集合在查看主题时可见。集合可以包含任何 URL,并且将在所有链接的主题上可见。集合可以组织成部分,并且对集合的任何更改都会反映在所有链接的主题上。链接的主题没有限制,因此用户可以跨类别/标签创建集合。

标题 & 描述

可选字段。如果提供,这些将显示在列表顶部。

部分

可选的组织功能。通过添加部分标题,可以将集合分成多个部分,从而显示可折叠的部分。

子集合

用户还可以创建子集合,该子集合仅为单个主题显示,允许用户仅为单个主题链接相关的 URL(例如特定帖子/外部资源)。添加的任何主题 URL 都不会被链接。

权限

该插件允许任何用户为其自己的主题创建集合。默认情况下,用户只能链接到自己的主题,并且必须添加其他用户作为维护者,他们可以添加自己的主题到集合中。此设置可以禁用,只允许特定组完全控制任何集合(默认情况下为 Staff & TL4)。

权限演示

设置

名称 描述
collections enabled 启用/禁用插件。默认值:true
collection by topic owner 允许主题 OP 创建集合。默认值:true
collection by topic owner allow groups 限制可以创建集合的主题 OP。限制 collection by topic owner。默认值:TL1
collection modification by allowed groups 允许创建/修改任何集合的组。默认值:Admin Moderators TL4
sections in subcollection 允许子集合中的部分标题。默认值:true

替代方案

该插件深受 Discourse Doc Categories 插件的启发(并且曾经基于它)。虽然 Doc Categories 插件具有良好的索引机制并且显示效果很好,但其设计用于 wiki 风格的页面,其中所有内容都汇集在一个类别中。同样,索引依赖于在单独主题中进行格式化的文本输入,这有利有弊。

DiscoTOC - automatic table of contents 主题组件也允许在帖子正文之外组织链接,但仅限于单个主题。

如果你的目的是仅仅是 wiki 风格的组织,Discourse Doc Categories 会是更好的选择。如果你只需要一些页面链接主题,DiscoTOC - automatic table of contents 会更好。

注意

这最初是为了支持我所在的论坛迁移到 Discourse 而设计的。作为一个以写作为主的论坛,用户会为不同的目的维护单独的主题,导致跨类别链接几乎是必需的。为了促进这一点,我创建了这个插件来支持用户自我组织。

曾经有一个替代方案,它只是一个主题组件,其中索引将通过用户输入的带有指向其他帖子的 URL 的 div 来实现。但在开发了 90% 的工具、向导和代码后,我意识到这不值得,用户很可能会跳过所有教程,仍然抱怨为什么东西不起作用。所以那个方案被放弃了。它实际上不是一个坏解决方案,因为它比插件更轻量级,但它会给用户带来很多不必要的负担,让他们确保不仅在一个帖子,而且在多个帖子中都有正确的格式。

我目前将其标记为 experimental,因为我对 UI 功能(例如图标)和权限系统还不是 100% 确定。另外,我需要添加自动单元测试。

20 个赞

供参考:所有视频都坏了 :thinking: (iPad)

1 个赞

哎呀,我以为 iOS Safari 支持 WebM……

我已经把视频换成了 MP4。谢谢!

5 个赞

是否可以启用像 Discourse Docs 那样的‘公开’集合?

1 个赞

抱歉,如果之前没有说清楚,所有的集合都是“公开的”。所有用户都会看到关于同一主题的相同集合。此插件旨在组织主题,而不是作为用户的私人“书签文件夹”。

5 个赞

更新了插件,支持侧边栏中的表情符号和彩色方块!

5 个赞

这看起来确实非常棒。而且文档绝对出色——这是我心目中 meta.discourse.org 上文档最完善的 Plugin!!

您是否考虑过将其扩展,使其也涵盖主题列表?

我经常发现,拥有每个类别或每个标签的链接集合会非常有帮助。例如,有一个专门针对特定群组的私有类别,它还使用其他一些工具(例如 Google Docs 中的几个文件夹、一个地方政府门户网站、一个关联的聊天频道和一个群组收件箱)。最好能由类别版主来控制它。

3 个赞

非常感谢!

这绝对是我之前考虑过的事情,但我不认为它会很好地融入当前以用户驱动的方式来组织主题的设计。对于分类/标签级别来说,这并不理想,因为它必须限制在版主控制之下。最初的用例是为了涵盖链接那些对于 1-2 个主题来说太大了,但对于标签/分类来说又太小了的相关主题。

可以通过 Discourse Doc Categories 插件在侧边栏中显示分类的主题列表索引,尽管配置方法不同。拥有两个插件做两件非常相似的事情确实很麻烦,但我认为它们最初的理念足够不同,足以保证采用不同的方法。

从用户的角度来看,为 Private Topics Plugin 添加一个兼容扩展是一个非常酷的想法。我得考虑一下……

这样就只剩下每个标签级别了。为标签创建一个 Discourse Doc Categories 的 PR(或者创建一个新的插件/TC)是一个选择,但目前我并没有积极考虑。也许将来会。

实际上,这可能很适合我的用例。我不确定它是否足够灵活以适应(我将在本周晚些时候尝试一下)。

听起来很有趣。您有什么用例?

对于普通用户来说,启用私有主题的类别只会显示他们自己的主题。因此,我认为这可能是少数几个地方之一,允许 Collections 插件将集合从主题级别提升到每个用户的类别级别是有意义的。

我参与的论坛实际上有一个私有类别供用户用作个人草稿/测试场地。他们会创建大量的主题,因此有时会在这里发生用户驱动的主题组织。

我真的很希望它是一个用户可以创建类别并将他们选择的主题放入其中的收集系统,就像一个画廊。唉。

这怎么不是那个呢?

1 个赞

我猜你不能创建类别。

我非常欣赏这个插件的拖放用户界面(UI),它可以轻松创建像书籍章节一样的任意主题序列,并且可以轻松重新排列。

我已经启动了一个主题组件,用于为集合添加顺序导航,例如 \text{<kbd>上一个 <</kbd>}\text{<kbd>下一个 ></kbd>} 以及在模态框中进行分页……

这是我的工作仓库

3 个赞

非常需要,我今天正在查看这个,这似乎是它最后需要的组件。

@Alteras 我在“创建集合”模式中遇到了关闭 X 的错误。它可以悬停和点击,但直到页面刷新后才能关闭该模式。

1 个赞

哦,这是一个很棒的概念。我喜欢用于快速查看不同链接主题帖子的模态框。它也有助于告知用户,对于那些没有/不一直打开侧边栏的用户来说,存在一个“集合”。

我对替换帖子内容而不是仅仅将用户重定向到主题的决定感到好奇。

我真的很喜欢使用 « 上一个下一个 » 在时间轴上方导航主题的想法,而无需侧边栏。也许它可以像目录 (toc) 一样与时间轴结合,这样在长篇的第一篇帖子主题中可以轻松访问,而无需滚动回顶部……或者只是装饰顶部/底部的帖子本身……

如果你同意,我想探索将其中一些想法直接添加到插件中,也许为管理员添加额外的站点设置。当然,我完全不反对基于该插件构建一个主题组件 (TC),为用户提供更多定制。如果你需要关于你的 TC 的任何帮助,请告诉我。你应该能够从 Ember 服务 service:collection-sidebar 中获取当前显示的集合信息,而无需解析 DOM。

嗯……这真的很奇怪。我似乎无法重现它。我最近进行了一些更改,更新了插件以解决一些弃用问题,这可能会有影响?请检查插件是否已更新。也请分享您的设置详情(浏览器、移动/桌面、Discourse 版本)。

2 个赞

我过时了,也许这就是原因。我还在使用 11 月 6 日的提交。
预计时间:请忽略,更新后已解决。

1 个赞

我喜欢这种快捷性。这不是一个经过深思熟虑的设计。

由于这里有机会对项目进行任意排序,而排序绝对不与任何时间轴挂钩,我的初步目标是重用核心中嵌套的水平滚动菜单行为,就像我们在用户个人资料显示中所做的那样,例如,在(固定的)收藏集标题和描述(如果/存在)下方,是两行可水平滚动/滑动的行——分区标题及其关联的主题标题在下方。

模态框内还有一个可折叠的(从左侧快速滑入/滑出)垂直显示,复制了模态框外部左侧边栏的行为。

请,尽管去做吧!

2 个赞

既然我已经让它运行起来了(感谢上面关于更新的提醒),我发现有几点问题:

  1. 即使用户不属于允许的组,集合按钮仍然可见。尝试创建集合时会导致内部服务器错误(在模态框中以红色条优雅地显示)。
  2. 在集合侧边栏上,底部的按钮提供了原始的“创建集合”选项。必须使用原始帖子上的按钮才能管理它,如果能立即从集合侧边栏上的按钮提供“管理”选项会非常有帮助。
  3. 是否有可能区分集合和子集合的权限?子集合对于那些希望自己整理主题但又不想对所有链接的主题产生集合那样的广泛影响的个人来说,将非常有用。

最后,这个插件如何处理两个集合链接同一个主题?两个子集合?这让我更倾向于建议 #3,以便喜欢集合功能的用户更容易管理重叠的目标。

编辑:我意识到 #1 是一个与集合修改相关的错误,它允许属于允许组但非拥有的主题进行修改。尽管如此,一个更好的错误消息可能会有所帮助!

1 个赞

所以设置 允许组修改收藏集 是为工作人员和特权较高的用户准备的,例如维护维基的帮助者。不过看来我需要修复这些错误。

只要 允许组修改收藏集 设置得足够高,收藏集和子收藏集应该只能由主题所有者(和工作人员)创建/修改。主题所有者应该能够将普通用户添加为收藏集或子收藏集的维护者,然后这些维护者可以添加他们自己的主题。我不太确定您的设置是什么,以至于需要将它们分开。

两个收藏集不能链接到同一个主题。尝试链接已在收藏集中的主题时应显示错误。同样,每个主题只允许有一个子收藏集。这是因为收藏集都是公开的,应该只由主题所有者创建。


嗯……我感觉最好是创建一个单独的插件,它只包含可以公开或私密查看的书签文件夹……“个人收藏集?”“书签库?”“主题播放列表?”或者我干脆扩展这个插件。但这两个功能的底层代码和理念会大不相同……不幸的是,“收藏集”这个名字相当宽泛,可以有多种解释。

2 个赞