给 WordPress 换了一个 Markdown 插件

之前我换 Hugo 的原因之一就是对 WordPress 的编辑器的开发路线非常不满。一个简单的博客,弄那么复杂的古腾堡干什么?这东西,我感觉就是初学者用这简单把,还有真正在浏览器里打字的人用着输入一些。像我们这种在外部把文章写好了再发布的,非常不爽。我猜和 WordPress 要往 CMS 工具发展有关。

过去古腾堡是个插件,我不用它的话禁用即可,但随着版本升级,古腾堡成了默认的了,我也找不到可以把它关闭的开关。切换到 HTML 编辑模式,把 Markdown 复制进去,切换回来还是乱了,再换到 HTML 模式,被加上了 HTML 的标签,不是我想要的。更别提通过 Ulysses 发布了,之前的文章里的列表全没了,一团糟。

我很奇怪 WordPress 没有跟上潮流,默认加上解析 Markdown 的功能。Moveable Type 在很早的版本就默认支持 Markdown,而 WordPress 还是需要插件支持。我刚学会 Markdown 后,给 WordPress 装了一个名为 Markdown for WordPress and bbPress 的插件,这几年一直这么用着。直到出了古腾堡的妖蛾子。我尝试着打开 Jetpack 里面的 Markdown 功能,也没起到作用。无奈还是换一个插件吧。

根据评价,我选择了 WP Githuber MD,尝试了一下不得了。首先之前的格式恢复正常了,再者编辑器也有了更加强大的功能,实现了左右两栏的设计,左边是 Markdown 文本,右边是实时预览。虽然我目前用不到实时预览的功能,不过还没有把它关闭,新鲜两天再说。

这样我的博客系统又可以安稳的用一段时间了。我觉得 WordPress 这样破坏生态,从使用者的角度来说真看不出有什么太大的必要。Firefox 给插件系统动了大手术,换来了开发者和用户的长时间阵痛,到现在还让我心有余悸,真不希望 WordPress 走 Firefox 的后尘。毕竟,博客在今天已经式微,强大又稳定还能保持更新的博客系统也没多少了。

Mena 离婚了,博客还写吗?

事情是这样的,晚上在看 Twitter,看到冯大辉分享了一篇他写的博客,我一看网址的开头是 mt,就好奇点进去看了看。文章本身没什么,只是这个博客是 Movable Type 架设的。我知道冯大辉过去是用 Movable Type 的,后来换成了 WordPress,我还不知道他还在继续用 Movable Type。看他有一篇文章,标题是《优雅不太容易模仿》,让我感到惊讶,看他的意思是想要重新拾用 Movable Type。

之前我关注 Movable Type 时,看到从版本 6 开始,Movable Type 已经不再允许私人免费使用。个人使用也需要先购买一个有效期一年的许可证。而一份许可证的费用,在我看来确实不菲。说句公道话,自从 DHH 发布了一个 10 分钟开发一个博客的视频后,博客系统就不再神秘了。比起其他种类的各种 CMS,实在是太简单了,无非是把一个页面渲染成网页而已。现在有些人的博客已经没有评论功能了,评论功能只要做好了与文章的衔接,也没有什么难的。放在今天,个人的博客基本上不会被大量同时访问,也不需要过多的考虑性能问题。这样的话,一个不那么流行的博客系统软件,要这么贵,我实在是觉得他们疯了。

这次看到冯大辉还在用 Movable Type,我心想现在的他自然可以买的起。然后就顺着他的链接,去了 MovableType 的官网上看看,看到目前已经发展到了版本 7 了,虽然还是 RC 版,不由的想起了我用 MT5 的 RC 版时就遇到的一个 bug,提交了 bug report 一直到了正式版还没有修复,最后还是我自己找资料修复的事情。之后又想起了 Movable Type 的创始人 Ben & Mena Trott,于是再搜索一下他们的信息。上一次关注他们时,他们已经把 Six Apart 公司给卖了,并不再负责公司的运营了。这次看到了 Mena Trott 的维基百科页面,惊讶的发现他们似乎已经离婚了?页面上说:

The company name originates from the fact that Trott and co-founder/ex-husband Benjamin Trott were born six days apart.

还有,原先 Mena 的全名是 Mena Grabowski Trott,现在成了 Mena Grabowski Lazar 了。简单的调查了一下她的网上记录,发现似乎和一位名叫 Joe Lazar 的男士相关,不确定他们之间是什么关系。

不关怎么样,到了离婚的时候自然就离了,作为外人没有什么意见。只是突然遇见了这样的事,心中不免想的多了起来。两个人成名之前经历了什么事情,我不得而知,但他们的成名是因为博客。当年 Mena 想写博客,但没有好的博客应用程序,作为 Perl 黑客的 Ben 发挥男友力,写出了 Movable Type 这套软件。之后他们以这套软件创业,创立了 Six Apart 公司,起这个名字的原因也一度被我们津津乐道——Ben 和 Mena 的年龄相差 6 岁,而他们的生日也相隔 6 天,多么浪漫的公司名称?公司成立后,Ben 性格低调,应该专注于开发吧,Mena 是外向性格,我看过她上了 TED 做关于博客的演讲,属于意识形态的,非技术。

说道 Mena 的演讲,之前我也写过一篇文章,不过没有讨论太多关于演讲本身的东西,因为我现在重新听了一下,演讲本身其实挺糟糕的,没有什么吸引人的点,看了评论也是负面评价较多。当时我听了之后是什么感受,具体的已经难以回顾,不过一个想法是——博客这么简单的东西,需要人跑到 TED 上去演讲鼓吹吗?作为一个 blogger,说实话我感觉有点脸红。今天看了,博客没落不是没有道理,不是说它没有价值,只是它被人们鼓吹的太厉害了,泡沫的破裂也就不可避免了。

回到 Mena 的婚姻,我在想,她现在还会想写博客吗?如果是我,可能不会吧。之前她的博客写到了 2010 年 12 月,目前她的域名 dollarshort.org 目前也没内容了,她的博客转移到了 TypePad 上。之前经过创办公司,从我的角度看,Mena 的人生已经和博客有了太多的牵扯了。而博客这条线的另一端,绑在 Ben 身上。如果他俩和平分手,那问题倒还好说,可如果有其他隐情,那问题就复杂了,作为当事人,不愿意回顾和他有关的东西是顺理成章的吧。

