我只是好奇：这里停用“cakeday”插件是否有特定的原因？
1 个赞
1 个赞
所以，禁用插件的解决方案是，在那些多年来一直使用 cakeday 的论坛上禁用 cakeday，而不是在那些以前没有使用 cakeday 的论坛上禁用 cakeday？
1 个赞
我觉得情况有点不对劲了。
这是迁移 #1，它被注释掉了 
。
如何知道它是否在每个实例上都运行过？
所以该迁移将 SiteSetting.cakeday_enabled 保存在了数据库中。
这是一个清理迁移，它会删除在迁移 #1 执行时创建的该设置。这看起来有点可疑 但嘿，它有效 编辑：它无效。
所以现在它回退到了默认值，而默认值现在是……关闭的？
情况确实不妙。它很可疑，而且没有奏效。
我刚刚运行了 Discourse 站点更新，但无法通过您所说的清理迁移。
当迁移在 up 方法中运行 migration_timestamp("20250717093505") 和 migration_timestamp("20250811132217") 时，会得到 nil 值。这些 nil 值破坏了迁移中 delete_settings 方法中的 sql 查询。
可能是因为它所引用的迁移操作已经被注释掉了。
我一直被教导迁移操作以后绝不应被修改。这就是原因。
我打算把它移到 Contribute > Bug 板块，希望能引起更多人的关注……
1 个赞
将 d-cakeday 合并到 core 的过程没有按计划进行……
所有捆绑的插件都必须默认禁用，而 d-cakeday 是少数几个一直启用的迁移插件之一。
最初的想法是，在迁移到 core 之前启用了该插件的站点仍将启用它，而之前没有启用该插件的站点将使用新的默认值（关闭）。
我现在已经开了一个 PR，它用一个新的启发式方法替换了最近的（不正确的）迁移，该方法用于确定是启用 cakeday/cakeday_birthday 还是保持默认的“关闭”值。
5 个赞
此主题已在 4 天后自动关闭。不再允许新的回复。