移动平台稍微适合做一些专注性工作

我在 MacBook Pro 上用 Day One 写日记,总是感觉效率很低,或许是有太多干扰,随便一下 cmd+tab 就切换到别打应用看一看。我很多日记,都是用 iPad 来写的。在 iPadOS 的平台下,至少应用是全屏的。屏幕不会太大,给人浪费空间的感觉。这样更容易产生一种沉浸式的体验。

我想,如果可以用 iPad 来写博客,或许也可以拯救我的注意力。但目前用 iPad 来写博客有几个问题:

  1. 输入体验不高。排除 Smart Keyboard Folio 手感这种可以忍受的问题,主要让我难受的是在外接键盘情况中,不支持第三方输入法。苹果的键盘现在有了双拼,支持小鹤了,这不错,但重码率还是有一些的。特别是需要翻页的时候,只能通过上下方向键来执行,太影响效率。如果能通过逗号、句号,哪怕是减号、等号来翻页,我也能接受,当然最好是支持第三方输入法,可以用鹤形。

  2. 没有专门客户端。我在电脑上用的是 MarsEdit,不支持 iPadOS。我目前在用 WordPress 的客户端,比较难用,速度也很慢。当然也可以用 Ulysses,但用作写博客会有各种问题,而且他对 Markdown 的支持也很怪异,比如加个链接就需要手指点几下,不能用标准的 Markdown 语法让我觉得难受。

最后,这篇文章在 WordPress 客户端发布失败。圆圈进度条一直在转,没法停止。我只好杀后台,心里担心会不会草稿也丢失。好在最后没有。复制粘贴到 Ulysses 里发布吧。

MarsEdit 4

我曾经是 MarsEdit 3 的用户,在国外读大学期间用它写过一段时间的博客。当时遇到过使用上的问题,根据这篇文章的记录,当时我用的版本还不支持手动设定 slug,对于中文用户来说,中文标题会被忽略,生成很奇怪的文章网址。后来我开发者通过信,最终升级后解决了。

后来有了 Ulysses,它支持发布功能,所以我就开始用它来写博客。现在冷静分析,不是 MarsEdit 不好,当然它的界面太传统是一方面,但功能上是没啥缺陷的。之所以换到 Ulysses,我想是因为我花钱买了它。一份许可不算便宜,我不能买来放那里不用吧?写博客是个比较不错的用途。

回国后,虽然我写博客的时间少了,但我主要还是用 Ulysses。Ulysses 有它自身的好处,它跨设备,可以在 Mac、iPad、iPhone 上运行,并良好同步。工作时遇到需要现场发言的场景,我可以在 iPad 上打开 Ulysses 进行编辑,然后用一个字号比较大的发布模版,在 iPad 上显示,作为提纲。还有几次我需要上台演讲,我就用手机上的 Ulysses 打开在 iPad 上编写好的发言稿,还是用发布的功能,选一个看上去清晰的格式,作为提示。

我在 Ulysses 里有一个文件夹,名字叫“博客文章”,目前有 124 篇文章。我在里面写完后,通过发布功能,直接发布到我这个博客上。我感觉挺好的,特别是加上同步功能,我可以随时随地写博客。很多时候我拿出 iPad 来就可以写了,有时候躺在床上睡前也可以写。Ulysses 有即时保存功能,不想写了直接关闭即可,不怕丢失内容。

近期看到了 MarsEdit 4 发布的消息。其实早就听说了,不过当时没有兴趣。这次之所以又调查了一次,是因为又看的 John Gruber 的文章,然后还看了他在 XOXO 关于 Darring Fireball 的演讲。看到他的网站上写的他用来写作的工具,里面还是有 MarsEdit。我也不知道目前还是这样,还是他仅是没时间调整网页,不过不影响我再去看一眼 MarsEdit。

看着看着,我想还是下载一份试用版来用一用。这篇文章往前数两篇,都算是我用 MarsEdit 的尝试。给我的感觉是,和 MarsEdit 3 相比看不出很大改进。我是个怕麻烦的人,很多博客系统上有的功能,我其实懒得用,感觉对我这一个个人的博客也没啥大用,我用到的其实是最基础的功能。我看了版本 4 要收费,一度想着是不是可以用版本 3?结果版本 3 在当前的系统已经不再支持,下载下来的程序无法执行。想来想去,目前我打算在试用期结束后,花钱买一份许可。