总之,这件事情作为一个外人,全都是推测,毕竟她还不算什么普通意义上的名人,也没有什么媒体去挖掘。一切不过我自己的意淫而已。

过去与今天

今天,妻子带我去了回民小区的磊磊烧烤。我对这种烧烤模式感觉其实挺一般的,倒不是说卫生问题,主要是每一串只有三个花生豆大小的肉块,吃起来太不过瘾了,与我童年时吃的羊肉串的口感大相径庭,有种不过瘾的失落。不过自古以来,吃这种烧烤吃的不是肉,主要是气氛。

这次让我感觉回到了2009年回国时,跟一群雄性小伙伴们聚会时吃烧烤的日子。我们那次去的应该不是这家磊磊,而是旁边的某一家我记不清名字的店。那次吃了什么我已经没印象了,就是记得喝了几桶扎啤,肚子好涨的感觉。几个哥们两年没见了,感觉很有趣。今天我们两个人也吃了一些,我独自喝了一扎啤酒,很涨,我也有点高,不过也是很开心就是了。

今天中午在美莲的必胜客坐了会儿,喝了几杯下午茶,吃了一点点心,然后上网。看到了一些信息,其中有两件让我比较在意。

其中第一件是关于“王小平”的。

王小平,女,1980年生人,在15岁时在中学时成绩全班第一的情况下,认为现有的教育制度不适合自己,于是毅然退学,在家自学。之后说是讲课、写书,有了一定的名气。我在上中学的时候,在报纸上看到了关于她的报道,对她的理论有了点兴趣。其中印象最深的是学习的三个要素——“为何学”、“学什么”、“怎么学”。目前人们关注最多的事“怎么学”,而王小平认为“为何学”才是重点,有了“为何学”才能有“学什么”和“怎么学”能够确定下来。之后我专门从书店中找来了她写的、比较小众的《本领恐慌》,云里雾里的也没怎么看明白。

今天我莫名的想到了她,我想知道她现在是什么情况,是不是还在自学,在干些什么,有没有后悔当年退学的决定,以及当年做出超然决定的她有没有“俗人”的种种生活,比如婚姻。今天找了一下,没有太多的信息,我从亚马逊上搜索了一下她的名字,能找到一些纸质书,可惜没有我想要看的 Kindle 版的。有些评论是她的书比较浮夸,毕竟写书的是20岁的人,很难有强壮的人生经历来充实自己的语言,一个人生还没有经历过大半的人,写出来关于教育的书籍,确实也不好让人信服。

另一件事情是关于 Movable Type 的。

今天也想不起什么时候是怎么样想起它来了,因为我本来也觉得不想也不再需要再关注它了。今天看了一下它的网页,挺吃惊的发现它竟然发布了6.1版本了。我的博客放弃使用 Movable Type 的时候,它才出版本5不久,现在有了下一个大版本,应该有了不少新的功能了吧。于是不由自主的就像装上试试。然后上了他的 .com 页面上,看到可以一键安装到 AWS 主机上,这点不错,可惜我没有 AWS,也觉得不大容易搞懂 AWS 的付费方式,担心不知不觉的被扣款,所以也没有进行下去。然后看了一下页面的其它部分,竟然没有找到下载链接。然后研究了一下,发现现在 Movable Type 竟然不给免费下载了,真是让我搞不懂。我搜索下,倒是有可以让你跟过去一样,免费下载开源版本的方法,但是在一个日文页面里,填上你的邮箱,选中一个要下载的理由,然后会给你发个链接还有提取码,你可以下载,很奇怪!

我觉得不管 Movable Type 想怎么经营,是不是又选择了什么超前的、高大上的盈利模式,但只要是愿意免费给个人用户使用这套系统,总是应该给出一个比较方便、容易的获取途径。搞这么麻烦的下载,而其它的使用途径又不给出一个非常非常鲜明的获取说明,还有一部分是在日文页面上才有的,这是想作死吗?难道这群人要生生的放弃博客后台这个市场吗?

两件过去与今天的差异、一件与过去相似的事件,记录于此。

我怎么又修改了一次 .htaccess 文件?

今天打开了好久没有关注的 Google Webmaster Tools 页面,看了一下我的网站的情况,发现有好几百个 404 链接。看一下描述,结果又是 .html 文件找不到错误。

这是一个很老的问题了。还是年轻时犯下的错误。小时候对于互联网更多是一种娱乐、玩耍的态度,所以对一些事情就比较随意。最开始时我用的 WordPress 搭建 blog,因为刚开始时什么也不懂,在买共享空间之前从网上注册了一个免费的临时空间,在里面上传了 WordPress 的程序(我记得当时好像版本时 1.5),很快的就运行起来了。我当时觉得安装 WordPress 原来这么容易,于是等有了共享空间后就用 WordPress 来写 blog。

那时候最流行的 blog 程序有两款,WordPress 和 Movable Type,相对来说 Movable Type 评价更高一些。Movable Type 是老牌的 blog 工具,质量上有保证,底蕴也更厚重一些;WordPress 比较新,年轻、有活力,但从时间上还没有完美的证明自己。从国内的用户来看,WordPress 安装容易,还是完全的自由软件,所以用户很多;但很多重量级的 blogger 都在用 Movable Type,也很有影响力。我因为是玩的心态,所以就都想试试。但 Movable Type 是 Perl 程序,安装 CGI 程序比 PHP 要难一些,尤其是在共享空间里,PHP 需要的各种库都全了,而有些主机的一些 Perl CGI 库就没有,所以安装 Movable Type 就更困难,因此我开始时没有安装成功。到后来慢慢有了经验后,我才成功安装了 Movable Type。

