从 Drupal 6 升级到 Drupal 7：程序员的最佳实践？

Posted 2023-02-15

【中文标题】从 Drupal 6 升级到 Drupal 7：程序员的最佳实践？

【英文标题】：Upgrading from Drupal 6 to Drupal 7: best programmer's practices?

【发布时间】：2010-12-17 13:59:25

【问题描述】：

虽然我从 D4 系列开始就使用 drupal，但我才开始使用 D6 进行专业开发，所以 - 尽管我进行了各种网站升级 - 我从未面临过必须移植我自己的代码的任务 到新版本。

我知道 Drupal 社区会提供很多关于更改 API 和架构更改的技术支持（请参阅 D5-D6 的 deadwood module 甚至这些 D6-D7 操作方法的存根for modulesand themes)。

但是，我的问题更多的是战略思考，或者换句话说，我正在寻找有关如何计划/实施/根据同事开发人员从以前的经验中学到的知识，回顾移植我自己的代码的过程。一些例子：

您是否建议我一有时间就开始移植我的模块，并在一段时间内保持并发 D7（因此我为 D 日“做好了准备”），还是建议您宁愿等待移植真正迫在眉睫的那一天，然后将模块升级到 D7 并删除 D6 版本？ 只有我的一些模块具有完整的测试覆盖率。您是否建议完成 D6 版本的测试覆盖，以便让所有测试都能检查 D7 端口，还是建议在移植时编写我的测试指令以测试 D7 版本？ 您是否发现作为早期采用者在新功能和更好的 API 方面为您提供了优势，或者您是否发现延迟转换以利用大量现成的 contrib 模块更方便？ 您是否为自己设置了质量标准/评估标准，或者您是否只是将标准设置为“如果有效，我很高兴”？为什么？如果你设定了某些标准或目标，它们在哪里/它们会是什么？他们对您有什么帮助？ 您过去是否遇到过常见的陷阱，并且您认为这些陷阱适用于 D6-D7 移植过程？ 移植是进行一些重构的好时机，还是只是让一切变得更加复杂而需要重新组合在一起？ ...

这些问题并非详尽无遗，但我希望它们能让我了解我正在寻找什么样的信息。我宁愿说：任何你认为相关且我没有在上面列出的东西都会得到一个“加号”！ :)

如果我没有足够清楚地表达自己，请发表评论，并附上您认为我应该在问题中添加的信息。提前感谢您的宝贵时间！

PS：是的，我知道... D7 还没有推出，重要的贡献模块升级还需要几个月的时间...但是现在开始思考永远不会太早！ :)

【问题讨论】：

我喜欢这个问题，因为这是我必须面对的问题。但是，我还不会太急于更新。不仅 Drupal 7 仍在开发中，而且您或我使用的许多模块都可能需要很长时间才能移植到 Drupal 7。此外，我们可能还可以使用新的（目前我们不知道的）特性或模块利用并实际减少我们的自定义代码。我的个人计划是在 D7 发布时安装一个测试版本，但要等到 Drupal 环境稳定后再移植我现有的站点。

嗯 - 到目前为止我还没有这样做，但鉴于这些是多个未解决的问题，没有可能的“正确”答案，我需要这样做：应该是社区维基！ i>（在那里，我说过了——现在快点，在那个位被翻转之前给我投票；）

我在社区 wki 上阅读了更多内容，所以我了解了背后的逻辑和推理，并将这个问题变成了 wiki。

另见***.com/questions/2353545/…。

【参考方案1】：

好问题，让我们看看：

（何时开始移植） 这当然取决于要移植的模块的复杂性。如果确实有复杂/大的问题，早点开始可能会很有用，以便在没有压力的情况下找到棘手的地方。对于较小的/标准的，我会尝试找到一个更大的时间段，以便我可以连续移植其中的许多，以便快速记住常规内容（并从可能改进的文档中受益）。

（测试覆盖率） 通常我会说在开始重构/移植之前有一个好的测试覆盖率肯定是可取的。但是鉴于 Drupal-7 通过将测试框架移至核心引入了一个重大变化，我预计无论如何都需要重写大量测试。因此，如果迁移后不需要维护 Drupal-6 版本，我会节省时间/麻烦，并在移植后扩大覆盖范围。

