成功的 Drupal 7 到 9 迁移背后的科学（以及其中一些失败的原因）

还记得贵公司的每个人都喜欢（或至少容忍）您被迫迁移到新系统的伟大网站吗？ 而你信任的团队可能会咬得比他们能咀嚼的更多？ 曾经可能是一个完美的外观和功能的网站，现在变成了一堆奇怪的问题、性能不佳，或者有时，一个几乎无法使用的网站。

如果这听起来很熟悉，并且在将 Drupal 7（或 6）站点升级到 Drupal 9（或 8）后遇到了奇怪的问题，请阅读本文直到最后。 我们将探讨站点所有者在将 Drupal 7（或 6）升级到 Drupal 9（或 8）后面临的常见问题以及如何解决这些问题。 这不会涵盖我们在进行迁移救援时看到的所有问题，但至少应该让您达到晚上可以入睡的程度。

Drupal 7 到 9 升级 - 基本挑战

您可能会问自己的第一个问题是：“为什么？” 从平台的角度来看，从 Drupal 7 升级到 Drupal 9（Drupal 8 现已被淘汰）似乎不应该那么难。

好吧，Drupal 8 改变了一切。 它进行了全面的架构大修，因此 CMS 可以更具可持续性、相关性并且从长远来看更容易掌握。 它采用了现代技术和框架，如面向对象编程、Symfony、Twig、最新的 PHP 版本等等，还允许 Drupal 社区通过提供更广泛的技能来帮助构建 Drupal，从而呈指数级增长。 这意味着，现在更容易找到专家来构建和维护您的 Drupal 网站。 好消息是，在初始迁移之后升级到任何未来版本的 Drupal（如 Drupal 8 到 Drupal 9）都非常容易，并且不需要重建。

但是回到手头的问题，许多组织仍在从Drupal 7 迁移到 9 ，这确实涉及网站的完全重建。 重建本身足够复杂，无需维护当前的内容结构，它可以让最有经验的开发人员适应。 在大多数情况下，大型网站需要更多关注，因为它们往往有多个贡献和自定义模块，没有直接的升级路径。 所有这些共同为错误打开了无限的机会。

对于没有尝试过此类迁移的团队，通常情况下，第一个 Drupal 7 到 9 迁移错误是缺乏准备。 成功迁移 Drupal 的第一步也是最重要的一步是进行彻底的迁移审计，以分析当前网站结构的每一个细节。 该报告不仅可以帮助您评估迁移的影响，还可以让您深入了解需要改进的领域。 下一个最重要的步骤是决定是否允许专门的 Drupal 开发合作伙伴（日复一日地使用 Drupal 的人）进行迁移。 就像您更喜欢心脏外科医生而不是整形外科医生进行搭桥手术一样； 拥有一家专注于 Drupal 的专业公司来构建您的 Drupal 网站将导致成功迁移。

常见的 Drupal 7 到 9 迁移挑战

在从 Drupal 6/7 迁移到 8/9 之后，最常见的挫折来源之一是在处理问题时不知道从哪里开始。 无论有没有编码技能，你如何找出真正的问题所在？ 简单 - 检查您的错误日志。 我知道，听起来您正在打开另一罐蠕虫试图理解日志所说的内容，但我们将引导您了解下面的常见问题。

让我们直接深入探讨 Drupal 站点所有者在从 Drupal 7 迁移到 Drupal 9 后面临的一些最常见问题。

网站几乎没有启动/损坏

1. 服务器问题：如果您没有足够的权限访问您的服务器，您的服务器可能会受到威胁。 深入了解错误日志将帮助您了解问题的根源。 如果是服务器问题，请确保您有足够的权限访问您的服务器。 如果您遇到空间短缺问题，请联系您的托管服务提供商以增加您的内存限制。 如果这没有帮助，请向他们提出一张票，并提及您的服务器问题。
2. 自定义代码：如果您的 Drupal 6/7 网站比预期的更复杂，那么可能不是在迁移之前评估自定义代码并正确映射它们，而是执行简单的提升和转换。 如果您在页面加载时触发了自定义条件，并且没有找到与之关联的自定义代码，那么您最终会得到一个损坏的页面。 首先要做的是检查您是否在迁移审核中正确评估了网站（如果您这样做了），以检查自定义模块和代码。 如果问题是由于自定义条件造成的并且缺少代码，您将需要 Drupal 开发人员来创建自定义代码实现。 理想情况下，应该在迁移任何内容之前创建自定义代码。
3. Core/Contrib 模块：有时您可能会在已经有解决方案/补丁的核心或贡献模块上遇到已知问题。 一些研究可以帮助确定这一点。 找到并应用补丁，你应该很高兴。
4. 过时的 PHP 版本/库：您的新 Drupal 站点可能仍在运行旧版本的 PHP 或您的代码所依赖的库。 确保您的网站实现了最新版本的 PHP 和其他库。 还要检查是否满足所有系统要求和配置。

无法编辑页面（权限问题）