安装成功了之后我就有转移的想法,我想把我的 blog 转移到 Movable Type 上。从今天看来这是相当不明智的,两个工具之间有很大的差异,转移过去容易但一些后续问题都比较麻烦。我当时也没有马上转换,因为我还不大会用它。后来我第一个共享空间到期了,我一直也没有主意,有一天突然我的 blog 不能访问了,我面临着转移的问题。后来有人从网上看到了我的消息,好心的为我提供空间,同样是 Dreamhost,我于是就把文件都转移到新空间上去。因为这个契机,我把 blog 程序换成了 Movable Type。

Movable Type 始终不让我完全满意。我是从版本 4 开始用的,从这个版本开始人们对 Movable Type 的评价打了很大的折扣,有些人到现在还在用版本 3 甚至版本 2。我过去也尝试过旧版本的 Movable Type,感觉 2 相对来说还是稍微简陋了些,但比版本 4 要快很多;版本 3 就非常完美了,兼具速度与功能。版本 4 用起来是各种慢,后台总体慢,发布慢(我全站发布一次要将近一个小时),而生成的静态页面跟我用 WordPress 时比起来速度也没有多么快,反而还稍慢一些,这就让人有点不愉快了。后来 Dreamhost 主机到期了,我和那位好心的朋友一起换到了 Site 5 的空间,速度马上上来了(全站发布不到两分钟),这时候我才享受到了 Movable Type 的一些乐趣。

真正让我对 Movable Type 死心的时版本 5 的发布。当它还在 beta 版的时候我就试用了,结果因为跨语言的问题导致我的站点不能发布。我提交了错误报告,结果一直到了正式版发行出来问题都没有解决。Six Apart 公司也买了,Movable Type 的开发重心从美国移到了日本,开发的力度也小了很多,这就是一个有各种漏洞的破船,所以我趁着买 VPS 的机会,赶紧转移了。

在我从 WordPress 换到 Movable Type 的时候,犯了个大错误,没有设置 Movable Type 生成的链接,让它看上去像 WordPress 的链接,结果两边的链接不同,旧的链接就不能访问了。这跟我的性格有关,我比较迷信作者的权威,比如我做方便面的时候喜欢严格按照说明上来,有时甚至还读秒来保证泡面的时间不会过长或过短。所以当我看到 Movable Type 默认的链接是 /year/month/slug.html,我就用了它。如果我把它修改成过去用 WordPress 时的链接 /year/month/slug/ 的格式,一切问题都没有了,结果我觉得我的 blog 没多少人看,影响不大,所以就傻乎乎的用了新的链接格式。

后来我为了让旧链接可以访问到新的 blog 的文章,只好设定 URL 转向,看说明、示例来编写我的 .htaccess 文件。

我用了几年 Movable Type,到最后还是回到了 WordPress 的怀抱,这时候我还是选择了 WordPress 默认的链接格式。其实我这个时候也可以“将错就错”,把 WordPress 的链接格式改成 Movable Type 类型的,但我想既然转换旧转换彻底,那些残余就全部摒弃不要了吧。所以我的链接格式就又一次冲突了。

开始时我用的是 Lighttpd 和 Nginx 服务器,它们的 URL 转向方面的文档比较少,我从网上找了很多例子,到最后好像在 Lighttpd 里成功了,Nginx 怎么也没有弄好,到最后我也只好放弃了。后来我买了 Linode 后开始用 Apache,这方面的资料就多了,而且我也可以方便的用 .htaccess 来设定了。

从开始到现在,我印象里设定了好几次这个文件。大概有五次?这个文件是一个设定好了就很久不需要动它的文件,而且它的语法也千奇百怪,所以我从来就没有真正学会它。每次修改我都要查看文档,找一些例子,做好几次尝试才能把它弄好。本来我希望一次成功后再也不用修改它了,没想到这次又搞了一次,我印象里之前好像动过其次这个文件啊,可能还是没搞定 URL 转向的问题。我希望这次是最后一次了。

我从 2007 年 3 月开始买了域名和共享空间,到现在已经是满 6 年了。我的第一篇 blog 文章是 2006 年 3 月在 BSP 上发表的,到现在已经整整 7 年了,到今天看来已经有很长一段时间了。当年的很多 blog 现在已经不见了。这么长时间,已经让我对互联网的态度从“玩”过度到“使用”了,追求的也已经不是新鲜感而是安定了。很多人已经扔掉了 WordPress 开始玩 Octopress 了,我已经不打算跟进了。之后肯定还会出现更新、更炫的工具,我也没有了真正投入使用的兴趣了。踏踏实实的做一种保持其实是很宝贵的。

Nginx 重定向

过去因为一直弄不好我的 blog 里的 Google Analytics 插件的设定,导致在 WordPress 后台的 Dashboard 里面无法显示 Google Analytics 的报告,因此我过去几个月都没有怎么去看 Google 的统计工具。昨天把这事搞定了,于是我也看了一下网站统计方面的信息。当我看到 Google Webmaster Tools 里报告的 189 项 Not found 抓取错误时,觉得应该处理一下子了。

之所以搞得这么难看,是因为我过去切换 blog 系统的 URL 设定的缘故。最早我用的是 WordPress,当时用的是 /year/month/slug/ 的 URL 格式,后来我学会了 Movable Type,于是就把 URL 的格式弄成了 Movable Type 默认的 /year/month/slug.html 格式。当时为了把搜索引擎索引的旧的 URL 都改过来还花了好多功夫。后来我实在是不想再用 Movable Type 了,就把 blog 程序换回了更有前途的 WordPress,URL 格式我也切换回来了,毕竟这是 WordPress 里比较常用的。Movable Type 是生成的静态页面,因此用 html 格式比较自然,WordPress 是动态页面,自然就比较倾向于子目录的格式。

切换了 URL 格式,过去的页面就自然无法访问了。我在第一次切换成 Movable Type 的时候,就为此费了心思。当时用的是虚拟主机,web 服务器自然是 Apache,我就捣鼓了一阵 .htaccess,让旧的 URL 可以自动重定向到新的下面。这次也是如此,不过是反过来了。而且这次我用的是 VPS 主机,资源不容许跑 Apahce,所以我用的 web 服务器是 Nginx。Nginx 不支持 .htaccess,因此我要修改 Nginx 的设定。通过搜索,相关代码如下:

