我不这么认为。这个案例似乎与图片网格类似。在那次更改中，警告也被显示出来了，但当时我收到的回复是：
1 个赞
您之后仍然可以通过常规站点设置来禁用它。
@davidb 你能确认一下吗？
我同意，在即将推出的更改中，我们也应该想办法让这种措辞不那么令人困惑。
我们可以尝试在更改本身可配置时，在其标题和描述中清楚地说明这一点。
1 个赞
GIF 即将推出的更改目前位于隐藏的网站设置中，但我觉得未来我们应使其可见，并允许在管理区域中启用或禁用该功能。
在此期间，只需将即将推出的更改保持为“无”，这样未来默认情况下它将处于关闭状态。无需在管理端进行任何进一步更改。
4 个赞
是的，当我搜索 enable_gifs 时，它直接把我带到了即将推出的更改页面。这非常令人困惑。
即将推出的更改这个概念很棒。只是需要调整一下措辞。
谢谢大家！
2 个赞
在这种情况下 @davidb @mcwumbly，如果 enable_gifs 的变更类型是 site_setting_default 而不是 feature，就不会显示那个令人担忧的永久性提示。这是在这里控制的：
不过，我认为一般来说，对于即将发生的变更，使用 feature 类型是可以的……所以也许我们需要让这个永久性提示对即将发生的变更更加明确。
也许可以添加 will_become_permanent: true 或类似的额外元数据？不太确定……
1 个赞
为什么我们被引导使用 Klipy 而不是其他选项？我更喜欢 Giphy，希望继续使用它。
该组件的设置和交互方式使得使用其他选项（如 Giphy）变得非常令人困惑。
我想这是因为 Giphy 不再提供免费选项了
1 个赞
现在没问题了。我搞定了（谢谢 Moin！）。我不得不卸载 Discourse GIF 组件，以便让设置选项出现。然后将该设置设为 no one（无人），再重新安装并重新配置该组件。现在 Giphy 又可以正常使用了。
2 个赞
很高兴能帮到你。当安装了 GIF 主题组件时，即将到来的变更会被隐藏，这确实有点令人困惑：要使用该组件，你需要先卸载它，禁用即将到来的变更，然后再重新安装。
你是否收到了关于该变更的通知？还是说因为即将到来的变更被隐藏了，所以这些通知被抑制了？我在想，这是否会导致他们不知道需要运行迁移并获取 API 密钥的问题。
1 个赞
哦，我们以前在主题组件中有这个，但在核心中没有，有一个 providerLogo：
Klipy 的那个是在 FEATURE: Add Klipy as GIF API provider by xfalcox · Pull Request #107 · discourse/discourse-gifs · GitHub 中添加的。@davidb 在核心版本中故意不添加这个提供商标志是故意的吗？
2 个赞
不幸的是，在移植到核心时似乎遗漏了它。它之前在主题组件中是条件性显示的，但现在我们应该始终显示它。
已在此处添加：UX: add Klipy branding to gifs picker - Pull Request #41501 - discourse/discourse - GitHub
2 个赞
最近，我们在主题组件中添加了一个全局通知横幅，因此当组件更新到最新版本时，它会向站点管理员显示横幅和指向本主题的链接。
由于我们上周将即将进行的变更移至稳定版，因此该横幅现在应该出现在任何使用主题组件的站点上，以便他们采取任何必要的操作。
提醒一下，如果您真的想继续使用 Giphy，可能值得分叉该存储库，因为我们计划在不远的将来将其归档。
2 个赞
我们采用自托管方式，并在旧的主题组件中使用了 Giphy。我们禁用了该功能，现在只能看到 Klipy API 选项。我们能否输入旧的 Giphy 密钥并将其用作提供商，还是说现在必须使用 Klipy？
编辑：看来不行，所以我们只能听天由命，通过 Klipy 进行验证视频审核了。
嗨 @fearlessfrog 
我遇到了同样的问题——要继续使用 Giphy，你需要完全删除该主题组件（仅禁用是不够的），然后将 admin -> 即将推出的更改 → 启用 GIF 设置改为“无”。之后，重新安装该组件的一个分支即可继续使用——官方团队很快就会归档他们的版本。我在这里有一个该组件的分支，你可以使用。
卸载旧组件：
在 admin-即将推出的更改 中禁用该设置
我真的不知道团队为什么要这样做，但这非常令人困惑，我花了好一会儿才弄明白（多亏了 Moin 的解释）——这对自建服务器用户非常不友好。将来我可能会将该分支重建为我自己的组件，去掉其他不必要的字段和文件，但在那之前我会设置一个管理员横幅通知。
给团队的备注：Discourse Gifs 组件仍然列在默认组件安装页面中：
4 个赞
谢谢，@davidb 能否请移除这个选项？
我们之所以这样做，是因为它优化了我们托管客户的设置，我们会手动进入并为他们卸载旧的 gif 组件。我们没想到人们会想继续使用 Giphy，因为他们的定价公布后显得非常高，这正是我们最初在主题组件中添加 Klipy 的原因。
下次我们可以为想要继续使用旧组件的自托管用户在原帖中添加更多信息，我们只是假设这里的自托管用户也会转向 Klipy：
我们一定会想办法让这件事不那么令人困惑和意外，我已经让 David B 开设一个内部主题，我将在不久的将来着手处理。
2 个赞
我不明白的是，我仍然在使用我原来的免费 Giphy API，没有任何问题？我刚刚登录了 Giphy 开发者控制台，它就在那里。我到底要承担哪些费用？我从未输入过信用卡或支付任何费用，现在我也看不到需要支付的地方——对我来说，它看起来一直就是这样。我链接它的论坛似乎没有遇到速率限制，而且我们经常使用它 
好吧，显然它对于每小时最多 100 次 API 调用 运行良好，我认为这对于自托管者来说完全没问题。
2 个赞
没错，但考虑到我们希望 GIF 成为核心功能，在我们的托管环境上成本会高得令人望而却步。
2 个赞
我认为主题组件中只包含了“由 Klipy 提供技术支持”（来自此列表），但在移植到核心版本时，我们本应更仔细地对照官方网站进行检查——已在 UX: add placeholder text for Klipy gifs search - Pull Request #41651 - discourse/discourse - GitHub 中添加了主要的必要归属声明。
已完成——已在 UX: remove gifs from popular theme components - Pull Request #41649 - discourse/discourse - GitHub 中添加。
我们已更新了该警告显示的逻辑。问题现已在 DEV: add upcoming change permanent banner metadata - Pull Request #41700 - discourse/discourse - GitHub 中解决。
对于运行最新 Discourse 版本的站点，这些问题现已得到解决。
4 个赞