适用于 Drupal 的 CKEditor TextSelection：切换到 Source 模式时保持光标与选区不丢失
如果你在 Drupal 里编辑内容足够久，很可能遇到过这个小但恼人的工作流断点：你选中一个词或把光标放到某处，切换到 Source 来调整标记（markup），然后……位置就丢了。我做了一个小模块，专门解决这个问题。
这个模块做什么
CKEditor TextSelection 是一个 Drupal 模块，它将 CKEditor 5 的 “Text Selection” 插件集成到 Drupal 的 CKEditor 5 编辑器中。它的核心目标很简单：在 WYSIWYG 与 Source 模式之间切换时，保留光标位置与文本选区 ——并通过滚动把选区带到可视区域，确保你始终看得到选中的内容。
Drupal 作为后端：GraphQL、JSON:API、RESTful，以及隐藏在 API 选择中的昂贵错误
有一次，在一次关于解耦 Drupal 的规划会议进行到一半时，一位 CTO 问我：“所以，我们应该使用哪个 API？”
房间里安静了一秒。前端想要 GraphQL。后端想要 JSON:API。一家集成供应商已经默认会使用 REST。产品负责人只是希望移动应用不要再等待网站发布。
这个小问题通常听起来像是技术问题。其实不是。它是治理问题，是预算问题，有时还是一个披着开发者连帽衫的招聘问题。
Drupal 可以成为解耦产品中非常强大的后端。它已经具备结构化内容、角色、权限、工作流、修订、翻译、媒体处理、分类法以及成熟的模块生态系统。尴尬的部分在于决定这些内容如何离开 Drupal。Drupal 核心原生支持 JSON:API，GraphQL 可通过贡献模块使用，而 Drupal 的 RESTful Web Services 模块仍然是自定义资源式 endpoint 的一个选择。Drupal 自己的解耦文档把这种划分说得很清楚：JSON:API 在核心中，GraphQL 是贡献模块，Drupal 可以通过 API 向外部前端暴露内容。
然而，团队仍然会做出糟糕的选择。
他们选择 GraphQL，因为它听起来现代。他们选择 REST，因为所有人都用过。他们选择 JSON:API，因为它已经存在。这些都不是战略。
如何维护 Drupal 中的超大型菜单
我曾经打开过一个包含数千个链接的 Drupal 菜单，然后眼看着浏览器比我先放弃。严格来说，页面是加载出来了。只是之后的每一次点击，都像是在要求一台老旧打印机解释自己的感受。
从 BigMenu 和 Menu Select 开始
如果一个 Drupal 网站有一个大型编辑菜单，首要问题通常不是架构，而是编辑器界面。当菜单增长到数千个链接时，核心的菜单管理页面可能会变得非常痛苦。BigMenu 通过改变编辑人员浏览和管理菜单的方式来处理这个问题：它不会强行把整棵树加载到页面上，而是在编辑人员需要时，通过 AJAX 打开子树。 https://www.drupal.org/project/bigmenu
使用 AI 自动翻译 Drupal 页面
多语言积压（backlog）有一种特别的“味道”。你周一用英文发布，承诺德语“这周搞定”，到了周五却盯着 47 个已更新页面，根本没法清楚回答：“所以……真实进度到底是什么？”
我见过团队试图用更多流程来解决：表格、翻译工单、每周同步会。一直都能凑合，直到有人在 200 个页面里改了主视觉段落（hero paragraph）。然后你又回到靠猜的状态。
最终对我们有效的方法，是把翻译当作一个生产系统来做：用 TMGMT 进行跟踪与治理，用一个小型自定义模块通过 cron 自动触发任务，再配合一个在后台运行的 AI 翻译器，它可以通过分块（chunking）处理超长字段。
这篇文章从管理者视角出发：产出、风险，以及你应该问团队哪些问题，避免最后变成一个“悄无声息的烂摊子”。
先说清楚：在 Drupal 语境里，“自动翻译”到底是什么意思
如果你想象的是一个魔法按钮，能瞬间把整个网站变成五种语言，那就忘了吧。可靠的版本更慢，也更无聊：
Drupal：用 GLightbox 替换 Colorbox
1 简介
十多年来，Lightbox 插件一直是 Drupal 网站的核心组成部分。它们允许编辑人员在不离开当前页面的情况下，通过覆盖层展示图片、视频和其他媒体内容——这是现代富媒体网站访客所习以为常的一种交互模式。
Colorbox 长期以来一直是 Drupal 生态系统中的首选解决方案。colorbox 贡献模块与 Drupal 的图片字段格式器紧密配合，拥有成熟的 API，并且在社区中具有极高的认知度。然而，随着 Web 的发展，Colorbox 已逐渐显露出其年代感：它依赖 jQuery，负载较重，并且在当代无障碍性方面明显落后。
GLightbox 应运而生——这是一个纯原生 JavaScript（零依赖）的 lightbox 库，拥有精致的 UI、强大的无障碍支持以及极轻量的体积。对应的 Drupal 模块可以无缝集成到此前由 Colorbox 处理的相同图片字段和媒体实体中。
为 CKEditor 5 重写 CKEditor 4 插件
在 DrupalBook，我们支持那些将编辑体验视为业务关键要素的 Drupal 平台，而不是事后才考虑的技术细节。当 Drupal 从 CKEditor 4 过渡到 CKEditor 5 时，引入了现代化的编辑基础，但同时也为依赖成熟 CKEditor 4 插件的组织带来了显著空缺。本文将说明我们如何通过迁移关键功能来弥补这一差距，在保障编辑团队工作连续性的同时，使客户能够顺利推进到现代版本的 Drupal。
CKEditor 5 中缺失的插件
从 CKEditor 4 到 CKEditor 5 的转变并不是一次常规升级，而是对编辑器架构的彻底替换。从管理角度来看，这意味着许多熟悉的插件突然无法继续使用，其中包括编辑人员多年来每日依赖的工具。在多个客户项目中，这些缺失的插件已经深度嵌入到内容工作流、培训资料和质量标准中。移除它们将会降低生产效率、增加出错率，并削弱编辑团队对平台的信任。
多语言 Drupal 的内容建模：按模块翻译，而非按页面翻译
基于 Jenkins 和 GitLab CI 的 Drupal CI 驱动配置管理
1. 为什么由 CI 驱动的配置管理至关重要
Drupal 的配置系统是该平台最大的优势之一 —— 同时也是最可靠的痛点来源之一。能够将站点中的每一项配置以 YAML 文件的形式进行导出和导入，这一能力非常强大，但前提是团队成员对谁负责在各个环境之间移动这些文件达成一致。在大多数团队中，这种共识从未真正存在。
任何发布过 Drupal 站点的人都熟悉以下经典问题：
将 Drupal 7 升级到最新版本的 Drupal
尽管 Drupal 7 的官方支持已经结束，不再提供新的更新，且所有新模块都仅针对 Drupal 11+ 版本发布，但目前仍有大量网站在使用 Drupal 7，且无法迁移到新版本。这其中有诸多原因，尤其是对于拥有大量自定义代码的网站而言更是如此。
使用 Claude Code、Codex、Copilot
在关于将 Drupal 7 升级至最新 Drupal 版本的文章中，有必要指出，像 Claude Code、Codex 和 Copilot 这样的现代 AI 工具，可以成为团队非常有价值的助手，并有效降低项目的整体复杂度。即使读者不深入了解技术细节，也能理解这些工具的核心价值：它们可以帮助更快地理解网站的旧代码结构，谨慎地将现有业务逻辑迁移到平台的新版本，并在升级过程中减少错误数量。通过自动提供更现代、更安全的解决方案，提示系统中需要修改的部分，以及加速日常开发的重复性工作，这些工具最终可以缩短迁移周期，使过程更加可预测，简化管理层的控制，并让团队专注于业务目标的实现，而非技术难题本身，从而确保网站在升级到新版 Drupal 后的稳定运行。