rewrite ^/(.*).html$ http://liuf.net$1 permanent;

话说 Nginx 虽然在 VPS 领域比较有知名度了,但好像还是比不过 Apache。像 WordPress 之类的程序,官方支持文档里首选的还是 Apache。像 WordPress 的一些插件,更是如此了。比如 WP Super Cache 插件,我到现在进入它的后台上来还是给我一篇警告,比如说 Mod Rewrite 模块没安装啊、Mod Rewrite 规则无法更新之类的啊,实在是烦死了。虽然我根据网上一些前辈的代码,修改了 Nginx 里相关的设置文件,但我仍然不确定这个插件是否正确运行了。本来我觉得应改没什么问题,不过最近我发现我通过这个插件 Preload 的缓存,在 Preload 完毕之后就被删除了,让我非常不解。更可气的是,这次我为了弄 URL 重定向的问题,仔细的看了一下 Nginx 的相关设定代码,发现我从别人那里弄来的 WP Super Cache 的设定代码里根本就有问题,也许是版本之间有差异,在重定向的 URL 里面竟然多了几道下划线,这不让之前的设定都失效了么……我改了相关的设定,观察一下有没有效果再说。

另外,在修改重定向设定时,我还从 Nginx 官方网站上看到了这么一个页面,关于统一网址时的错误做法以及正确的做法,虽然不是很明白为什么这样就效率低,不过我还是照着改了过来。

总之,Nginx 的设定给我的感觉是比较灵活,像编程语言那样的设定脚本,不是严格的语法,灵活性相当的高;不过不足的是比较冗长,繁琐,不如 Apache 的 .htaccess 文件的设定那么简单明确。我当然希望它能有所改进,毕竟 Nginx 占用资源小这一点对于 VPS 用户来说是相当大的优势。如果有相关模块,能做到把 .htaccess 文件动态转换成 Nginx 的设定就好了,就像 Lighttpd 的 magnet 模块一样,可以使用 Lua 语言来代替 Lighttpd 自己的设定。既然 Lua 语言可以转换成 Lighttpd 的设定,那么我像把 .htaccess 的规则转换成 Nginx 的设定应该也问题不大吧。

一个网志发布系统的倒掉

我在前几个月主动的生活在一个“信息相对闭塞”的环境中。过去我奉行的宗旨是“生活在互联网中”,也就是说,在日常生活当中,我多数携带笔记本电脑,Apple Mail 程序一直运行着,每隔几分钟就自动检查一下我的私人邮箱和学校的邮箱,有了新邮件我可以马上处理;Adium 一直运行,保持登录 Google Talk、MSN、QQ,有时甚至还有 Facebook,始终设定到 Available 状态,这样有人要联系我的时候我马上就可以回复;Twitterrific 或 Tweetie 一直运行,我的好友或者 list 上关注的人在有了新状态的时候我可以立刻了解;每天必做的几件事情之一就是阅读 Google Reader 上的几乎每篇文章,让它的 inbox 保持为空……

几个月前,我对于这种状态突然感觉厌烦,于是便过一种“隔离”的生活。Apple Mail 和 Adium 通通不运行了,Twitter 也不登录,Google Reader 上的新闻也不管了。这让我安静了一段时间,同时也让我错过了业界的很多新闻。比如今天我偶然间打开了过去经常看的几个 blog 时,看到的这篇《Movable Type 是如何被 WordPress 超越的?》。

看到了文章之后,我很吃惊,因为 6A 公司竟然被收购了。我上网查了一下,发生的时间大概在去年 10 月。

6A 的几件产品中,我用过的大概也就是 Movable Type 了。虽然我现在已经不用了,但毕竟曾经使用过一段时间,从感情上来说我是希望 Movable Type 可以更好的发展下去的。大概从 Movable Type 4 开始,6A 吧主要的精力放在了媒体上。比如 TypePad 等平台之类的。尽管 Movable Type 依然是 6A 的主要产品之一,但更多的是作为其它平台的一件底层产品,我的感觉是 Movable Type 像是 6A 自产自用的内部工具,而对于 Movable Type 的外围用户而言,6A 就像是后妈一样,对 Movable Type 不管不问。

从 Movable Type 的 bug tracker 上观察,Movable Type 的主要开发者都是日本人,Movable Type 的开发团队好像就在日本,Movable Type 5 似乎也是日本那边开发的。这让我感觉 6A 把比较“低层”的产品交给“人力资源密集”的东方国家来开发,美国本部那边进行比较“高层”的交互,主要是针对一些大的媒体发布者等等。同时日本也是 Perl 使用的大国之一,很多 Perl 黑客都是日本人,因此把 Movable Type 的开发放在日本也许是不得已而为之吧。

Fenng 在那篇文章里总结了几点 6A 运营 Movable Type 失败给 WordPress 的几条原因。其中除了语言选择上的错误之外,我都比较赞同。对于我自己的使用经验来说,不活跃的产品开发状态是我离开 Movable Type 的最大原因。

我首次接触 blog 是在 2006 年,购买自己的域名和虚拟主机在 2007 年,从那时起我开始使用 WordPress。那时我还是一个 blog 菜鸟,但很明显的感觉到 WordPress 仅仅是一个 just work 的系统,还算不上 wonderful。我自己就有几次 WordPress 让我抓狂的经历。我在 2007 年刚来加拿大不到一个月的时候在另一个域名上终于安装了 Movable Type,但当时关于路径方面还有一点地方我没有搞懂,而且 Movable Type 的模版显示中文简直让人恶心,所以我那时在那个域名上用 Movable Type 写了几个月的英文 blog。到了 2009 年我在 Dreamhost 上的虚拟主机帐号到期,转移到另一个帐号时 blog 的模版出了问题。那时我又一次尝试了 Movable Type,感觉可以用它搞定我的日常 blog 了,就从 WordPress 转移了过去。当中我从 Dreamhost 转移到了 site5,对于 Movable Type 生成文章的速度有了很深刻的感受。2010 年我买了自己的 VPS,在转移的时候从 Movable Type 切换回了 WordPress。

