Drupal 的 AI 已经不再是一堆按厂商拆开、谁需要谁自己挂上去的贡献模块。它现在是一个有抽象层托底的统一项目,有安全团队覆盖的发布周期,并且在 Drupal CMS 里被打包成产品,在安装过程中主动问你要不要把其中一部分打开。值得问的问题已经从 Drupal 能不能做 AI,变成了哪些部分值得打开,以及当四位编辑每个工作日都在用它时,每一项功能到底要花多少钱。 多数文章讲到演示就停了。有人敲一段提示词,页面出现了;你看着聊天机器人建出一个内容类型。演示本身是真的。它没有告诉你的是,编辑点下那个按钮的瞬间有什么离开了你的基础设施,清单上的模块里哪些从来没有发布过稳定版,以及哪一条预算真的会涨。 Drupal AI 给企业带来了什...
文章
在一个页面浏览所有文章。查找关于人工智能、编程、安全、基础设施与 Web 开发的教程、深度解读、指南与更新。
“Drupal 很慢”这个名声，绝大部分来自主机托管，而它几乎总是一个采购决定，而不是软件问题。站点被认真地做了出来，然后上线在一个按“几个 PHP 文件的宣传册站点”定价的套餐上。结果就是：一套带着正经渲染管线的内容管理系统，跑在一个自己改不了的内存上限里，跑在一个自己控制不了的操作码缓存上，还没有一个能运行自身工具的命令行。 人们心里拿来对比的是 WordPress，而这个对比是错的。WordPress 几乎在任何环境下都能凑合跑，是因为它的市场份额逼着主机商把它做成几乎在任何环境下都能凑合跑。Drupal 的前提不同：它假定你有较新的 PHP、较新的数据库、真正的缓存后端、一个命令行，以及一套把代码库当成构建产物而不是当成“可...
在开源 CMS 的世界里，Drupal 安全是少数几个公开流程好过平台名声的领域之一。Drupal 安全团队按固定的披露时间表运作，用一套有据可查的数值标准为每一份公告评分，并在核心与数以万计的贡献项目之间协调修复。 现实中的战绩配不上这套流程。Drupal 站点确实会被攻破，而原因几乎从来不是没有人知道。公告准时发布了，就在某个星期三。补丁则在下一周才进入生产环境。这篇文章要谈的正是那段空档，而安全加固、防火墙与文件权限的存在，都是为了让这段空档变得可以熬过去，或者把它缩短。 决定风险的是你打补丁的速度，而不是你恰好装了哪些模块。 核心公告落在每月一次的星期三窗口，贡献项目公告则是每周三，两者都依据一套公开的标准评为 0 到 25...
Drupal SEO 的名声并不完全配得上它的实力。随便问一圈，总会有人告诉你 Drupal 开箱即用就很适合搜索，而说这话的人往往是在拿十五年前对另一个平台的记忆做比较。一套原装的 Drupal 11 安装，既没有元描述字段，也没有 XML 站点地图，URL 变更时没有自动重定向，而且在编辑手动敲入别名之前，内容一直在 /node/123 上响应。 这不是在批评这个项目。核心刻意把自己的范围保持得很小，把一切带有立场的东西推给贡献模块，而这恰恰是大型 Drupal 站点能比多数平台调得更精细的原因。但这也意味着开箱即用这个说法承担了非常多的分量，意味着一个 Drupal 站点的搜索表现，几乎完全取决于第一天装了哪些模块，以及有谁把...
CMS 迁移属于少数几类项目：技术活可以做得毫无差错，结果却仍然是一场灾难。站点按期上线，样子更好看，加载也更快，流量却掉了一半，原因是几百条网址换了形状，而没有人去做那张对照表。技术验收一项项全过，商业结果却是负的。 丢掉的流量并不是新平台造成的，而是断裂造成的：以前能响应的地址现在不再响应，以前能被认出来的页面现在看起来像全新的，多年积累在旧网址上的历史也失去了去处。而且排名往往不是上线当天就掉下去，而是在随后的几周里慢慢往下沉，所以上线当天看着一切正常，并不能说明任何问题。 决定结果的只有一个判断：你要保留 URL 结构吗？ 如果保留，迁移基本上就是一件内容和模板的活儿，风险有限。如果不保留，每一条变动过的地址都需要一条指向其...
故障复盘很容易开起来，很难做得有用。会开了，文档写了，四条改进项记下来了，六个月后同一个故障又发生一次，而某个人正好在找别的东西时翻出了那份旧文档。 在讨论这件事时，注意力几乎都落在"无指责"这个词上。这条原则确实重要，但失效的地方并不在那里。有大量组织把无指责执行得一丝不苟，复盘却什么也没有改变，原因很简单：他们把复盘本身当成了交付物，而不是当成产出交付物的手段。 判断你们的复盘是否有效，有一个简单到让人难堪的测试：过去六个月记录下来的改进项，实际完成的比例是多少？ 如果答案是"大部分"，那么无论流程长什么样，它都在起作用。如果低于一半，你们是在开会而不是在运行一个流程，换更漂亮的模板也救不了。少数几条带负责人和期限的事项，胜过一...
密码存储是软件里少数几个真正存在标准答案的领域之一。答案早就公开了，一直有人维护，而且免费。可它同时又是最经常被做错的领域之一，原因很简单：那些错误的做法在某个年代确实是正确的，而后来没有人再回头看过一眼。 失败的样子很少稀奇。通常就是一套 2016 年按照 2012 年的建议搭起来的系统，到今天还在跑，还在接受登录请求，而自从当初写下那段哈希代码的人离职之后，就再也没有人打开过那个函数。它没出过故障，也没被审计过，所以从来不在任何人的待办清单上。 如果只带走一句话：用 Argon2id，实在不行就用 bcrypt。 本文其余部分都是细节。像 SHA-256 这样的通用哈希函数，无论你把它套用多少次，都不是密码哈希。它的快是设计目...
软件供应链安全听上去像是那些设有专职安全团队的大机构才需要操心的事，而正是这种定位把人带偏了。一个只维护少数几个服务的小团队，通常也依赖着几百个包，其中没有一个是团队里有人真正读过的。这些包在构建时从团队并不掌控的包仓库里拉取，然后在存放着部署凭据的机器上执行安装脚本。 暴露面并不随公司规模等比增长。它随依赖数量和构建自动化程度增长，而小团队往往前者更多、后者更少有人盯着，处境比那些公开讨论这件事的大机构还要吃紧一些。 令人不适的算术： 你的应用大概有十几个直接依赖，以及几百个间接依赖。这十几个是你自己挑的。剩下的不是，你一个都没读过，而其中任何一个只要执行安装脚本，拿到的权限就和你的构建进程完全一样。这才是真实的攻击面，而在你亲手...
多语言 SEO 通常被讲成一个翻译问题，外加一点技术标记。但把这个站点用十二种语言运营下来，也就是英语、阿拉伯语、德语、法语、匈牙利语、意大利语、日语、韩语、罗马尼亚语、越南语，加上中文的两种书写形式，我们很清楚地看到：翻译才是简单的那一半。 难的那一半在于，你在英语里习以为常的每一条规则，都有一个依文字系统而变的版本，而你原本并不知道它存在。长度上限不一样。结构会跑偏。数字会被一个想帮忙的译者写成汉字，从那一刻起就不再和原文对得上。这些问题在有东西去检查之前，一律看不见。 真正让它跑起来的是自动化，不是努力。 在任何内容上线之前，有十一项独立检查会从头到尾扫一遍：语言覆盖率、原文与各译文之间的结构一致、数字一致性、标题层级顺序、死...
在多数已经运营了一段时间的网站上，内容更新是回报率最高的一项工作，而它之所以不受欢迎，正是因为做完之后没有任何东西可以拿出来宣布。修改一篇已经有排名的文章，感觉像是在做维护。发布一篇新文章，感觉像是在往前走。数字通常不同意这种感觉。 原因在于，一个已经存在的页面早就积累了那些昂贵的东西：外部链接、抓取历史，以及与一组搜索词之间被验证过的关系。新页面从零开始，什么都没有，要花上好几个月才能挣到旧页面早已拥有的东西。而改进旧页面，是直接叠加在这份积累之上。 会让整件事白做的错误，是只改日期，别的什么都不改。 这种做法足够常见，值得把话讲明白。一个把新鲜度纳入考虑的检索系统，比较的是内容而不是时间戳，一个日期动了、实质却原封不动的页面，除...