这更像是一个 Feature - Dev 主题，我不确定它应该归入哪个。
有没有办法在插件中修改站点设置？我有 99% 的把握没有，但我只是想确认一下。
如果没有，我是否可以提出一个建议，不要让它成为不可变的？或者，是否可以有一个 API 或一种方法来“解锁”SiteSettings 的不可变属性？
我正在考虑的一个可能的用例是将受保护类别的列表包含到一个设置中，这样管理员就可以更容易地包含/排除它们。
谢谢。
1 个赞
你只是想更改站点设置的值吗？只需执行 SiteSetting.whatever='new value 即可。或者你想改变关于它们的一些事情？
你不想为此添加一个设置吗？只需添加到 config/settings.yml 中？ 类似这样的
1 个赞
[quote=“NateDhaliwal, post:1, topic:389676”]我正在考虑的一种可能的用例是将受保护类别的列表包含在一个设置中，这样管理员就可以更容易地包含/排除它们。
[/quote]
我们从这里开始，由外向内进行。
您能首先从社区的角度描述一下用例吗？他们试图完成什么？目前做这件事有什么困难？您想象中的什么功能可以更有效地满足他们的需求（无论如何实现）？
然后，我们可以从那里确定这最好是通过插件还是作为核心功能来实现。
然后，我们可以从那里讨论实现它的建议。
1 个赞
我错误地认为，既然在 TCs（主题/分类/站点设置）中设置是不可变的，那么在 Ruby 插件中也是如此。我会试试那个方法。
如果能在 TCs 中使它们可编辑就更好了。我的用例（我现在正在使用一个插件来实现）是获取所有分类中的所有主题和帖子，然后对它们做一些处理，但不想包含受保护的分类（比如一个 excluded_categories 设置）。
然而，如果可以向设置中添加受保护的分类，然后之后再访问它，那就更容易了。这样，管理员可以通过从设置中移除它们来选择包含某些受保护的分类。
有了 @pfaffman 的想法，这也许可以实现，但不能在 TCs 中实现。
这样做的问题在于我事先不知道受保护的分类是什么。
如果你以管理员身份登录，那么主题组件可以通过 API 更改 siteSettings。
那只需创建一个主题组件设置并添加那些类别即可？你指的不是我没想到的某个 protected_categories 站点设置吧？所以是像这样？
1 个赞
我很想了解更多信息。我认为这将有助于我更好地理解这个请求的背景。
您愿意分享更多关于您的社区的信息吗？
您是此功能的主要用户，还是您的团队中还有其他人需要它？您是否有依赖此功能的工作流程的用户文档？如果有，它看起来是怎样的？如果没有，您能简要描述一下它可能是什么样的吗？
@mcwumbly @pfaffman 好的，让我尽可能多地解释一下。
我正在开发一个插件，它将主题和帖子发布到 GitHub 上作为 Markdown 文件（类似于存档）。
但是，我不想包含私有分类（我想现在这是正确的术语？）到其中，因为它们是“私有的”。
因此，我正在寻找一种方法来预先填充一个设置，其中包含私有分类的列表，该列表不能在 default 参数中定义，因为我事先不会知道私有分类是什么。
如果可以通过直接在 Ruby 中更改 SiteSetting 来完成此操作，那么是否也可以通过主题组件（Theme Component）的 settings 来完成同样的操作？我相当确定后者是不可变的。有没有办法在主题组件中更改它？
请耐心等待。
我仍然想从社区团队的角度更好地了解您试图解决什么问题。
这是什么样的社区？谁在运营它？他们为什么要将内容复制到 GitHub 上？
他们试图解决什么问题？
1 个赞
这与社区关系不大。我正以我自己的方式尝试这个（并附带一个回填作业）。这会将每个主题和帖子保存为存储库中的一个 Markdown 文件。
1 个赞
我仍然不清楚“私人”对你意味着什么。它是否意味着你只想要对所有人或匿名用户可见的分类？或者你是否有其他定义。
如果你想要那些，那么你的插件可以只获取那些，也许通过你传递一个用户的搜索（或者也许通过调用一个守护进程），或者只是检查权限。
或者如果“私人”是一种观点，那么你可以添加一个设置。
你可能想在每天运行一次的作业中做这个，还是其他什么？
如果你要将内容推送到 GitHub，我认为你希望 Discourse 自己来完成，而不是弄乱让你的浏览器将数据推送到 Discourse？我不明白你如何以及为何要用主题组件来做这件事。
2 个赞
我的意思是像 Staff 这样的类别，以及其他受群组限制的类别。我认为这可以通过插件实现，但我猜 TC（主题创建者）设置就不能再更改了？
另一种可能的方法是将其进一步外部化，而不是作为插件或主题组件来实现。
这里有一些先例：Discourse Public Data Dump
再说一次，我认为尽可能从你正在努力实现的最终结果的角度来处理这个问题，这样更容易提供建议。
所以感谢分享这个链接：
也许我们可以以此为起点，进一步阐明到目前为止你隐含定义的功能规范（functional spec）。
我现在对你的理解是，你想要：
- 创建一个 Discourse 站点的静态 html 存档
- 随着新内容的创建而保持其最新
- 排除某些版块
你目前正在探索的设计是：
- 创建一个插件，该插件：
- 允许管理员：
- 明确配置要排除哪些版块
- 配置一个 git URL 来存储静态内容
- 定期运行一个后台作业，该作业：
- 为主题和帖子创建 markdown 文件
- 将它们存储在 git 仓库中的某个文件/目录结构中
- 将其推送到 GitHub
- 允许管理员：
- 最终用户可以在 GitHub 上以 html 形式查看内容
这样对吗？
完全正确！我已经根据那个这里做了一个基本结构。
1 个赞
您不需要为此设置，该信息已可供插件使用。
1 个赞
我是否正确地理解您指的是 Category.where(...) 方法来获取这些“私有”分类？但是，如果管理员想包含（其中一些）这些分类，我是否需要一个 include categories 设置来抵消代码中定义的“私有”分类？那会不会适得其反？
更新：所以 SiteSettings 可以通过插件编辑。但我认为 TC 设置仍然不能编辑？将 Modify SiteSettings/make SiteSettings mutable? - #2 by pfaffman 标记为解决方案。
我仍然不明白这一点。是的，您可以将这些设置添加为 SiteSetting，并且插件可以读取该设置，甚至可以更改它。但是在上述情况下，它为什么要更改该设置呢？
1 个赞
假设我有 5 个类别：A、B、C、D 和 E。现在假设 B 和 C 仅对某些组可用。为了防止私有主题在上传到存储库时被共享，B 和 C 与 Staff 等其他类别一起被添加到 excluded_categories 设置中。
现在假设网站管理员同意共享 B 的主题，他可以从该设置中删除 B，同时保留 C。
因此，excluded_categories 一开始必须更改为添加“私有”类别 B 和 C。我不确定这是否有意义？
尽管从技术角度来看这是完全可行的，但我认为这种方法会过于复杂，特别是考虑到“在开始时”很难定义/检测，而且您想避免插件在站点管理员将其删除后仍然不断添加 B。此外，当添加一个新的私有分类时，插件需要添加它，但它需要能够区分一个新的分类（添加）和管理员先前已删除的分类（不要重新添加）。
我倾向于使用一个初始为空的 include_private_categories 设置，插件将简单地处理所有公共分类，以及 include_private_categories 中的分类。这将为您省去很多麻烦。
3 个赞
我还更新了标题，以更好地描述此主题的真正内容。
2 个赞
我能想象的另一种替代设计是拥有两个独立的仓库：一个用于公共内容，一个用于私有内容。
私有内容仓库本身可以保持私有（您可以独立确定谁有权访问它）。