以上是我使用 blog 的简要经历,当中遇到了一些小问题,也学到了很多。最开始了解 blog 的时候,我就被灌输了一种 blog 市场二元化的概念:WordPress 和 Movable Type 二分天下。WordPress 大众一些,Movable Type 更加的优雅、正统。这种描述让我现在立刻想起了 Linux 和 FreeBSD。

或许是出于“得不到的总是更好的”这一想法,我在使用了 WordPress 后总想着试试 Movable Type,觉得写 blog 不用一下 Movable Type 就是一件憾事的感觉。后来等我真正使用了 Movable Type 后,我遇到了一些问题,比方说“发布效率”等,但我依旧乐此不疲,因为“好玩”、“新鲜”、“有趣”。不过那时我刻意抵制 WordPress 的任何消息,因为我了解在某些方面 Movable Type 可能永远也比不过 WordPress,比方说“发布效率”——我害怕自己动摇。

也是因为好玩,我可以忍受 Movable Type 的种种不便,比方说“发布效率”。:) 当我还在 Dreamhost 的时候,我的 blog 整站发布一次需要 45 分钟之多。我在那个时候就可以忍受这种速度在现在看来也算是一种奇迹了。当时我甚至认为 Movable Type 发布站点就是这么个速度,后来我换到 site5 主机上才发现原来我的 blog 整站发布一次只要 2 分钟不到,这才扼腕叹息。Movable Type 给我带来的种种不便,而我还坚持使用了一年,现在看来当中未尝没有一种“拧”的心态:既然曾经是好东西,那么我现在一定也可以用好。

其实从使用经验上来看,我觉得 Movable Type 和 WordPress 对我来说也有点像 FreeBSD 和 Linux。我第一次在自己家里的 PC 上安装成功的 UNIX 操作系统就是 FreeBSD 4.7-RELEASE,而不是当时已经很红的 Linux,这让我对 FreeBSD 有相当深刻的感情。现在想来,我之所以没有在自己的机器上安装 Linux 大概有两个原因:其一是资金上的问题,我在上初中的时候就想在自己的机器上跑 Linux,可是家里不同意我从书店里花钱买一套 Linux 发行版(当时我期待的是 Xtream,简装版是 20 元左右,精装版包括一本书有 60 元多一些),而我的 FreeBSD 安装光盘是买《FreeBSD Handbook(第二版)中文版》附赠的,虽然那本书的价格在 50 元左右(家里支持我买书);其二是技术原因,那时几乎所有的 Linux 发行版安装程序都是设定好启动时自动运行 X 界面的,而我相当不幸的有一台没有显卡驱动的 PC,所以最后的结果总是引导失败,相反 FreeBSD 安装结束后启动起来的是字符界面,X 需要单独设定,所以我没有 X 也能略微使用一下这个系统。当时我也同样挺“拧”的,那时家里还没有宽带网络,我设定的用 Modem 拨号上网,当时用 ports 安装个软件要等下载还真是麻烦。好在那时可以设定连网方式为按需连接,否则那时的电话费一定超高。

后来在来到加拿大之后,我大概在 10 月份在自己唯一的计算机上安装了 Ubuntu,后来转到了 Gentoo。当中一直没有考虑 FreeBSD,是因为我已经认识到了 FreeBSD 终究是把方向放在服务器领域的操作系统,作为 PC 用户,我要追求的不是超高的稳定性,而是新鲜丰富的软件、快速的运行速度等等。因此我虽然极为怀念 FreeBSD(尤其是我遇到 Linux 的麻烦的时候,比如我在用 Gentoo Portage 时遇到了循环依赖,就想在用 FreeBSD ports 的时候从来没有遇到过这种问题),但还是安装了 Linux 并用的很愉快。

当然,我现在已经重新回到了 WordPress 的怀抱,并且用的很愉快。使用 WordPress 固然是出于效率、易用性等考虑,但我也确实尝试在 VPS 上安装 Movable Type,并发现比在虚拟主机上的难度大了许多。Nginx 对 perl cgi 的支持不好,Lighttpd 上好像有成功的例子,但我自己也失败了。其实,这些都是次要原因。我切换回 WordPress 的最主要的原因大概是我对 Movable Type 的未来的信心不足了。

6A 作为一个资历比较老的互联网公司,我觉得它是有实力来把 Movable Type 发展好的。6A 也曾经财大气粗过,它做了几笔收购的对象的规模都让我挺吃惊的,所以现在 6A 被收购才让我更加的吃惊。另外我觉得 6A 之前的经营模式应该是盈利的。不说产品,光是他们手里的几个域名就很值钱,运作的好应该会很成功。但问题是 6A 的关注中心不在产品,而在互联网服务。这就让我这个 Movable Type 的用户比较失望了。

我之前在从 Movable Type 4 升级到 Movable Type 5 的时候遇到过 wide character 的问题,结果提交了报告之后一直没有的到修复。这么一个错误在一项正式发布的产品当中简直让我无法想象。针对这个问题,我和 6A 的人员讨论过,结果问题没有解决对方就不回我的邮件了。后来还是社区的人把问题解决了,原来只需要不到 5 行代码就能搞定。我提交了 patch 后也是相当长的时间没有被整合进去。或许 6A 的人手不足,工作重点在其它方面。可从 Movable Type 4 到 Movable Type 5 除了界面上,我没有觉得有太大的变化。而 6A 给 Movable Type 不断整合各种功能,比如社区这些东西都是普通用户不需要的,反而 blog 这项基本的功能没有做到精致。我宁愿 6A 像宝洁公司运营旗下的品牌一样,把每样产品有针对性的做到极致之后再考虑整合,而不是给我们一个表面上“高大全”实际上问题多多的产品。

总之在 Movable Type 5 发布之后的这段时间内 Movable Type 的发展速度让我灰心了。无论是商业软件还是自由软件,最大的问题之一就是软件没有更新。一个僵尸软件是最让人厌烦的了。Movable Type 在几年之内没有什么变更,让我对它的将来不抱什么希望,6A 被收购则更是如此。而 WordPress 的开发风格让人觉得未来特别的充实。虽然 2007 年的时候 WordPress 还有很多的问题,但快速的开发到了今天 WordPress 已经可以让我满意了。写倒这里我突然意识到这又是一个 Eric Raymond 《大教堂和市集》的例子,也许 6A 的老板没有领会这篇文章的思想?

