Tag Archives: MT

Movable Type 是如何被 WordPress 超越的?

前几天有一位网志⁽¹⁾读者发来反馈，我的个人站点文章分类的分页功能出了问题。读者的意见不能不重视，于是花了一点时间修复了一下。作为国内少数还在使用 Movable Type (MT) 作为网志发布工具的用户，处理的过程中不由使我再次涌起迁移到 WordPress (WP)的冲动，到现在 MT 甚至都不具备一个良好的原生的分页机制，不得不再次借助于第三方的插件来做到。不管承认与否，Movable Type 已经被 WordPress 全方位的无情的超越。如今的 Movable Type，已经不像当年那样被人津津乐道，甚至被 VideoEgg 收购的消息都没引起多大的反响。这是怎么一回事? 这几年发生了什么？在这个时间回顾一下，或许别具意义。

Movable Type 是如何被 WordPress 超越的？

让我们回到 2001 年，短暂无业闲暇中的 Perl 工程师 Ben Trott 为了满足妻子 Mena Trott 在网上书写的热情而创作了 Movable Type，9 月份作为个人项目发布了 Movable Type(这个单词也是”活字印刷”的意思)初始版本，10月份发布了 1.0 版本(Refer)。很快，免费（严格来说是 Donation-Ware 的版权形式）而精致优雅的 Movable Type 赢得了不少用户，引起了业界广泛注意。Ben 夫妇的夫妻店名为 Six Apart , 这个名字的由来据说是因为两个人的生日相差六天，和什么”六度分割”理论没什么直接联系。2004 年拿到第二轮融资。2003 年，Ben 夫妇二人拿到了来自伊藤穰一(Joi Ito) 的第一笔风险投资，2004 年拿到第二轮融资。资本一旦进入，情况似乎就发生了变化。在 2004 年发布的 3.0 版本引发了轩然大波，Six Apart 短视的将 Movable Type 的版权进行了调整，打算开始收费，这一杀鸡取卵的举措引来了大量用户的不满与诟病，从而使得不少用户转投当时并不成熟的 WordPress 的怀抱。到现在为止，我们似乎得到了 Movable Type 落败的第一个原因：错误的时机采用了错误的收费策略。

WordPress 的最初发展过程似乎没有什么秘密可言，在维基百科上可以找到关于 WordPress 发展的方方面面的信息。当时只有 19 岁的的 Matt Mullenweg 在 b2/cafelog 的基础上开发了 WordPress，遵循 Web 标准，于 2003 年 5 月以 GPL 版权形式发布。随后的两年中，Matt 被 CNET 雇佣，退学，在几位 WordPress 开发者的努力下推出了 1.5 这个重要的版本，2005 年 Matt 从 CNET 离职而全力投入 WordPress 项目，正式成立了 Automattic，随后发布了 Akismet 项目(用以对抗垃圾信息)， WordPress.com 相继正式对公共开放，看起来似乎是无心插柳柳成荫，其实是很大程度上依靠着开源社区的力量驱动。而 Movable Type 的版权形式让用户心怀芥蒂，直到 2007 年，Six Apart 才重新修改版权形式为 GPL (GPLv2) 。这个时候已经无法改变什么了。这几年中，Movable Type 几乎没有什么革新的功能出来，版本 3 和 Spam 较劲了许久，然后 4.0 解决了 Spam 问题后则是跟性能问题斗争，现在的版本 5 倒是有些中规中矩，只是时不我待。WordPress 的开发者分为 Lead Developer、Contributing Developer、Developer ，这种形式更能激发贡献者的热情，形成了一个相对更为健康的结构，而对于 Movable Type ，即使在开源后也几乎找不到这样的结构，只是知道目前日本的 Perl 技术社区承担了很大一部分开发改进工作。如果要总结一下 Movable Type 被 WordPress 超越的第二个原因：WordPress 吸引了开源社区的力量。

如果说语言决定运势，似乎有些技术巫婆的味道。Ben Trott 用 Perl 语言开发的 Movable Type ，而 WordPress 则是用 PHP 进行开发。很不幸的是，Perl 差不多是过去 10 年最让人扼腕的一门语言，从 Perl 5 之后一直停滞不前，直到去年 Perl 6 才姗姗来迟，Perl 没有凤凰涅槃，终究彻彻底底的成为了一门小众语言。Perl 功能超级强大，但有个相当大的弊端，那就是一个人写出来的程序，换一个人很难读懂。这意味着 Perl 写出来的 Movable Type 很难借助于群体的力量而继续改进，终究将 MT 变成属于小众群体的工具。2003 年的时候，PHP 还不够先进，但是 PHP 一直在迅速进化，而 PHP 用户群也越来越大，PHP 语言越来越流行²。WordPress 尽管开始粗糙，但是经过不断的改进后最终变得功能强大甚至完美。很多国内 Blogger 应该记忆犹新，选择 Movable Type 的话，必须要找能够支持 Perl 环境的虚拟主机，而虚拟主机支持 PHP 则几乎是”标配”。语言的选择决定了一个产品的基因，从某种程度上也决定了产品的命运。这是两种技术文化的碰撞，这是 Movable Type 被 WordPress 超越的第三个原因：选择 Perl 是一种错误。