（早期采用者与观望） 从 4.7 版本开始使用 Drupal，我们总是在考虑移植之前至少等待新主要版本的第一个正式发布。对于 Drupal 6，我们在移植我们的第一个站点之前等待视图模块，我们仍然在 Drupal-5 上有一些较小的项目，因为它们工作得很好，而且很难证明我们的客户的额外费用是合理的仍然有维护/安全修复。一天中只有这么多的时间，而且总是有很多待修复的错误、要添加的功能等，所以玩未完成的技术是没有用的，因为还有更多迫在眉睫的事情要做，这将立即使我们的客户受益。现在，如果我们必须维护一个或多个“官方”贡献的模块，这肯定会有所不同，因为提供早期端口将是一件好事。 我在这里有点困惑 - 作为早期采用者肯定会使社区受益，因为有人必须在修复之前发现错误，但另一方面，与错误斗争一小时又一小时几乎没有商业意义如果您稍等片刻，其他人可能已经找到/修复了。只要我必须以此为生，我就需要关注我的资源，努力在服务社区和从中受益之间取得可接受的平衡：-/

（质量标准） “如果它有效，我很高兴”并没有削减它，因为我不想只是暂时的快乐，但明天也是如此。因此，我的质量标准之一是我需要（在某种程度上）确定我足够好地“理解”新概念，以便不仅使事情发挥作用，而且使它们按应有的方式工作。现在这很难更准确地定义，因为在“得到它”之前显然不可能知道一个人是否“得到它”，所以它归结为“是的，它有点工作”与“是的”的直觉/区别，这看起来是对的”，人们不得不承认他经常会在这方面犯错。 也就是说，我正在寻找的一个特别点是“尽早干预”。作为初学者，我经常在主题阶段“事后”调整一些东西，而通过一个或另一个钩子在处理链中更早地应用“修复”会容易得多。所以现在，每当我要在主题层中“调整”某些东西时，我都会故意花一点时间来检查这是否不能在更早的挂钩中更干净/兼容地完成。由于我希望 Drupal-7 添加更多挂钩选项，因此我会特别注意这一点，因为它通常会减少添加新模块时的冲突和突然“破坏”。

（常见的陷阱） 好吧 - 主要是移植到早期，然后发现一个或多个所需模块根本不适用于新版本，或者仅处于 dev/alpha/early beta 状态。所以我会确保首先编译一个完整使用/需要的模块列表，列出它们的移植状态，以及快速检查它们的问题队列。 除此之外，到目前为止，我一直非常对新版本及其改进感到满意，我再次期待 Drupal-7。

（移植时重构） 可以说移植本身就是一个相当大的重构，因此没有必要通过重构与移植无关的东西来增加复杂性。另一方面，如果您已经不得不将您的模块撕成碎片，为什么不利用这个机会对其进行大修呢？我会尝试根据复杂性画一条线——对于大/复杂的模块，我会尽可能直接地做端口，如果需要，稍后再进行更多重构。对于较小的模块，这并不重要，因为引入细微错误的可能性应该很小。

（其他东西） ...需要考虑一下...

---

好的，其他的：

资源需求 - 鉴于某些 Drupal-7 线程，看起来它们可能会上升，因此在移植位于共享/受限主机帐户上的较小站点之前，应评估这一点。

最新版本优先 - 这是相当明显的，并且总是在升级指南中强调，但仍然值得一提：在进行重大升级之前，首先将核心和所有模块升级到最新的当前版本，因为升级代码是很可能依赖于最新的表/数据结构才能正常工作。鉴于 Drupal 的“零碎”，一次一步的更新策略，很难实现能够检测不同的升级前状态并采取相应行动的升级代码。

【讨论】：

有趣 - 不知道我可以通过频繁编辑将我自己的问题提交到社区 wiki - 好吧，我的第一个“应该是 wiki”评论为我服务；）

感谢 Henrik 的广泛回答。我喜欢它并赞成它。我保持这个问题仍然开放只是因为我希望我能收集更多的想法和建议。我会调查社区维基的事情。我还不知道这个功能...暂时：谢谢！