为什么我不再继续用 Ulysses 了呢?我感觉在写博客方面,Ulysses 有些“专业不对口”。虽然它的功能足够丰富,也可以满足发布一篇博客的需求,但在管理博客方面是有些不足的。从 Ulysses 的角度上,一篇文章发布前可以做种种修改,但发布后就和我无关了。如果要修改什么东西,就只好重新发布。在结合 WordPress 来用的时候,如果我想改个错别字,就需要重新发布一次。或者我想加一个标签,也带来过发布了两篇文章的情况。而 MarsEdit,版本 3 我记不清了,版本 4 里可以把我博客里所有的文章都拉到本地,随时修改、调整,就想是一个博客的客户端一样,特别方便,这是吸引我的地方。

MarsEdit 存在的不足是对 iPadOS、iOS 系统没有支持。它是个比较传统的软件,面向的是在电脑端写博客的场景,移动平台上写博客不知道是否在他们的开发计划上。

兜兜转转

今天,把WordPress的Markdown插件换回了我最早使用的Markdown for WordPress and bbPress

当年我学会了Markdown语法后,就立刻想在写博客的时候使用。当时也是有缘,我第一个找到的就是这个插件,用着感觉很不错,一直用了好几年。后来之所以把它换掉,原因已经记不清了,似乎是和WordPress新加入的谷腾堡编辑器有关,或许和JetPack插件有关系,似乎官方已经支持Markdown语法,我就没有必要安装这个插件了。还有一个可能的原因,也是谷腾堡的锅,我用Ulysses写完博客后,直接发布会发生语法问题。

之后我又换了插件,大概是因为JetPack的速度太慢了,于是就禁用了它。找了一个WP Githuber MD插件。当时为什么没有用回Markdown for WordPress and bbPress插件我已经忘记了,是否是仍然存在问题也记不清,反正WP Githuber MD感觉挺好用的,提供的双栏编辑器界面,左边写Markdown,右边实时生成结果,很直观。不过我用不到,一方面我使用的Markdown语法非常简单,很少有写错需要看看结果的时候,再者我使用Ulysses来写,在线编辑器用的很少。

今天发现了WP Githuber MD插件的缺陷。我发现我过去文章里的Markdown语法全都失效了,开始以为是配置的原因,今天仔细看了看,没有这方面的配置。我试着从后台进入文章编辑,什么也不做,只点一下更新,再刷新页面就恢复了。我去数据库里看看,原来在进行文章编辑之后,数据库里保存的Markdown格式全部被转换成了HTML标记。看来WP Githuber MD插件的编辑器能够识别HTML标记,并转换成Markdown格式,在保存的时候再以HTML保存,但这造成了我之前文章里的Markdown失效了,因为它们没有被转换。

上网查找一下解决方案,发现现在的Markdown插件基本上都是一个原理,没有找到能够在生成页面时动态转换语法的插件,似乎功能都往即时转译去了,也就是在编辑时是Markdown,保存时会转换成HTML再保存。我好几年前用的插件就能做到在生成页面时转换,现在的主机效率应该不至于做不到吧。还看到有极端的说法是在Typora里编写,然后导出HTML后再粘到WordPress里,我实在是不知道是怎么想的。

没办法,最终还是启用了最早的Markdown for WordPress and bbPress插件。是否会出问题我还需要继续观察。

给 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 的后尘。毕竟,博客在今天已经式微,强大又稳定还能保持更新的博客系统也没多少了。

回归 WordPress

今天下午,趁加班在办公室没事,终于想起了要写写博客。想了一刻钟的时间,终于决定要把 Hugo 系统换回 WordPress。

之前我其实就考虑过这个问题,只是一直没有下定决心。当前网上的趋势是静态内容生成器逐渐替代动态生成工具,从 Hugo 换回 WordPress 似乎有点“开历史倒车”的感觉,我总觉得是自己哪个地方做的不大对,或者有哪个关节没有想明白,要不然为什么网上这么多人推荐的内容生成器我用着就这么不安稳呢?