Six Apart 步步抢得先机，却总是被后发的 WordPress 超过。Six Apart 在 2003 年就正式推出了 TypePad 这个 Blog 托管平台，远比 WordPress.com 起步早。做平台，非常关键的一点是需要一个好的生态来维系。Movable Type 想从软件 License 中赚钱的想法实际上已经注定了构建不出这样相对开放的生态。而 WordPress 则不然，始终坚持开源，团结技术社区。WordPress 逐步发展成为最流行的网志发布工具，而广泛的用户群则给 WordPress 带来了大量有价值的反馈，技术爱好者则进一步贡献了数不清的插件，很多用户因为 WordPress 有着这么多的插件而放弃 Movable Type，也难怪，到现在 MT 还没有一个合适的插件让用户很方便的显示相关文章，而 WordPress 下面类似的插件比比皆是，只是有的写的糟糕，有的写得精致而已。不难看出，WordPress 走了一条农村包围城市的路线，逐渐培养了大量的基础用户。时至今日，WordPress.com 是全球前 20 名的网站，而 TypePad 排名是 200 左右。 Movable Type 被 WordPress 超越的第四个原因：WordPress 构建了一个更好的产品生态，进而培育了一个成功的平台。

关于”生态”，我想说一下国内的一些开源产品，比如 Discuz!，较少得到来自技术社区的贡献，说是开源，仅仅是把代码公开，缺乏与技术社区良好的互动，形成不了良好的技术生态。

不知是不是 Ben Trott 最初单枪匹马写出来的 MT 的缘故，Six Apart 团队另一个特别的地方是没有出现有影响力的技术明星。在 2005 年，Six Apart 收购了 LiveJournal 背后的公司 Danga 。Danga 这个技术团队在 Web 2.0 历史上是值得纪念的，给业界贡献了 Memcached 、MogileFS 这样经典的开源产品，让无数创业团队受益，相信今天很多公司都在使用 Danga 团队开源的产品或是从 Memcached 中借鉴了 Key-Value 产品的设计理念。甚至那篇 LiveJournal’s Backend 也给了国内很多技术人员以启迪，我甚至认为这是 Web 2.0 技术大潮中最重要的 PPT 之一。遗憾的是，Brad Fitzpatrick 这位大牛没多久就离开了 Six Apart ，加入了 Google。这一次收购似乎没有给 Six Apart 带来什么。除此之外，业界很少有优秀的 Perl 为主导的技术团队了。后来， Six Apart 又有几次收购，似乎也都是为了技术团队而进行的。反观 Automattic ，迄今为止只进行过两三次收购而已，而且都是为了完善 WordPress 产品功能。第五个原因，Six Apart 的收购没有做到价值最大化。在雅虎的收购上我们也看到了类似的失败的做法。

抛开这两个产品的其它方面不谈，一个成功的产品和一个走向没落的产品之间的差异是一点一点产生的。我们能看到结局，但回到 2001 年的时候，没有人能预料到这些。当然，今天的 Movable Type 绝非一无是处，尤其是模板结构，现在也要比 WordPress 优秀，但是没办法，WordPress 好的模板主题更多。另外，MT 的静态⁽³⁾页面发布功能依然是一个不可替代的优秀特性，虽说 WordPress 启用了 Cache 之后，MT 这一点已经不具备多大的优势了。当然，难以割舍的还有习惯和一种别样的感情，所以，至今国内仍有不少出色的网志是构建在 Movable Type 之上的。

两个产品似乎从没剑拔弩张相向过，但我想 WordPress 至少是将 Movable Type 作为一个对手并一步一步将其超越的。我知道，作为 Movable Type 或是 WordPress 忠实用户的你，一定还有其它看法。

Movable Type is Dead, Long Live Movable Type.

–EOF–

注1: 为了纪念过去的一些原则上的争论，这里”Blog”一律译作”网志”。

注2: 关于 Perl 和 PHP 的那一段言论会引发争论。请原谅我的偏见和无知吧。

注3: MT 的静态发布，对于单个页面的访问，Web 服务器来说减轻了压力，但是对于需要频繁交互的应用需求，比如类似留言这样的操作，MT 就太慢了。

延伸阅读：这里有一篇老外写的分析文章，大部分观点都是类似的。

Movable Type 的 wide character in subroutine entry Bug

这是一则只写给国内几百个 Movable Type 用户看的信息。

