重新排列话题和类别的软件架构

社区维基 系统管理员
1

为了脚本化地重新排列一个大型 Discourse 站点，并与我的网站领导层合作，我编写了一个简单的框架，用于打包一系列 ruby 脚本，并通过 YAML 配置文件进行驱动。这样，我就可以在暂存站点上恢复备份，运行我的脚本，获得反馈，更改几行 YAML，恢复备份，用新配置运行脚本，然后重复，直到满意为止。

我的网站有近 600 行配置，通过 UI 手动操作是行不通的。更不用说多次操作来获得正确的结果了。我知道这一点，因为上次我提出进行大刀阔斧的更改时，我确实放弃了尝试。相比之下，有了这个脚本，我现在可以在每次迭代中完成整个周期，只需几分钟，即使该网站大约有五十万个帖子和一百多个类别。这让我能够从我的网站领导层那里获得快速反馈，并且我将能够快速迁移我的网站。

更详细的文档在存储库的 README 文件中，代码如下：

:warning: 此脚本不进行任何错误检查。在实时站点上运行它几乎是疯狂的。它旨在在暂存站点上运行，验证结果，然后上线。作为作者，我仍然打算这样运行它。如果你直接在实时站点上运行它，当它崩溃时，你将不得不承担所有后果。 :warning:

根据文档，配置文件可能如下所示：

---
- describe:
    context: Old Name
    category: 7
    name: New Name
    description: New description of category
    slug: new-slug
- movePosts:
    context: move only faq posts from the Support category to the Documentation category
    source: 3 # Support category ID
    target: 6 # Documentation category ID
    withTag: faq
    hide: false # do not hide the Support category when done
- movePosts:
    context: consolidate How-To category into documentation with how-to tag
    source: 8 # How-To category ID
    target: 6 # Documentation category ID
    addTag: how-to
    hide: true # hide the old How-To category, visible only to Admin

运行时，进度输出可能如下所示。

==========
Move hidden categories out of the way so they don't clutter admin view
setHiddenCategory: {:category=>11}
==========
Rename Old Name to New Name
describe: {:category=>7, :name=>"New Name", :description=>"New description of category", :slug=>"new-slug"}
==========
move only faq posts from the Support category to the Documentation category
movePosts: {:source=>3, :withTag=>"faq", :target=>6}
==========

要使用它，请将您的 YAML 文件放在 /var/discourse/shared/app/tmp/rearrange.yaml，然后：

cd /var/discourse
./launcher enter app
git clone https://github.com/johnsonm/discourse-site-rearranger.git script/discourse-site-rearranger
ruby script/discourse-site-rearranger/rearrange.rb /shared/tmp/rearrange.yaml

但是， 这个脚本很可能无法完全满足您的需求。它实际上是一个框架，可以非常轻松地通过几行代码插入新操作，以自动化脚本化站点修改的更多方面。您只需要定义一个具有几行代码的方法，就可以从 YAML 文件中正确调用它。

您是否一直在考虑改进您网站的组织结构，但又因为使用 UI 而望而却步，或者想知道如何相信您能够在暂存站点上复制您的测试以进行实时更改？看看这个，告诉我您的想法！

5 个赞
5

我正在使用此脚本创建一个测试站点，作为我主站点的克隆。高视觉保真度是重点的一部分，但可能会导致在审查更改时意外地在错误的站点上发布内容，并且下次刷新测试站点时，这些意外发布的帖子会被清除。

我最初在征求公众反馈时将测试站点设为只读。但站点处于只读模式时禁用了登录，因此当要求他们登录时，他们无法登录。

我添加了一个新的 publicCategoriesReadonly 操作，该操作使匿名可见的类别只能由 :admins 写入，而 :everyone 只能设置为 :readonly，以便允许人们登录并进行探索，但有助于避免意外地在错误的站点上发布内容。现在，整个站点不是只读模式，但公共类别是只读模式。

6

可以通过 slug 将类别引用为标签。此脚本允许移动类别内容并更改 slug，这会导致之前的帖子在重新烘焙后不再链接。（在重新烘焙之前，永久链接重定向将使链接正常工作。）

我现在已更新脚本，以跟踪迁移之前和之后的标签，并重新映射帖子中对已更改类别的引用。

7

我已经为那些安装了 Retort 并希望迁移到受支持插件的用户，在框架中添加了一个 migrateRetortToReactions 操作。

2 个赞
8

太棒了！这是个好消息。如果有人能把它做成一个 rake 任务并提交给 reactions 插件就更好了。

我很快会看看。

1 个赞
9

将它作为插件中的 rake 任务听起来对我来说很明智。

我已经签署了 CDCK CLA，因此我对由此产生的作品的任何版权利益都不会受到阻碍，并且它可以与插件本身相同的许可证一起使用。

另外，我想我可能弄错了什么；如果你发现任何错误，我很想知道，因为我计划在未来几周内在自己的网站上运行该脚本。:smiley:

从更大的范围来看，如果你发现这个框架对你支持 Discourse 安装的工作很有用，但希望有更多的错误处理，我将接受 PR。我只想确保任何提交给它的 PR 都来自已签署 CLA 的人，并且同意它的任何有用部分都可以合并到官方 Discourse 中，我知道这对你来说是真的……

2 个赞
10

我在 Retort 主题中发现 @angus 有一个分支支持 UI 驱动的转换，我之前完全错过了这一点。

我的脚本深入研究了内部机制，这些机制将来可能会发生变化，一旦我用这个脚本完成了转换，我就不会注意到这些内部机制的变化了。 我首先尝试“正确地”去做，但发现 Reactions 插件没有暴露允许这样做的接口。@angus 采取了更长远的眼光：

@pfaffman 如果你创建一个 rake 任务，你可能想把它放在一个也对接口进行更改的 PR 中，这样，例如，created_by 可以被传入，并且是静默的，而不是像我那样使用“后门”。到那时，rake 任务将用于命令行迁移，同时也将允许 @angus 进行 UI 驱动的迁移。