1. 500 错误：如果您因为遇到 500 内部服务器错误而无法编辑页面，这可能是由于各种原因（配置错误、代码错误、索引错误、聚合等）。 但是，更常见的原因之一是它可能是由于字段格式之间的不匹配或缺少字段。 例如，如果您的 Drupal 7 站点中的日期字段未以正确的格式迁移，或者该值未转换为 Drupal 9 格式，则会引发错误。 另一个例子是，如果在 Drupal 7 中您一直使用图像字段，但在 Drupal 9 中，您使用的是媒体字段。 解决此问题的最佳方法是纠正迁移脚本以正确存储数据。 如果只有几个字段要编辑，您还可以创建挂钩更新。
2. 403 错误：通常，403 错误是因为权限转移不正确。 检查权限是否设置正确。 如果您使用一个模块来管理您的用户，请检查它在 Drupal 9 中是否可用。有时，您可能有挂钩或事件订阅者限制对某些用户的访问。 检查这些条件并确保它也在您的新安装中实施。
3. 权限页面没有响应：您的 Drupal 站点可能正在实施一些自定义代码来处理权限。 如果此代码未在新的 Drupal 9 站点中实现，您可能无法查看或编辑（或两者）权限页面。 有时，我们会看到在没有正确迁移其角色和用户配置文件的情况下批量迁移用户的情况。 作为标准做法，在迁移权限之前，开发人员应创建自定义权限并将其分配给人员/权限中的角色。

糟糕的网站性能

1. 不必要的模块：模块是您的 Drupal 站点的构建块，因此您也需要迁移它们。 但有时我们会看到过时的不必要的 Drupal 7 模块移至 Drupal 9，这可能会导致各种问题。 特别是因为它们会影响您的网站。 以下是您的某些模块不需要迁移的一些原因：
   • 该模块（或其功能）已移至 Drupal Core。 例如，媒体贡献模块在 Drupal 8.5 中移至核心，这消除了使用贡献模块的需要。
   • 它的功能很简单，可以插入到另一个自定义模块中。 例如，如果 node::postSave 模块仅用于一种或两种内容类型，以便在创建节点后选择用户应该去哪里，则可以将代码移至自定义模块。
   • 模块的要求需要重新评估。 有时，可用性的微小变化可以极大地提高网站性能。 例如，除非内容营销团队庞大且分散，否则所有网站都不需要内容审核模块。 Drupal 的核心编辑工作流功能（草稿、发布）足以满足大多数不需要复杂/详细工作流的业务需求。
   • 有时，子模块与模块一起安装，但很少/从不使用。 应删除此类子模块。
2. 复制相同的架构：虽然简单地举起手来转移并从迁移中掸去灰尘会更容易，但它几乎从来都不是一个好方法。 特别是如果较旧的（Drupal 6/7）架构混乱且不够健壮。 业务逻辑/需求的变化也可能需要完全重新架构。 彻底的现场审核将准确告诉您需要保留哪些模块以及可以安全删除哪些模块。

第三方集成不再有效

1. 过时的 API 版本：如果您的网站连接到不同的第三方工具，如 Salesforce、Marketo、Mailchimp 等，执行不当的迁移可能会影响这些集成的工作方式。 通常是您在 Drupal 集成模块中调用的 API 是旧版本。 唯一的解决方法是集成应该用最新版本的第三方 API 编写。
2. 集成模块问题：您需要检查第三方 API 是否在集成模块中被正确调用。 参数是否正确传递？ 检查它们是如何设置和检索的。 检查该集成模块的问题队列。 可能有需要应用的可用补丁。 需要进行适当的测试以确保 API 已正确移植到 Drupal 9。

其他常见问题和修复

1. 模块安装：始终使用 composer 安装模块。 这将避免由于无效/不可用依赖项导致的错误。
2. 迁移源不匹配：无论您的迁移源是什么（CSV、数据库、JSON、XML），请确保源字段与目标字段匹配。 如果您使用 CSV 作为源，请记住导入顺序 - 映射内容类型的优先级很重要。
3. 图片路径：很多时候，用户直接在 CKEditor 内容中添加图片。 这些图像在迁移时并不总是转到指定的路径，因为它们的位置通常与其他媒体文件所在的位置不同。 精心计划的迁移应该解决这个问题。
4. SEO：疏忽的 Drupal 7 到 9 迁移会以多种方式影响您网站的 SEO。 最重要的问题之一是链接断开。 确保保留现有的 URL 结构和导航，因为任何更改都可能导致大量断开的链接。 需要进行完整的 SEO 审核，以确保道路上没有颠簸。
5. Drupal 7 风格：经常会出现 Drupal 7 到 Drupal 9 的迁移问题（尤其是性能问题），因为开发人员使用与 Drupal 7 相同的编码风格，而不是适应 Drupal 8 带来的变化。示例， （a）你杀死的方式页面缓存在 Drupal 8 中非常不同。 (b) Drupal 8 具有内置的配置管理，但它通常没有以正确的方式实现或在每个环境中都没有得到很好的维护。 (c)我们还遇到了 Drupal 8 项目仍在实施过程代码样式的实例。