之前博客还城 Hugo 的我似乎没有写一篇文章,在这里记录一下我由 WordPress 换到 Hugo 的理由:

  1. WordPress 越来越复杂,或者说臃肿。现在的方向似乎是往一个综合性的 CMS 系统的方向发展,用作个人博客有“杀鸡用牛刀”的感觉。
  2. 开放方向让我不适应。新的古藤堡编辑器似乎有替代传统编辑器的趋势,而我对古藤堡很不感冒。如果我是新手,我会觉得古藤堡功能强大,可我用惯了 Markdown,在古藤堡里会有各种问题,我需要的只是一个 HTML 编辑器。
  3. 越来越臃肿的程序导致了速度变慢。我不大清楚问题具体出在什么地方,但静态的网页速度快是毋庸置疑的。

而我这次下定决心,以及之前默默思考从 Hugo 换回 WordPress 的理由如下:

  1. 编辑起来不是很方便。我打算用 Emacs 来编辑,但 Emacs 的折行功能是自动在文本上加入换行符来实现的,在 Hugo 生成的网页里还会有影响。用 Emacs 之前用过 VS Code,并不是很习惯。还用过 Typora,过去在 Windows 下我都用它来编辑 WordPress 的博客,可它对 toml 的语法好像并不能识别,用起来有些不便。而如果使用 WordPress,我就又可以在 Ulysses 里写博客了。
  2. Hugo 让我不能随地写博客。虽然我把 Hugo 文件夹放进了 Dropbox 里,算是随身带着,可当我写完了一篇博客,要生成的话就需要 Hugo 的可执行文件,要发布的话还需要 rsync,都是不大方便的。
  3. 对 Disqus 的担忧。我在 Hugo 的评论系统用的也是 Disqus,我没有尝试是否在国内不能使用。我自己用的科学上网,没有敢于尝试是否能正常在 Disqus 上留言,当鸵鸟回避了这个问题。相比来看,还是 WordPress 有自己的留言系统,最为放心。
  4. Hugo 的一些难题。用了 Hugo 我遇到了一些难题一直没有学会怎么解决。首先是模板,Hugo 的模板里有太多自定义的字段,不同的模板还不一致,比方说有的模板可以用一个变量来设置 Disqus 的账号,有了这个变量,Hugo 就会在生成页面时自动插入 Disqus 的代码,而有的模板没有这个变量,有的模板是另一个变量名,让我反复修改配置文件,很麻烦混乱。第二个是路径,我的博客是放在域名的子目录下的,而我不论从 Hugo 的文档里还是网上的文章和实例,无一不是从域名或者字域名的根目录里安装的。我的情况是,生成的页面里的链接全都把我的子目录的目录名给弄没了,导致从首页里根本没法进入具体的一片文章。最后,我通过实验,发现需要把 absLangUrl() 一类的函数全都换成 relLangUrl() 才行。我不知道为何会发生这样的问题,怀疑 Hugo 的团队压根没考虑到我这种情况。还有一个问题,页面的分类、标签的页面我搞不好,在 WordPress 里反正是比较容易的。
  5. 我并不需要极致的访问速度,WordPress 做到了不错的平衡。而实际上在我这里访问服务器上的 Hugo 页面速度也并不算是飞快,感觉差距不明显。

因此,我下午把系统还了过来。过程比较顺利,我之前的目录、数据库都没动,只是改了名称并调整了 Nginx 的配置。现在只要把配置和目录名都调回来就行了。然后升级了一下该升级的,Disqus 有个同步功能,不过我还没搞明白,看介绍是可以双向同步,但我手动同步后关闭 Disqus 插件,评论还是没有出现。等将来慢慢研究吧,少的评论实际上不算多,过去有因为换 Movable Type 大量丢掉评论的经历,这次小意思啦。

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 身上。如果他俩和平分手,那问题倒还好说,可如果有其他隐情,那问题就复杂了,作为当事人,不愿意回顾和他有关的东西是顺理成章的吧。

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

Is Blogging Fun?

最近写博客的次数极大的减少,心中也有很多遗憾。

多数情况下,感觉随着年龄的增长,少了倾诉的欲望。少有几次有了感觉,甚至在心里打好了腹稿,但没有多少时间去写,好不容易想写了,又感觉没有了过去那种行云流水说写就写的感觉。除了不像过去那样有强烈的动力外,从客观上我没有找到 Windows 平台下的写作软件也有关系。

