Drupal 12 定于 2026年12月7日那一周发布，而 Drupal 10 在 2026年12月9日走到生命周期终点。这两个日期就写在 Drupal 核心发布计划的同一页上，相隔不过两行，可是绝大多数正在运行 Drupal 10 站点的人两个都没注意到。新大版本的第一个 alpha 已经在 2026年9月2日打上标签，所以这次发布的形状现在是记录在案的事实，不再是猜测。 这场撞车就是全部故事。一个大版本发布，对站点所有者来说通常并不紧急，因为你可以在旧的大版本上坐一两年，等生态跟上来。这一次不同，旧的大版本在新版本发布的同一周停止收到安全公告，于是一个技术事件变成了一个带着合规锋刃的截止日期。...
软件开发
关于软件开发的文章、指南和教程，为开发者和企业提供实用知识与技巧。面向开发者与技术团队。
Salesforce 集成几乎从来不是败在协议上。认证是已经解决的问题，写入一条记录也是已经解决的问题。真正把项目拖垮的，是每天的请求配额和数据模型的形状，而这两件事通常要等到上线大约三周之后才被发现，那时夜间作业开始返回错误，却没有人说得清它在测试环境里为什么是好的。 这个模式一致到可以预测。开发者对着一个 Developer Edition 组织开发，一切通过，客户签字验收。随后这套代码遇上的，是一个已经住着营销连接器、数据仓库抽取作业和一个 2019 年就在跑的 Apex 触发器的生产组织，而那份看起来很宽裕的请求预算，其实是别人早已在花的一口共用的锅。 这篇文章把意外提前摊开来讲：你应该用哪个 API、配额是怎么算的、当你的...
大多数 WordPress 插件开发都沿着同一条弧线走。有人需要一个预约表单、一个内容抓取器,或者结算页上的一个额外字段,开发者写了出来,它能用,大家各自忙别的去了。两年后,这个站点被困在一个旧版本的 WordPress 上,因为没人有把握那个插件能挺过一次更新,而写它的人早就走了。 原因很少是核心跑得太快。WordPress 在破坏兼容这件事上非常保守,五年前写得像样的插件,今天不改一行仍然跑在 WordPress 7.1 上。插件会坏,坏在头一个星期定下的几个决定:功能被放进了主题,该挂钩子的地方直接改了核心文件,数据被塞进了手边最方便的结构,以及从来没有人拿候选发布版试过。 一个定制 WordPress 插件靠什么才能扛住核心...
CMS 迁移属于少数几类项目：技术活可以做得毫无差错，结果却仍然是一场灾难。站点按期上线，样子更好看，加载也更快，流量却掉了一半，原因是几百条网址换了形状，而没有人去做那张对照表。技术验收一项项全过，商业结果却是负的。 丢掉的流量并不是新平台造成的，而是断裂造成的：以前能响应的地址现在不再响应，以前能被认出来的页面现在看起来像全新的，多年积累在旧网址上的历史也失去了去处。而且排名往往不是上线当天就掉下去，而是在随后的几周里慢慢往下沉，所以上线当天看着一切正常，并不能说明任何问题。 决定结果的只有一个判断：你要保留 URL 结构吗？ 如果保留，迁移基本上就是一件内容和模板的活儿，风险有限。如果不保留，每一条变动过的地址都需要一条指向其...
故障复盘很容易开起来，很难做得有用。会开了，文档写了，四条改进项记下来了，六个月后同一个故障又发生一次，而某个人正好在找别的东西时翻出了那份旧文档。 在讨论这件事时，注意力几乎都落在"无指责"这个词上。这条原则确实重要，但失效的地方并不在那里。有大量组织把无指责执行得一丝不苟，复盘却什么也没有改变，原因很简单：他们把复盘本身当成了交付物，而不是当成产出交付物的手段。 判断你们的复盘是否有效，有一个简单到让人难堪的测试：过去六个月记录下来的改进项，实际完成的比例是多少？ 如果答案是"大部分"，那么无论流程长什么样，它都在起作用。如果低于一半，你们是在开会而不是在运行一个流程，换更漂亮的模板也救不了。少数几条带负责人和期限的事项，胜过一...
密码存储是软件里少数几个真正存在标准答案的领域之一。答案早就公开了，一直有人维护，而且免费。可它同时又是最经常被做错的领域之一，原因很简单：那些错误的做法在某个年代确实是正确的，而后来没有人再回头看过一眼。 失败的样子很少稀奇。通常就是一套 2016 年按照 2012 年的建议搭起来的系统，到今天还在跑，还在接受登录请求，而自从当初写下那段哈希代码的人离职之后，就再也没有人打开过那个函数。它没出过故障，也没被审计过，所以从来不在任何人的待办清单上。 如果只带走一句话：用 Argon2id，实在不行就用 bcrypt。 本文其余部分都是细节。像 SHA-256 这样的通用哈希函数，无论你把它套用多少次，都不是密码哈希。它的快是设计目...
软件供应链安全听上去像是那些设有专职安全团队的大机构才需要操心的事，而正是这种定位把人带偏了。一个只维护少数几个服务的小团队，通常也依赖着几百个包，其中没有一个是团队里有人真正读过的。这些包在构建时从团队并不掌控的包仓库里拉取，然后在存放着部署凭据的机器上执行安装脚本。 暴露面并不随公司规模等比增长。它随依赖数量和构建自动化程度增长，而小团队往往前者更多、后者更少有人盯着，处境比那些公开讨论这件事的大机构还要吃紧一些。 令人不适的算术： 你的应用大概有十几个直接依赖，以及几百个间接依赖。这十几个是你自己挑的。剩下的不是，你一个都没读过，而其中任何一个只要执行安装脚本，拿到的权限就和你的构建进程完全一样。这才是真实的攻击面，而在你亲手...
技术文档的失败方式非常具体，也非常好预测。有人在两周清闲的时间里写下一大堆，接着系统变了，没有人回头更新，一年之内那份文档就开始信心十足地讲着错误的内容。到了那个时候，它比什么都没有还要糟，因为相信它的读者会依据早已不成立的信息去动手。 常见的反应是号召大家多写一些，而这只会让同样的失败来得更快。有用的反应是少写，并且认真挑选写什么，因为真正的瓶颈不是写作的工夫，而是维护的工夫。文档从写完那一刻起，就开始被现实甩在后面。 判断一份文档该不该存在，唯一经得起时间的检验是： 当它变错的时候，会不会有人察觉？部署指南天天有人用，错误立刻就会浮出来。一份二十页的子系统说明只会被读一次，它的错误要等到十八个月后，有人照着它动手时才浮出来。没有...
开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。 延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。 唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。...
软件源代码托管，也就是把源代码交给中立的第三方保管（英文称为 software escrow），回应的是一种完全合理的担忧：为你构建并运维关键系统的供应商倒闭了，而你手上留下的，是一个自己离不开、却又维护不了的东西。托管协议把源代码存放在第三方那里，一旦真的发生这种情况，第三方就把它交付给你。 这种担忧是站得住脚的。问题在于这项工具经常被误解，而两者之间的落差催生出一类协议：每年都在花钱，真到需要它的那一天却帮不上忙。 签字之前应该先问的那个不舒服的问题： 如果明天就把代码交到你手上，你这边真的有人跑得起来吗？一份没有构建说明、没有基础设施定义、没有它所调用的第三方服务凭据、也没有数据的源代码托管，不是业务连续性方案。那只是一个文件...