今天我还看到了阮一峰的一篇文章,其中引用了一句话我觉得很好:

“未来不属于那些害怕技术进步的人。”(Those who fear technological advances have every reason to fear the future.)

一直没有进步,这就是我弃用 Movable Type 的最大理由。也许 Movable Type 确实没有未来了吧,或许 Movable Type 的未来在 Perl 大国日本? 🙂

旧文章转向设定好了

我在之前的文章里说过,我的 blog 之前用的是 MT 系统来架设的,不过长期以来我对 MT 失望了,所以接着换了主机的契机,我把 blog 程序换成了 WP。但 MT 的默认 URL 是以 .html 结尾的,而 WP 默认的 URL 是目录形式的。所以我从 MT 导入的旧文章的链接都失效了。

我在那时候其实有个简单的方法可以解决这个问题,就是把 WP 的 Permalink 设定成 .html 结尾的。我测试了确实有效,不过我不想用这种方法。原因是我过去的共享空间是用 Apache 做 web 服务器的(似乎共享空间都这样),而我在 VPS 上使用的是 Lighttpd。在 Apache 下设定 URL 转向是通过 .htaccess 文件来设定的,而 Lighttpd 是在设定文件里面配置的。我这是第一次用 Lighttpd(另一个 VPS 上的 Nginx 也是第一次),所以不想放弃这个机会,想把旧的 URL 全转向到新的上面。

中间我抽空略微看了一下文档,觉得不难。这段时间其实我脑子一直昏头了。我脑子里想的是着 mod_rewrite 相关的文档,因为在 Apache 里面就是通过 rewrite 来设定转向的。结果我在 url.rewrite 部分里面弄来弄去,把位置也调来调去,就是不工作。直到今天,我看了一下系统的文档,才找到了 url.redirect。在配置文件里相应的部分加上这么一句就好了:

url.redirect = ( "^/blog/(.+)\.html$" => "/blog/$1/" )

一下子完成之后,真是不胜唏嘘啊。

MT 对于文章的 slug 管理,我感觉挺混乱的。slug 里面分隔单词的不论是减号还是下划线,生成文章时统一变成减号,所以我过去用 MT 的时候就没有注意这一点,想用减号就用减号,想用下划线就用下划线。结果这写文章导入到 WP 里面后,那写下划线就直接输出出来了,非常不好。我正好安装了自动生成 sitemap 的插件,于是就在 sitemap 里搜索,找到包含下划线的 URL,手动在后台改了 slug。

这样这个 blog 就基本上配置的差不多了。唯一的缺陷就是过去的 500 多条留言没了。不过我是没精力再管了,我现在对与用户的访问也不看重了,所以就没有再试着继续恢复留言,而是直接去数据库把 wp_comments 表给请空了了事。这样总算可以清净的写一阵子文章了。

导入 Movable Type 的旧文章

切换了 blog 程序之后,旧的文章就成了一个问题。

WordPress 的文章链接是目录格式的,而 Movable Type 的文章链接是 .html 格式的。除此之外,Movable Type 把每一篇文章静态输出成了 HTML 文件,而 WordPress 是动态生成。我在 WordPress 导入从 Movable Type 导出的文章后发现,我在 Movable Type 下用 Markdown 格式写的文章,所有自然段都合到了一起。一片文章成了一大段,这是完全不能忍受的。

所以我想的是,把 Movable Type 静态输出的 HTML 文件也复制到网站根目录下,但和 WordPress 的 PHP 文件都搅和到了一起,不便与管理。我只好在网站根目录下建立了一个 old 目录,把过去的站点都放在了那里。等未来做个转向,遇到以 .html 结尾的域名,就转到 old 目录去找旧的文件。

不过这样有一个很大的问题,就是这些旧的文章都没法通过 blog 程序来修改了。页面的样式不统一,用户从新页面上也看不到旧页面的链接了。而且明明已经写了那么长时间的 blog 了,这么一弄从表面上看上去只有两三篇文章,看上去也不舒服啊。边栏上 Archives 下面长长的列表看上去多有感觉啊。

虽然目前在 blog 程序界是 WordPress 和 Movable Type 两大巨头霸占市场,但没有形成一个统一的标准是个大问题。从 Movable Type 里导出来的文章,往 WordPress 里导入总是无法做到完美的。文章可以勉强导入,当然我用 Markdown 写的文章在导入后格式也不对了。如果页面里的图片什么的,是放在第三方的图床里,用 HTML 来引用的倒还好一些,可偏偏我的图片基本上都放在自己的服务器上,通过 Movable Type 来上传管理的,这样导入进去就完全不可访问了。

所以今天我决定克服这个问题。链接地址改变了,用编辑器弄个查找/替换就搞定了。而段落换行问题,我不知道是哪边的 Markdown 插件出的问题,所以就考虑在导出的文本文件中插入 br 标签来完成。我不确定能不能行,所以就先试试,写个小程序来逐行分析一下,看如果遇到“BODY:”就把之后的文字在每一行之后都加上 br 标签(Markdown 格式一行是一段),如果遇到“—–”就正常输出。完成后的代码在此:convert.rb

转换完成后,我试着导入进 WordPress,结果发生错误,原来是我的 PHP 设定里上传文件的体积限制是 2MB,而我要导入的文件刚刚超过了。于是去 /etc/php5/cgi/php.ini 里,把 upload_max_filesize 的值调高一些,重启 Lighttpd 后就正常了。

我目前的文章,加上昨天写的两篇和今天的一篇,一共有 476 篇。在导入的过程中内存占用最高大概有 70MB 左右。导入的速度很快,在上传完成之后大概有不到 10 秒就完成了。

至于切换的效果,目前看起来还可以。除了有些文章的开头我添加的小图标似乎有些问题外,其它的基本上都正常了。之前写的一些文章,被别的站点链接后,现在那些链接就失效了。之前我查看文档,勉强可以写个 .htaccess 来做转向,现在的 Lighttpd 我就不太熟练了,几天试了几次都没有成功。后来从网上看到了 user auth 模块可以用 .htaccess 文件来设定规则,等以后有时间再看看吧。