在 Mac 平台下,我用过几个专门写博客或者专门用来写作的软件。最早我尝试过 MarsEdit,用它写过不少。它最大的问题是对 WordPress 的 slug 功能支持不好,中文标题在 WordPress 里会被忽略,因此对几乎每一篇文章,我都要手动输入一个 slug。之前没有这个功能,后来有了,我也换了工具。之后我主要用 Ulysses 来写博客,它支持 Marddown,满足了我简易排版的需求。另外它对文章优秀的组织功能是我非常喜欢的。写博客不是它的全部功能,我用它也写过一些文章,有了发布功能,写博客不要太简单。

后来我因为对 Office 办公套件的需求,买了一台 Windows 笔记本,就把 MacBook Pro 给卖了。现在其实有点想念,卖它时它的质量还很棒,现在的 MacBook Pro,有了我还没有适应的 TouchBar 和蝶式键盘,让我有些望而却步。

Windows 笔记本在办公方面给了我很大的帮助,但对于工作以外其他的东西支持的并不是很完美。一个能用的 UNIX 环境,勉强配置的能用了,但写博客的软件我一直没找到。最接近的一个是 Typora,界面很美观,虽然没有发布的功能,但编辑完毕后复制到后台发布也可以。但相对于 Ulysses,Typora 缺少了文章管理功能,我的文章只能放在一个文件夹中。Ulysses 有 iPad 和 iPhone 客户端,我可以随地的编辑一篇文章,在 Typora 里就没法实现了。目前一切都在磨合之中。

现在我还没丢掉阅读 RSS 的习惯。Mac 和 iOS 系统上有 Reeder,安卓系统上没有很完美的,我目前一直在用 Inoreader 客户端,如果连这个也没了,不知道我还怎么用它。过去我喜欢读的一些作者都不再写了,让我觉得遗憾。有些转移到了微信写公众号,我一直都不适应。现在写的最多的是一些媒体,有了能盈利的模式,写起来的速度是嗖嗖的,特别有一家叫好奇心日报,老是被我骂“又臭又长”。过来的 Daring Fireball 还很高产,让我挺羡慕的。不羡慕他以此为职业,而是它的产量。

我不是媒体,不以写博客为职业,近两年来发布的文章数目渐渐到了个位,让我也比较苦恼。之前我不大愿意用 Day One 这样的日记软件,因为我觉得有些功能和博客比重复了。事实上,当我习惯了用 Day One 后,博客的发表数量便大大减少了。Day One 里的内容可以算是博客的超集,博客里不方便公开发表的,在 Day One 里写完全没关系。久而久之,我想不如干脆就在 Day One 里写吧。

当初为什么要写博客,我想有一部分原因是有趣。现在博客还有趣吗?我相信是有的。不过毕竟已经成家立业,不能由着自己的兴趣来做事情了。

大手术

最近我的网站服务器运行的比较糟糕,特别是博客部分,经常发生 500 错误,有的时候 MySQL 会被 mercy killed,导致 WordPress 无法连接到数据库,博客就挂掉了。

过去我买的比较廉价的 VPS,因此时不时就要捣鼓一下,不过自从我买了 Linode,就比较少的去上 VPS,所以近几年对 VPS 的了解也差了很多。VPS 资源不足的时候,一点资源就要精打细算,因此控制的比较好。后来的 VPS 的内存有了 1GB,想比起过去条件好了许多,我就没有在意控制,甚至编写过一个 Rails 应用,后台用的 MySQL InnoDB 引擎,那时候就觉得内存没有不够的时候。

后来经历过 MySQL 升级,默认的引擎变成了 InnoDB,我旧的配置文件一度导致 MySQL 无法启动。从那之后,我基本上没有再在意过 MySQL 资源优化的问题。这导致的问题就是,MySQL 进程经常被杀死,因为 VPS 的内存被用光了。然后我采用了一些办法,不过收效不大,最后我给博客加上了 WP Super Cache 插件,这样哪怕数据库挂掉也能访问一些页面。然后上周五写了几篇文章,发布的时候竟然出现了 500 错误,这简直不能忍受。刷新了几次发布成功文章后,我就考虑修正一下这个问题。

