吐槽一下drupal的管理吧！

作为二十年的drupal建站用户与drupal site building expert，从drupal 6开始用起一直到现在，我还是有资格评论一下drupal的。

第一个感觉AI时代drupal落后了。这是第一点。

接着第一点的感觉，就是drupal错失了AI时代，在CMS的架构和内容生成及管理发布投递方面，完全的战略错误了。

这次drupal错过了AI浪潮。但是wordpress就开始利用AI生成来协助小白用户建个人站了。我觉得这次恐怕wordpress要赢了。drupal总是自夸于自己有多少大学，多少政府部门用drupal建站，但是实际上drupal一直在作为CMS还是建站工具之间摇摆不定。

而今年drupal自己发布了新版11版，跟着发布了官方自己操刀的但是相当潦草的drupal-cms。为什么说他潦草呢？他们发行的zip包已经到了11.1.7版本，但是composer command创建的包竟然还是11.1.1。中间有好几个重要的安全更新。所以足以证明drupal的管理团队与技术团队已经完全不在状态了。

还有就是drupal一直在疯狂地追求上新的大版本，而忘了社区自己沉淀的皮肤与模块，都没法那么快的跟进。特别是distribution这种有着复杂的功能模块和皮肤套件，甚至对drupal core都打了很多补丁的，更加难以跟上drupal官方强推的快速迭代。这样子导致很多site builder只能放弃。其实这些是代码和技术层面的，关键是社区的参与人员，maintainer，也逐渐流失了。

drupal建站的顶峰是在drupal 7. 那个时候可以说社区参与的程序员，建站者，文档编辑人员，以及写帖子发博客的人，都是最活跃和最多的。因为drupal 7改掉了很多drupal 6积重难返的先天性毛病，大家看到了希望。modules，themes，distributions，大爆发。可以统计的基于drupal的网站数，google到的指导newbie建drupal网站的博客文章，包括那个程序员社区stackoverflow都很多帖子教人家。drupal 7的一大升级是responsive设计，也就是自适应屏幕的皮肤设计技术。

不过drupal 7的时候drupal错失了占领用户手机屏幕的机会。因为drupal核心管理层，错误地选择了progressive webapp，而不是native app的路径，包括responsive design。drupal从来没有想到要发布一个自己的client app，也就是客户端的app。在每一个公司都app化的时候，drupal还是坚持不做app，做所谓decoupled design，而所谓的native app，有几个技术出现了，但是drupal官方并没有给于足够的支持。所以现在drupal只是一个强大的cms了，大概率不能算一个好的建站工具了。不过也许我要学习一下如何decoupled drupal 然后和重新做一些适合手机的app前端。这个有空慢慢弄吧。

但是drupal的快速迭代导致社区的开发人员逃离是不争的事实。drupal 7火了没两年，drupal核心管理层又坐不住了，要推8,9,10，一下子就把core system的迭代速度提升了。但是很多modules的开发跟不上。比如，date module，这个非常关键的底层module，drupal 8版本就严重迟滞。记得我当初想做一个日期管理的功能，需要用到calendar这个模块，就因为date这个底层没有及时更新，等了两年只得弃疗。如果说drupal 6-drupal 7的升级是巨大的成功，那么drupal 7-drupal 8的升级则是彻底的失败。后来不得不放弃drupal 9，把它做中间过渡，最后以为drupal 10可以定下来做点东西了，他们又推进了drupal 11，而且还退出了一个新的官网，要和过去的说拜拜了。

最为搞笑的是我在drupal社区发帖子抱怨了一下这个情况，他们竟然直接把我封号了。

但是实际上绝大部分的开发者开发的modules，themes，才刚刚适配好drupal 10.4这个最后的稳定版。当然更多的是基本弃疗了。除了更新drupal 7版本的，很多开发者大哥大妹子都不再跟进10和11了。用的顺手的几个distribution也基本弃疗了。

所以现在用的drupal-cms 11，没有什么太多的皮肤可以用，也没有什么太多跟进的modules。

关键还很搞笑的一点，在多次的升级过程中，drupal把core里面的blog和book这种基本功能都给砍掉了。

卧槽！