之前尽管我用 Movable Type 有很多不足,甚至让我感觉很痛苦,但我一直没有切换程序,就是因为切换的代价有些大。这次藉着这次换主机的契机,我狠心把程序给换了。现在看起来结果还是好的。虽然我也怀念 Movable Type,但切换过来之后的感觉反而是松了一口气,有一种解脱的感觉。

Movable Type 情结

从我开始使用虚拟主机来搭建 blog 起,我就听说了 WordPress 和 Movable Type 的大名。我先用的是 WordPress,很顺利的装上了。用了大约一年之后,我刚到加拿大没一个月,手贱,试着在另一个域名上安装 Movable Type,结果不大完美,从那时就有 Movable Type 更难的印象。一直到去年,我的虚拟主机出问题了,我换了一家,又尝试安装了一次 Movable Type,结果成功了。奇怪的是,从那以后我又装了几次 Movable Type,一直很顺利。

安装好了 Movable Type 之后,有个问题让我兴奋的心情打了许多折扣,那就是效率。在我当时用的 Dreamhost 主机上,Movable Type 的效率简直可以用“惨不忍睹”来形容了。我当时也上网查了一些文章,结果得到的结论是 perl cgi 的执行效率就是如此,所以 Movable Type 可以说是天生比 WordPress 慢。这让我有种立马回到 WordPress 的感觉,不过我不大甘心就这么放弃了,于是就从那是开始了可以用“自残”形容的 Movable Type 使用历程。

到了去年 12 月,借给我主机的哥们迁移到了 site5,于是我就跟他合租。结果我才知道 Dreamhost 的虚拟主机有多么烂。我在 Dreamhost 上发布整个站点,需要大约 45 分钟,而在 site5 只要 1 分钟多一点。这让我开始接受了 Movable Type 的效率,虽然还是没法和 WordPress 相比,但我已经可以接受了。

从我的网络知识获取渠道上来看,大概是今年初 VPS 开始流行起来了。过去一个人在虚拟主机上装个 blog 程序来写 blog 已经算是比较有技术含量的活了,而现在我看到很多人都开始倒腾起了 VPS。我了解了一下 VPS 的概念,知道了相对于虚拟主机,VPS 有更多的资源,但多数需要使用者有更高的操作技能。我之前就看了很多相关的文章,也比较了几家提供商的方案和价格后,就想找机会试试 VPS。

今年暑假,我和几个同学打算开个站点,看看能不能挣点钱。基于效率上的考虑,我们选择把站点放在 VPS 上。开始的时候我在我的 site5 空间上放了一个 PHP 站,从国内测试的访问速度很不行,换到 VPS 上,国内的同学反应好多了。通过别人的文章推荐和评测,我选择了口碑比较好,价格比较低的 Ramhost。我选择的方案是 256MB 内存的 Micro 方案,机房在堪萨斯城,每月 8.99 美元。经过了大约一天半的实践和研究,算是在上面成功的安装了 Ubuntu 9.10 / Nginx / MySQL / PHP / Memcached / etc.,把站给跑起来了。中间走了一些弯路,不过最后还是弄成了。

Ramhost 有每月 2.99 美元的 80MB 内存的 Nano 方案,我算了算价格后比较心动,再加上之前安装过一次 VPS 了,也有了一些经验。分析一下在上面跑一个私人站点还是可以的,虽然内存很紧张。昨天晚上正式开通了。我没有选择 centos-5-i386-kloxo-hostinabox 那个镜像,尽管别人评价说 Ramhost 的人把它优化的非常小,而且我试了一下果然耗内存很小,但我实在是不喜欢 yum(装好后 yum 还是不能用的)和 kloxo 那种图形化的设定方式。那些选项都不知道在什么地方,之前我也没有经验,被 dns template 之类的东西给搞迷糊了。于是我就装了 debian-5.0-i386,按照这篇文章上讲的优化 Debian 的方法、以及这篇文章讲的优化 MySQL 的方法,把服务器给装好了。之前因为用的 Nginx,从网上找了些资料,说是对 Movable Type 支持不好,我也想尝尝鲜,就装了 Lighttpd。

Lighttpd 确实有 cgi 和 fast-cgi 的支持,不过我看了网上的一些文章,在上面装 Movable Type 似乎特别复杂,复杂到超出了我的兴趣;我自己尝试时数据库那步出了问题;再加上我这几年对 WordPress 也有了一定的改观,所以我最终放弃了安装 Movable Type,而选择了 WordPress。我在 site5 的 WordPress 里试着导入了从 Movable Type 里导出的文章,结果效果很不好。安装了 Markdown 插件之后,段落之间的空行都没了。全篇文章变成了一个大段,太难看了。最后无奈,我只好把过去的页面都放在了 old 目录里了,等着有时间做个转向看看,幸好 Movable Type 是输出静态文件。

我这个最便宜的 VPS 只有 80MB 内存,比较吃紧。我在安装 MySQL 的时候内存飙升到了 127MB。而我的内存加上 Burstable 的才 128MB,结果直接导致机器卡死,安装失败。而且我在刚刚开始使用的时候,看了一篇讲优化的文章,照着上篇删除了一些用户和一些组,导致配置不成功。于是我干脆还原成初始镜像,从头开始。

有了第一次的经历,第二次就快多了。安装 MySQL 的时候我挺紧张,但最后还是出错了,同样是因为内存不够。我按照上面提到的那篇 MySQL 优化的文章,使用了 my-small.cnf 这个配置,在里面添加了 skip-bdb 和 skip-innodb,总算把内存占用量给降下来了。目前 MySQL 一共占用 8MB 左右的内存空间。

我还是不习惯用命令行里操纵 MySQL(SQLite 就没事,奇怪),于是安装了 phpMyAdmin。这次安装的经历比我在上一个 VPS 上在 Ubuntu 10.04 上安装的经历要好的多。上次我装完了之后,配置了半天,才把它配好。而这次因为我用的是 Lighttpd,这就方便多了。安装程序直接做好了安装文件,用 lighty-enable-mod phpmyadmin 来启用相关的模块,就可以在浏览器里面访问了。