Movable Type 5 的用户可能会遇到关于留言功能的一个小Bug，系统在用户留言的时候提示留言失败(实际上留言已经成功），”wide character in subroutine entry”，搜索后可以参考这则信息以及困扰已久的 MT5 的 bug 解决了，但对于没有使用的 Markdown 插件的用户，这两个地方提到的办法只是给了一个思路。更合适的解决办法是打开 MT 的 Debug 模式，然后提交留言，系统提示信息可以让你发现具体是哪一个脚本出错，这次遇到的是 EncWords.pm 176 行提示错误。

于是，修改该文件，在开头加入：

use Encode qw(encode_utf8);

将 176 行的代码:

encode_base64($str, '');

修改为：

encode_base64(encode_utf8($str), '');

重新提交留言测试。MT 5.01、5.02 与 5.03 测试通过。

说句题外话，Movable Type 日渐式微，国内用户也是越来越少了。如果不是用 Perl 开发，比如用 PHP ，可能现在也未必是 WordPress 的天下。基因决定命运，对某些创业企业来说是这样。

–EOF–

更新：后续的几个版本也有同样的问题，需要手工修改一下。Movable Type 越来越没落了。

Movable Type 与 WordPress

在几次跳票之后，Six Apart 终于发布了 Movable Type 5。作为少数坚守在 MT 阵地的用户，当然是第一时间升级到新版本进行了一番体验，结果就是这几天正在一点点修改升级后的一些模板上的问题。倒是有活干了。

一点小经验是如果是延续用旧的主题的话，迁移到新的目录后要确保有 “theme.yaml” 这个文件，否则后台点击 Setting 按钮的时候会弹出一个”Can’t call method "label" on unblessed reference” 的错误。多数插件都能继续用，可以打开 MT 的 Debug 模式，然后查看 Plugin 列表，会显示哪些插件兼容性不够好。我觉得用好 MT 的一个秘诀就是…尽量少用插件。

总体来看 MT 新版本的确带来了很大改进，除了增加了版本历史功能外，内容结构的组织有更大的改进，模板的可定制化非常好，是目前能看到的 CMS 平台的登峰造极之作。只是从平台的角度考虑恐怕还竞争不过 WordPress ，我个人觉得语言的实现(Perl vs. PHP)造成了二者在最初发展上的差异，进而导致插件上开发的 Movable Type 远远不如 WordPress 容易，而插件的多寡影响功能的完善与丰富性。用户会接受哪一个不言而明了。另外一个影响因素就是更多的主机提供商对 PHP 的支持更为友好，甚至一些提供商提供一键安装 WordPress 的服务。而 MT 的安装怎么也需要用户懂一点点技术才成。

好的工具才会激发写作的乐趣，MT 属于这样的工具

–EOF–

Movable Type 的性能问题

我算得上是 Movable Type 的忠实用户。这两年来，WordPress 快成为独立 Blog 的标准配置了，MT 可以说每况愈下。自从升级到 MT4 之后，明显感觉 Blog 性能糟糕了很多，每一次发文章都要与 HTTP 500 错误战斗半天才能成功，读者留言也非常费劲，有段时间非常灰心丧气，都不想继续写下去了。如果说 MT 3 之前是与 SPAM 战斗，到了 MT 4 就完全是折腾性能问题了。虽然 MT 4 之后的每次小版本发布都宣称性能上有很大改进，实际表现总是欠佳。

一些常规的 MT 优化技巧其实作用都不大，我还把 MT 用的数据库索引分析了一遍，删掉了好几个价值不大的索引，虽然不是无用功，但也解决不了问题，因为瓶颈根本不在 DB 这里。大多数 Movable Type 用户的应用场景是在 Dreamhost 上，在这个环境里要想找到应用的瓶颈还真的是个技术活。缺乏 Profiling 工具不说，如果调用某个命令消耗了资源稍微过份一点，立刻被系统 Kill 掉。

其实 MT 的设计思想还是很不错的，大部分页面都 Build 成静态页面，减少对数据库的压力。一般来说，这比 WordPress 频繁调用数据库的方式(当然 WP 是可以起用 Cache 的)，应该在性能上有更好的表现才是。问题是 Dreamhost 对每个用户提供的硬件资源其实是很差的，尤其是磁盘 I/O 。我的所有页面加起来也不过几千个，如果只是访问静态页面或是数据库其实问题都不大的，麻烦出现在构建页面或者是遇到留言行为的时候，MT 会调用若干个磁盘上的模版文件，加上 Perl 本身的系统开销，消耗的资源就到了 Dreamhost 的极限，然后进程就被无情的 Kill 掉了。估计是用户群抱怨太多，从 MTOS 4.1.1 版本开始总算有了一个性能框架专门用以分析性能问题(并且号召用户提供性能数据以便协助解决性能问题)。启用了一段时间后，收集到的 Log 响应时间典型是这样的：

MT::Template::build[Comment Response]=0.60070
MT::App::Comments::run=28.24320
Total=28.85665

或许在 I/O 不错的系统上，表现会好吧。Dreamhost 上文件都是放置在 NFS 上的，而且众多用户共用一个系统，只能将就一下。

今天看到 4.15 的改进中，已经可以 Cache Template Module 了。甘愿作小白鼠，升级。盼望这次能有效解决特定应用场景的性能问题。不过开启了性能 Log 看了半天，效果并非很显著，

后记：

经验证的有效办法之一

通过Cache提升MT基于Tag搜索的速度，只在第一次构建需要的 Tag 时候会占用平时一样的系统资源。再次搜索时，开销大大降低。”抱怨的同时要有解决办法”。

–EOF–