我曾经打开过一个包含数千个链接的 Drupal 菜单，然后眼看着浏览器比我先放弃。严格来说，页面是加载出来了。只是之后的每一次点击，都像是在要求一台老旧打印机解释自己的感受。

从 BigMenu 和 Menu Select 开始

如果一个 Drupal 网站有一个大型编辑菜单，首要问题通常不是架构，而是编辑器界面。当菜单增长到数千个链接时，核心的菜单管理页面可能会变得非常痛苦。BigMenu 通过改变编辑人员浏览和管理菜单的方式来处理这个问题：它不会强行把整棵树加载到页面上，而是在编辑人员需要时，通过 AJAX 打开子树。 https://www.drupal.org/project/bigmenu

多语言积压（backlog）有一种特别的“味道”。你周一用英文发布，承诺德语“这周搞定”，到了周五却盯着 47 个已更新页面，根本没法清楚回答：“所以……真实进度到底是什么？”

我见过团队试图用更多流程来解决：表格、翻译工单、每周同步会。一直都能凑合，直到有人在 200 个页面里改了主视觉段落（hero paragraph）。然后你又回到靠猜的状态。

最终对我们有效的方法，是把翻译当作一个生产系统来做：用 TMGMT 进行跟踪与治理，用一个小型自定义模块通过 cron 自动触发任务，再配合一个在后台运行的 AI 翻译器，它可以通过分块（chunking）处理超长字段。

这篇文章从管理者视角出发：产出、风险，以及你应该问团队哪些问题，避免最后变成一个“悄无声息的烂摊子”。

先说清楚：在 Drupal 语境里，“自动翻译”到底是什么意思

如果你想象的是一个魔法按钮，能瞬间把整个网站变成五种语言，那就忘了吧。可靠的版本更慢，也更无聊：

1 简介

十多年来，Lightbox 插件一直是 Drupal 网站的核心组成部分。它们允许编辑人员在不离开当前页面的情况下，通过覆盖层展示图片、视频和其他媒体内容——这是现代富媒体网站访客所习以为常的一种交互模式。

Colorbox 长期以来一直是 Drupal 生态系统中的首选解决方案。colorbox 贡献模块与 Drupal 的图片字段格式器紧密配合，拥有成熟的 API，并且在社区中具有极高的认知度。然而，随着 Web 的发展，Colorbox 已逐渐显露出其年代感：它依赖 jQuery，负载较重，并且在当代无障碍性方面明显落后。

GLightbox 应运而生——这是一个纯原生 JavaScript（零依赖）的 lightbox 库，拥有精致的 UI、强大的无障碍支持以及极轻量的体积。对应的 Drupal 模块可以无缝集成到此前由 Colorbox 处理的相同图片字段和媒体实体中。

在 DrupalBook，我们支持那些将编辑体验视为业务关键要素的 Drupal 平台，而不是事后才考虑的技术细节。当 Drupal 从 CKEditor 4 过渡到 CKEditor 5 时，引入了现代化的编辑基础，但同时也为依赖成熟 CKEditor 4 插件的组织带来了显著空缺。本文将说明我们如何通过迁移关键功能来弥补这一差距，在保障编辑团队工作连续性的同时，使客户能够顺利推进到现代版本的 Drupal。

CKEditor 5 中缺失的插件

从 CKEditor 4 到 CKEditor 5 的转变并不是一次常规升级，而是对编辑器架构的彻底替换。从管理角度来看，这意味着许多熟悉的插件突然无法继续使用，其中包括编辑人员多年来每日依赖的工具。在多个客户项目中，这些缺失的插件已经深度嵌入到内容工作流、培训资料和质量标准中。移除它们将会降低生产效率、增加出错率，并削弱编辑团队对平台的信任。

1. 为什么由 CI 驱动的配置管理至关重要

Drupal 的配置系统是该平台最大的优势之一 —— 同时也是最可靠的痛点来源之一。能够将站点中的每一项配置以 YAML 文件的形式进行导出和导入，这一能力非常强大，但前提是团队成员对谁负责在各个环境之间移动这些文件达成一致。在大多数团队中，这种共识从未真正存在。

任何发布过 Drupal 站点的人都熟悉以下经典问题：

尽管 Drupal 7 的官方支持已经结束，不再提供新的更新，且所有新模块都仅针对 Drupal 11+ 版本发布，但目前仍有大量网站在使用 Drupal 7，且无法迁移到新版本。这其中有诸多原因，尤其是对于拥有大量自定义代码的网站而言更是如此。

使用 Claude Code、Codex、Copilot 

在关于将 Drupal 7 升级至最新 Drupal 版本的文章中，有必要指出，像 Claude Code、Codex 和 Copilot 这样的现代 AI 工具，可以成为团队非常有价值的助手，并有效降低项目的整体复杂度。即使读者不深入了解技术细节，也能理解这些工具的核心价值：它们可以帮助更快地理解网站的旧代码结构，谨慎地将现有业务逻辑迁移到平台的新版本，并在升级过程中减少错误数量。通过自动提供更现代、更安全的解决方案，提示系统中需要修改的部分，以及加速日常开发的重复性工作，这些工具最终可以缩短迁移周期，使过程更加可预测，简化管理层的控制，并让团队专注于业务目标的实现，而非技术难题本身，从而确保网站在升级到新版 Drupal 后的稳定运行。

为什么会有这个变更？

• 在 Drupal 9 中，jQuery Cookie 被从核心中移除，并由 js-cookie 库取代。在 Drupal 9 期间曾提供一个兼容性垫片（core/jquery.cookie），但在 Drupal 10 中被移除。
  https://www.drupal.org/node/3104677
• 在 Drupal 10.1 中，core/js-cookie 资产库本身被弃用，并计划在 Drupal 11 中删除，因为核心不再使用它。变更记录建议切换到贡献模块 JS Cookie。
  https://www.drupal.org/node/3322720

本部分介绍如何将 Drupal 内核从以前的版本（包括旧版 Drupal 6 和 Drupal 7）更新到最新的稳定版本。我还会在这里发布有关如何更新 Drupal 贡献模块的文章。

Drupal 的 CKEditor 模块将停止支持 CKEditor 4。不过，您仍然可以通过自定义模块集成 CKEditor 4，并继续使用它。当然，使用新版 CKEditor 5 或更高版本会更好，但仍有超过 14 万个网站在使用 CKEditor 的旧版模块（每四个 Drupal 网站中就有一个！）。

https://www.drupal.org/project/ckeditor

我需要提前说明的是，对匿名用户使用 CKEditor 4 并不安全。如果您允许匿名用户在网站上发表评论或创建页面（例如在 bug 跟踪系统中提交 issue），那么您别无选择，只能使用 CKEditor 5。