第一次使用 Lighttpd,感觉和 Nginx 有一些不同,当中走过一些弯路,最后的结果还算不错。不过我在安装 WordPress 的时候,提示我说 WordPress 不能写 wp-config.php 文件,我查了半天权限也没看出是哪出了问题,只好按要求手动把内容复制到文件里。WordPress 可以自动升级插件、安装扩展功能,这点挺好,但需要 FTP 才行。我本来不想装 FTP 的,但因为这个,就只好装了 vsftpd。弄好了按照配置文件里的注释自己改了改,发现竟然比上次要简单、顺利。不知道是因为我已经有了经验的原因,还是 Ubuntu 和 Debian 之间的不同导致的。

安装完成之后,我现在的内存使用量大概是 55~60MB。占用最大的是 php-cgi,我在 Lighttpd 的 FastCGI 的设定里,把进程数调整为 2,这样除了一个 5.6MB 的主进程外,还有两个副进程。这两个进程经常占用内存上 16MB,让我挺头疼,所以只好限制了进程的数量。目前我的配置文件里,max-procs 我设置为 1,PHP_FCGI_CHILDREN 我设置为 2,PHP_FCGI_MAX_REQUESTS 我暂时设定为 1000。目前用着还可以,内存用到 55MB,作为个人的站点是足够了。如果将来不再弄点别的,我看看要不要再多开一个进程。或者等将来研究研究 WP Super Cache 看看能不能降低一下内存占用。

我在 GoDaddy 注册的这个域名。之前有修改 DNS 的经历,那几次都要花上大约 12 个小时才能生效。结果这次我修改到 Ramhost 的 DNS 时,我看到提示说“给我们几分钟来让设置生效”。我当时没反应过来,但过了不到半小时,我刷新浏览器,发现域名已经指向了 Ramhost 的主机了。这让我感觉很讶异,之前还没有一次这么快过呢。不知道是 GoDaddy 提升了效率,还是仅仅是个例。这也给我带来了一点小麻烦,我本来打算的是先在 GoDaddy 里面修改了 DNS,然后在等待 DNS 生效这段时间内,正好打包旧的数据。结果让我有些猝不及防,我还没开始打包呢,域名就变了。后来我发现 site5 可以通过 “IP 地址/~用户名”的方式来访问,总算是解决了问题。

这次选择了 WordPress,除了我不想再耗费精力的安装 Movable Type 外,也是我比较长期考虑的结果。

这一段时间以来,我一直使用 Movable Type,确实感觉到了一些问题。首先就是资源少,没有 theme 这个问题实在是 Movable Type 用户的心病。社区不活跃、开发也不频繁,我之前因为 Movbale Type 5 里面的 Markdown 插件在国际字符下有问题导致不能发布 Markdown 格式书写的文章的问题,提交过多次报告,等待了很多次的更新,都没有解决问题。后来还是我从一个人的 blog 上看到了解决方案。我把解决方法做成 patch 提交后,也没有什么消息。按理说这么简单的修正应该看到了马上就放进下一次更新里的。难道是 6A 的开发很紧张吗?几次更新我还真没看出什么明显改进来。

相反,WordPress 在这几年里发展很活跃,更新也很明显(这种更新可不像 Movable Type 从 4 到 5 那样)。而且它的插件也确实可以用“浩如烟海”来形容(刚刚居然忘了提 Movable Type 的插件,我从开始使用 Movable Type 到现在,从来没有安装过系统自带的之外的插件,而且还禁用过一些自带的插件)。之前我也说了,现在的插件可以自动更新。设定好了 FTP 帐号后,基本上就杜绝了手工操作 wp-content 目录的麻烦。这写都是 WordPress 进步的标志。还有就是 Movable Type 总是说静态页面的好处,但无论我怎么设定,Movable Type 就是没有需要动态访问数据库的 WordPress 快,或许和磁盘 IO 有关系?反正用了 WordPress 享受到的是更快的速度,何乐而不为呢?

但这样一来我过去的文章就没法导入 WordPress 了。我目前把就的页面都放在了 old 目录下面,等有时间再做转向吧。

从此,我暂时和 Movable Type 说“再见”。虽然不再用它了,但也算是有感情的。希望这次“再见”不会是“永别”吧。

搜索条

MT5 有非常不错的主题,名为 pico,很符合我一贯喜爱的简约风格。我从 MT4 的时候看到介绍后就很像用了。

升级到 MT5 之后,虽然我之前做了一个三栏的白色模板,用起来一直也不错,不过在看了 pico 的缩略图之后,还是觉得想试一试。于是我就在升级不久就把主题换到了 pico。

pico 看起来一切都很不错,当然不能说是完美,但比起 MT4 之前的那些默认主题可是漂亮太多了。但它有一些我不喜欢的地方是挺致命的,其中之一就是布局有些不合理。也许是过于追求表面美感了,pico 主题的搜索框竟然在页面的下方,文章结尾的后面!

我觉得搜索框这种东西,要是方便的话,一定要放在页面的最上方,调入页面后第一眼就可以看到才好。如果要像 pico 那样,就放在页面的最下方也可以,毕竟方便人们寻找。而目前的情况是,pico 中的搜索框有些上不上下不下的。由于搜索况的下面是评论汇总,因此会把搜索框顶到最下面那一屏的上面。这样给人的第一感觉就是这个页面没有搜索功能!

我前几天看页面,觉得如果能把搜索框放在导航条上,说不定能解决问题。今天晚上有点时间,就试着捣鼓了一下。没有深入研究,只是把搜索 widget 里的代码复制到导航条里的相应位置,结果弄出了这么个东西:

pico-nav-bar-search

尝试了一下,是可以使用的。不过我看来看去,总觉得相当不协调。如果把按钮去掉应该能好一些,但我又不会(HTML 没怎么研究过),而且也不是很完美。总的来说,我的图形设计能力是相当的差的,只能在以后看看别人的页面设计,能不能有所启发了。