我想计划是不用 Apache 了,采用 Nginx。我刚用 VPS 的时候,内存很小,才 80M,当时就知道 Nginx 占用资源和 Apache 相比不是一个数量级的。当然 Apache 有它的好处,寿命很久的工程有很多插件,比如 WSGI,我安装 MoinMoin 非常方便,在 Nginx 下就要费一些事。再就是 .htaccess 等功能,Nginx 下使用不同的语法,要改变也很麻烦。不过,现在出现了资源不足的问题,我还是决心做一个尝试。我的 VPS 上目前跑的东西也不多了,主要是一个 WordPress 的博客和一个 MoinMoin 的 wiki,之前自己的 Rails 应用也不跑了,有一个 Awstats 在运行,不过现在看的也不多。

我琢磨了一下,我刚开始用 VPS 的时候,拿 Nginx+php-fpm 跑过 WordPress,经验证过基本上没什么问题,就是 Super Cache 之类的东西配置起来很不方便,实际上我的小站点不用缓存问题也不大。MoinMoin 之前有过不成功的经验,也有过成功的经验,后来入门之后,我发现用 Apache + UWSGI 跑 MoinMoin 还是挺简单的。Nginx 上我不敢确定,不过 Nginx 几年前就很火,相信现在一定有所改进。另外,我对 MoinMoin 这个 wiki 还有其它的考虑,不过没有成熟的记下来,改天在新的文章里再写写。

于是我周五晚上开始,一开始没有继续尝试修改原有的 Linode 服务器,而是从 DigitalOcean 上新建了一个 Droplet,系统还是选 Debian,因为最熟悉。从一开始安装 Nginx 到后来配置 WordPress,DigitalOcean 的帮助文档很全面,非常清晰,我还从中学会了用 rsync 从两个服务器之间同步文件。等我把数据库转移了之后,在新服务器上 WordPress 打不开了,查看错误日志,原来是 Cache 插件的问题。新服务器上没有配置插件,导致了无法显示。然后我尝试了各种其它的方法,一直没有成功。后来又尝试了一下 MoinMoin,我发现这个的文档就有些问题了,进行到了 uwsgi 配置这一步,总会有各种各样莫名其妙的不对,比如说执行了一个命令,start wsgi,而我的机器上并没有 start 这个命令,也许是 Ubuntu 特有的。我最终能做到显示一部分的页面,其它的就没有搞定。这时候时间已经到了周六的凌晨三点多,我坚持不住了,就先去睡觉了。

周六有时间就继续搞,到晚上,我重新在 Vultr 上建立了一个服务,也是用的 Debian,然后还是进行了各种配置,到了最后 WordPress 有很多页面都是 404,弄得我很郁闷,然后重新建立服务,再搞一次,发现我应该是忘记在 Nginx 上加入 index.php 的识别,最后算是弄好了。我一开始尝试导入从原 WordPress 导出的 xml 文件,结果没有成功,只导入了一部分,看来是中途出了问题。之后我还是在数据库层面导入,还是遇到了 Cache 问题。我从 wp-config.php 开始修改,一点一点删除和 cache 有关的配置和 PHP 文件,最后终于能够正常进入页面和后台,然后在控制台把 cache 相关的插件都关掉,算是正常了。

WordPress 正常了之后,我继续尝试 MoinMoin,很郁闷的是在 uWSGI 这一步怎么也无法正常。我发现 Python 应用这一部分的文档很不完善,而且不同的系统之间也有差异。比如,我从网上找到过在 Ubuntu 下的配置方式,按理说它和 Debian 血缘很近,但两者之间就不同用,还有 CentOS 系统下的配置说明,又是一种方法。MoinMoin 上有 Nginx 下配置的方法,从我的 Debian 服务器里就不能正常工作;Nginx 的页面有 MoinMoin 的配置实例,写的非常简洁,我看的云里雾里,最终还是放弃,等再找时间看看。我之前已经配置成功过,没理由这次会失败。不过这不是一个短时间能够完成的任务,还是找其它时间吧,毕竟 wiki 是给我自己看的记录,短期不上线也问题不大。

剩下的就是 Awstats 的迁移了,我还没有开始进行。另外 Shadowsocks 应该也不难,我看看 Linode 什么时候到期,再决定是继续用 Vultr 还是在 Linode 上新建一个 node。

给博客安装了 WP Super Cache 缓存

昨天我写到给博客添加了 memcache 和 batcache 缓存。memcache 通过 WP-ServerInfo 插件看到了命中率,应该是没问题了。

