# 有没有办法强制将标签添加到特定类别的主题中，而无需用户添加？

**URL:** <https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770>\
**Category:** Feature\
**Created:** [2023年三月28日 22:20 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770 "2023-03-28T22:20:49Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![MikeNolan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mikenolan/32/297597_2.png) [@MikeNolan](https://meta.discourse.org/u/MikeNolan)\
**Post date:** [2023年三月28日 22:20 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/1 "2023-03-28T22:20:50Z")

</div>

尽管我可能还有两周时间才能启动我的第一个 Discourse 站点（这是我 30 年来运行的邮件列表的替代品），但我已经在考虑另一个可能的项目，那就是将我的烹饪/烘焙博客站点从 Wordpress/BBPress 迁移到 Discourse。

为此，我需要一种方法来识别食谱并更改它们的格式和打印方式。

在标记新主题以在首帖中包含食谱方面，主题标签似乎是最佳选择（后续帖子将是评论，而不是完整的食谱），但似乎没有办法强制将标签（例如，“recipe”）插入到标签字段中。我还考虑使用标签字段来指示食谱的类型（面包、甜点、肉类等），以便食谱可以有多个标签，例如：recipe dessert。

打印是另一个独立的问题，我已经决定，为了实现这一点，我需要创建一个插件，让 Discourse 对打印主题中的选定帖子有更大的控制权。格式化带有食谱标签（首帖）的帖子以供打印可能是第二个任务。我可能还需要几个月的时间才能掌握足够的 Ruby 知识来考虑解决这个问题。

但愿望清单就到此为止，我现在的问题是，我能否强制在一个类别（例如，recipes）中创建新主题时预先插入一个标签（例如，recipe），这样用户就不必选择它，也无法删除它？

---

<div class="post-metadata">

**Author:** ![awesomerobot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/awesomerobot/32/142900_2.png) [@awesomerobot](https://meta.discourse.org/u/awesomerobot)\
**Post date:** [2023年三月29日 14:06 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/2 "2023-03-29T14:06:30Z")

</div>

我不确定你的具体用例，但在一个类别中强制为每个主题使用相同的标签可能是多余的。

虽然你无法使用现有设置在类别中预填充标签，但可以通过主题组件或插件来实现。

在没有进一步自定义的情况下，有几种方案可能适合你的情况：

1. 设置类别中的“主题所需最少标签数”设置，并为类别添加“必需标签组”。

2. 根据食谱中经常出现的单词或短语设置自动标记。你可以从“管理/自定义/监视的单词”进行设置。

---

<div class="post-metadata">

**Author:** ![MikeNolan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mikenolan/32/297597_2.png) [@MikeNolan](https://meta.discourse.org/u/MikeNolan)\
**Post date:** [2023年三月29日 16:36 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/3 "2023-03-29T16:36:45Z")

</div>

我实际上更希望在帖子中有一个单独的字段，说明“这是一个食谱，请相应格式化”，这样标签就可以用于其他面向用户的目的，正如我们俩所说明的那样，但我还不知道如何做到这一点。我知道有方法可以设置自定义帖子字段和自定义主题字段，但我仍在学习如何访问或利用它们。

虽然我认为主题中的主要帖子将被标记为食谱格式，但它也可以应用于其他地方。此外，除了我的烹饪博客之外，可能还有其他标记帖子以进行特殊格式化的用例，其中标记的帖子不一定是主题中的主要帖子或任何特定类别。而且，泛化该方法可能具有更广泛的实用性。

食谱配方的细节是另一个棘手的问题，理想情况下，我希望有一个结构化的格式，以便我可以隔离配料、指定的计量单位和数量的字段，最好是以一种允许我利用其他配料营养信息、价格、库存等数据库的方式。总产量也将允许食谱按比例放大或缩小。一些其他烹饪网站也这样做，但我认为它们缺少我想要的功能，烘焙社区也想要。是否所有这些都可以以与 Discourse 数据结构兼容的方式完成是另一个问题。（但我的第一印象是，在 Discourse 中完成可能比在 WordPress 中或作为从头开始的独立系统更容易，您已经构建了许多支持结构。）

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2023年三月29日 18:11 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/4 "2023-03-29T18:11:51Z")

</div>

> [@MikeNolan](#):
>
> 我实际上宁愿有一个单独的帖子字段，上面写着“这是一个食谱，请相应格式化”，这样标签就可以用于其他面向用户的目的。

您可以在插件中使用 TopicCustomField，但仅限员工使用的标签集，或者强制所有用户使用的标签集会更容易维护。另外，您能否将一组类别设置为食谱，这样您就可以将该格式应用于整个类别？这似乎是“哪些帖子是食谱”的最简单解决方案。

---

<div class="post-metadata">

**Author:** ![MikeNolan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mikenolan/32/297597_2.png) [@MikeNolan](https://meta.discourse.org/u/MikeNolan)\
**Post date:** [2023年三月29日 18:29 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/5 "2023-03-29T18:29:29Z")

</div>

这可以满足我的特定用例，但我正在考虑一个更具通用价值的插件。以下哪个更合适：

- 我希望此类别具有单独的特殊格式
- 我希望此主题具有单独的特殊格式
- 我希望此帖子具有单独的特殊格式
- 以上某种组合，例如，此类别可以在其某些主题和/或帖子中使用特殊格式，或者此主题可以在其某些帖子中使用特殊格式

我确信我对 Discourse/Ruby 的了解不足以做任何事情，更不用说以正确的方式做了，所以也许先处理我的特定用例对我来说是一个很好的起点。但在我过去 40 年参与过的项目中，一旦有人找到了简化的方法来做某事，他们就对更通用的方法不太感兴趣了。

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2023年三月29日 18:48 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/6 "2023-03-29T18:48:03Z")

</div>

> [@MikeNolan](#):
>
> 这对我特定的用例来说是可行的，但我在这里是想为将来可能更有普遍价值的插件做考虑

> **[The General Problem](https://xkcd.com/974/)**

这并不是我想要的那个，但我认为你最好解决你实际遇到的问题，而不是你想象中的问题。

> [@MikeNolan](#):
>
> 我希望这个帖子有单独的特殊格式

这个会比较棘手，不过你可以创建一个插件来添加一个 PostCustomField 并将其添加到序列化器中。

仅仅决定你将拥有只包含食谱/需要特殊格式的分类，就能解决绝大多数用例。强制使用一组标签是另一种稍微麻烦些的方法，但它也几乎不需要维护代码。

---

<div class="post-metadata">

**Author:** ![MikeNolan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mikenolan/32/297597_2.png) [@MikeNolan](https://meta.discourse.org/u/MikeNolan)\
**Post date:** [2023年三月29日 18:57 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/7 "2023-03-29T18:57:51Z")

</div>

我感谢您的建议和指导。新手很烦人，不是吗？（正如我在另一个帖子中提到的，我还不了解我所不知道的东西。）

多年来，我分析系统的方法是，在制定需求清单时，尽量预见尽可能多的情况，然后看看有多少是我最终决定不需要的，或者不知道如何实现的。这种方法对我来说一直很有效。

我用标签来处理这个问题时遇到的一个问题是，有人可能会将该标签应用于不属于它的主题。当然，如果我说“格式化标签仅在类别 X 中的主题包含此标签时才适用”，这对我来说可能就足够了。

而且我想到，如果格式化标签是可选的，用户就可以在该类别中创建不应用特殊格式的主题。我只是还没有决定这到底是好事还是坏事。

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2023年三月29日 19:26 UTC](https://meta.discourse.org/t/is-there-a-way-to-force-a-tag-into-a-topic-in-a-specific-category-without-the-user-having-to-add-it/259770/8 "2023-03-29T19:26:24Z")

</div>

> [@MikeNolan](#):
>
> 我遇到的一个问题是，使用标签时，有人可能会将不属于该主题的标签应用到该主题上。

我认为这个问题适用于所有可能的解决方案。 🙂