batcache 我本来以为安装成功了,不过到了晚上查了一番资料,原来之前我在 </head> 前看到的一串随机值并不是 batcache 的标记,正确的标记应该是写在注释里,说明了页面生成的时间。我找到了几篇文章,按照文章里说的对 advance-cache.php 文件进行调整,结果一直不行。

之后我想,既然 batcache 无法使用,我干脆就用 WP Super Cache 吧。WP Super Cache 跟 batcache 一样是缓存插件,但 batcache 是缓存在内存中的,而 WP Super Cache 是直接生成 HTML 文件,存储在硬盘中,访问的时候直接调去,而不用再读取数据库生成,这样极大的减轻了数据库的负担,也解决了我的问题。更方便的是,比起虚无缥缈的内存,在硬盘中的文件则是实实在在的,可以很容易看到效果。

过去我用过 WP Super Cache,那时我刚从 Movable Type 转换过来,看到了什么好东西都要用上,而 WP Super Cache 插件则是很有名的缓存插件。当时我还没敢用 Linode 这样高大上的 VPS,用的 Ramhost 的比较低的配置,所以将博客静态化也可以很好的提升性能。不过,那时因为 VPS 内存小,我用的是 Nginx 服务器,转发规则等配置跟 Apache 有些不同。我在上面跑 WordPress 本身就要调整设置了,再加上 WP Super Cache 给出的复杂的 .htaccess 配置,我是无论如何都无法将它转换成 Nginx 配置的。结果照着网上的教程,最后也不知道配置成功了没有,自己也没有觉得博客速度有所提升。现在我直接用上了 Apache,省了大量的麻烦,WP Super Cache 也很容易的就装上了。通过查看页面代码,也能在末尾看到记录生成时间的注释,说明安装成功。

另外,我印象里,在过去安装 WP Super Cache 时,推荐使用 mod_rewrite 来进行转向,而这次安装,推荐的则是通过 PHP 来转向,不知道是为了什么。看网上说,用 mod_rewrite 可以直接让网页服务器来转向,不用发动 PHP 运行,速度最快,所以我也用了 mod_rewrite

我想这样可以完全解决博客数据库崩溃的问题了吧。

为博客添加缓存

自从我给 VPS 升级了之后,MySQL 就经常容易出问题,不知道什么原因就会挂掉,导致博客无法访问,以及 Fever 不能正常更新。我已经很长时间没有管理 VPS 后台了,因此也无法找到问题的原因,从网上搜索也没有找到类似的例子,只是从 LISH 后台看到过可能是资源耗尽。

我过去可从来没有往这个方向去想,因为我的 VPS 只跑一个每多少流量的 WordPress 博客、一个自己写的小 Rails 程序、一个 MoinMoin、一个 Fever RSS。这些小型的东西要耗尽 VPS 的资源基本不可能,我的 VPS 还是 Linode 的,过去用着一直很好。

不过从后台的数据上看起来到是真的,应该是新的版本的系统哪个地方进行了修改,导致了问题,不过我是没有精力来解决了。但这问题实在是恼人,经常一刷新,博客不能访问,我只好重启 MySQL 服务,要么直接重启 VPS,但过几天又会发生。

昨天又一次发生了问题,我实在忍不了,于是就上网找了一下缓存方面的解决方案。我记得过去我用过某种 cache,搜索了一下叫 WP Super Cache,但不知道现在还能不能用。然后找到了我爱水煮鱼的网站,他的网站上有很多关于 WordPress 优化的文章,我过去也看过,不过已经有好几年每再看了。看到他还一直坚持较高频率的发表博客,真是感动。

通过我爱水煮鱼的博客,我回顾起了 memcache 等优化工具,于是安装了 Memcached 插件,还有 batcache,据说是 WP Super Cache 的内存版本。我很久没有关注这些,于是囫囵吞枣,也没有管其他,只要让它们能够运行就好了。我看到我爱水煮鱼的网页上的 memcache 命中率统计挺好看的,但不知道是哪个插件,于是自己找了个 WP-ServerInfo 插件装上了,也能显示命中率。

目前我的命中率是 99.43%,算是很高,不过我不知道如何看命中的详情,因此也不确定是否有效果,只好让时间来验证了。如果一段时间,我的数据库不崩溃,就算是他有效吧。batcache 也是,不像 WP Super Cache 那样,可以在硬盘上生成网页,这样我就能够直接看到效果。它是在内存里保存缓存的内容,我看不到结果。同样也让时间来验证吧。