今天早上收到了Ghost发来更新邮件，Ghost正式放出了0.5.0版本。由于一天都比较忙碌所以早上还没来得及看，下班后很兴奋的下来最新的版本体验了一番，结论就是这一次升级在表现的功能上最主要的多了多用户的功能，Ghost终于官方支持多作者模式。

更新没有遇到问题，短暂的重启应用后，马上尝试了一下新的casper(1.0)默认主题，变化有一些，但总体还是那个调调——大封面+大字体，直观大概印象的变化主要罗列为：

• 首页全幅的封面太丧心病狂了，内容直接跑第二屏...
• 明显的加强了订阅的位置，更为醒目
• 多用户的支持，使得新增加了作者的独立页面。在作者页上不仅列出了其全部作品，还可以单独订阅这个作者的文章。
• 主题的字体更大，由于还是加载了google字体所以严重影响了国内浏览的速度。

用了一会新主题，最后还是切回了这个casper旧版。我只能说新版太前卫了完全适应不过来啊...目前看来功能上需要尽快跟上的是单独的作者页。现阶段还是有点忙，等过段时间再说吧...

暴露静态内容的代码仍然在core/server/middleware/index.js中，像我这样有部分静态页面的可以直接找到// Static assets的区域添加自己的静态文件路径。

为了加快后台的速度，安装完后最好还要去掉Google字体的引用，模板文件位于core/server/views，将default.hb中的Google font引用注释掉。

<!-- <link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Open+Sans:400,300,700" /> -->

当时从wordpress切到ghost的时候，理所当然的多用户Ghost居然都不支持，到现在，Ghost不断发展和完善，已经越来越接近一个博客最核心功能的绝大部分。看着这样一个优秀的博客系统的成长，甚是欣慰。但愿其不要发展的像wordpress那般臃肿不堪，一直简单下去。

今年年初的时候，将博客整体从WordPress迁移到了新的Ghost平台，当初对原来的WordPress的评论的迁移没能做好功课，以至于在大半年的这段时间里都一直没能完整迁移。一开始以为Disqus的默认账户系统无法兼容WordPress的邮件帐号，现在看来我实在太傻太想当然了，这么大的市场，Disqus又怎么会放弃？所以，将评论从WordPress迁移到Disqus是可行的，只不过步骤可能会有点繁琐。

大概的操作步骤是：

1. 在原来的wordpress上安装disqus的插件，通过插件管理页面上的“导出到disqus”功能，将wordpress的评论同步导出至Disqus的系统里。
2. Disqus会将数据导入到其系统中，对于没有对应Disqus帐号的邮件地址，在Disqus里对应的链接就是空的，但不影响评论的显示。导入的过程会持续一段时间，完成后系统将会有邮件通知。
3. 如果URL的规则已经有所更改，那么就需要将旧的URL映射到新的URL上并合并重复的评论内容。这需要使用Disqus的URL Mapper功能，通过上传一个CSV的URL映射表，将所有相同URL的评论合并起来。

对于我这种已经迁移至Ghost的用户，为了不影响线上正在运行的博客，还得先用子域名和数据库备份恢复原来的wordpress，然后再从Disqus导出URL做整体的URL映射。

经过了一系列折腾的步骤之后，我总算是找回了原来博客的900多条评论。对于原打算放弃的这近千条评论，却在短短几小时里失而复得，还是感觉很开心:)

把以前的留言板的评论定向到了About页面，看到上一条评论时间是7个月前，果然很是怀念啊～

从WordPress换到Ghost以来也快半年了。相对于前辈WordPress，Ghost还是非常年轻的，所以很多功能都还不完善。2个月前的0.4.2版本才刚刚支持到tag，而静态页面的支持也只是在年初。即便年轻，Ghost也没有甩开大步往前冲，其更新频率其实并不高。

之前一直使用官方提供的自启动脚本运行Ghost，好处是服务器重启后无需关心应用的启动，对于我这种不时折腾服务器的人来说还是非常实用。不过却有一个致命的缺点，就是如果服务器上同时运行数个node应用，官方脚本service ghost restart会将其他应用一并停掉，这点就相当烦人了，尽管对于单独运行一个Ghost实例的博客来说其实并没有什么影响。

我的服务器上一直用pm2运行了好几个node应用，好几次重启Ghost后忘记重启其他应用，所以最后决定让pm2一起接管Ghost。

使用pm2

pm2是一个内建负载平衡的Node应用的进程管理器。它有很多Forever不具备的功能，所以现在使用的人越来越多。

使用pm2运行Ghost和运行其他应用没什么不同：

NODE_ENV=production pm2 start index.js --name swordair

由于是运行于生产环境，所以指定了NODE_ENV=production。应用上线后就可以通过list/monit等各种命令查看运行状态，非常简单直观。

启动脚本

pm2可以自己生成自启动脚本，这点甩Forever几条街。使用起来也异常简单：

sudo pm2 startup

当然，可能会遇到下面这样的错误(至少我遇到了)，这是因为需要指定运行对应的平台。

error: missing required argument ‘platform'

我用的是ubuntu，所以在命令后附加参数ubuntu即可。其他还可以选择centos或者是redhat等。

# sudo pm2 startup ubuntu
PM2 Generating system V init script in /etc/init.d/pm2-init.sh
PM2 Making script booting at startup...
PM2 -ubuntu- Using the command chmod +x /etc/init.d/pm2-init.sh; update-rc.d pm2-init.sh defaults
 Adding system startup for /etc/init.d/pm2-init.sh ...
   /etc/rc0.d/K20pm2-init.sh -> ../init.d/pm2-init.sh
   /etc/rc1.d/K20pm2-init.sh -> ../init.d/pm2-init.sh
   /etc/rc6.d/K20pm2-init.sh -> ../init.d/pm2-init.sh
   /etc/rc2.d/S20pm2-init.sh -> ../init.d/pm2-init.sh
   /etc/rc3.d/S20pm2-init.sh -> ../init.d/pm2-init.sh
   /etc/rc4.d/S20pm2-init.sh -> ../init.d/pm2-init.sh
   /etc/rc5.d/S20pm2-init.sh -> ../init.d/pm2-init.sh

PM2 Done.

这样，Ghost就能在系统重启后也自动启动。在/etc/init.d/pm2-init.sh中添加export NODE_ENV="production"可以确保应用运行在生产环境：

export HOME="/root"
export NODE_ENV="production"

最后的效果还是不错的，我所有的node应用都由pm2接管，统一管理可以大大提高效率。观察了一小段时间，只是发现资源占用比之前稍高一些。

参考资料

1. 使用 Ghost
2. 安装Ghost & 开始尝试 - 初始化脚本
3. How To Use PM2 to Setup a Node.js Production Environment On An Ubuntu VPS

今天终于完成了WordPress到Ghost的内容迁移工作，4年所写的博客内容，加上一些静态的文档、资源文件，以及Demo和工具，使得整个迁移花费了相当多大时间。我更是强迫症发作，硬是把博客所有的html内容手工转成markdown格式。

更换平台的契机，是因为WordPress的这几次更新，改了改后台配色，显得愈发臃肿起来。虽然WP经过改造是可以完成诸如支持markdown，不过自己也明白，WP这样完备的系统已经不适再作为小而美的博客发布平台。起初也打算自己用nodejs写一个简单的博客，不过应该可以想象到其实自己并没有这种精力和时间。

随后，我就找到了Ghost。

Ghost可以说满足了我的全部需求，markdown的输入环境，即时的预览效率，nodejs+express的强力组合，连模板系统都是自己也打算使用的Handlebars。与我选型唯一的不同，就是Ghost数据库默认选择了SQlite，而非NoSQL。而且，Ghost脱胎于WordPress，其最初目的本来就是专注于博客的小型系统，最早的方案其实是精简WordPress，但后台激进的采用了nodejs，展现出来的效果也确实是脱胎换骨。试用了一下之后，就下决心换了:)

当然，Ghost也并非完美，甚至可以说还远远不够好。当前版本0.3.3，还有一大堆功能都没有实现，只存在于线路图里。但我相信，Ghost会在不久的将来逐渐取代小型博客的WordPress，特别是惯用node而非php的前端工作者。

Ghost没有内建评论系统，并且也没有这个打算，而是将评论托管给第三方。这点对于国外来说没什么问题，但对于国内而言是比较糟糕的，因为第三方评论系统在G-F-W的威力下是经常抽风的。短期内，使用Ghost要付出的最大代价就是失去评论功能——这点我纠结了很久，不过最后还是决定放弃。虽然缺少了交流的氛围，但有时候想想自己一个人在博客上自言自语也并不是坏事。不用顾及评论的吐槽，不必花时间管理垃圾评论，一个博主所要做的事就变成了——发布内容到Web。撇开其他的干扰，写出一个真实的自己，想来也是种不错的感觉吧～

目前迁移算是结束了，DNS也已经切换完成。这里感谢淘宝的非常长同学，长期合租给我稳定VPS。如今，我乘着换平台的机会，搬到了linode上。感谢他之前两年的照顾，谢谢！

默认主题会先用一段时间，在有时间的时候会重新做一个自己的主题。Hello, Ghost! Hello, 2014!

2013年十二月的最后一天了，是个挺特殊的日子，很适合和旧的过去道别。当然，放弃WordPress并不是放弃博客，2014新年里，我的博客将会全部迁移至Ghost平台。实际上我已经这么做了，只是由于4年多所写的博客内容也不少，外加上有些洁癖，整个迁移过程比想象的更花时间。

我从2009年开始一直使用WordPress至今，撰写了超过200篇博文。而这过程中，WordPress版本从2.5不断演化到到如今的3.8，其已经不再仅仅是一个知名的博客平台，人们更多地将其作为CMS使用。WordPress并非不好，只是对于纯粹的博客而言，他越来越显得笨拙。这种笨拙终于在人们的喜新厌旧中被唾弃。我想用markdown来撰写内容，WordPress可以做到；我想更简单地控制代码输出，WordPress也可以做到；实际上，很少有WordPress做不到的，但WordPress却无法做得足够干净利落。当有一个新的事物漂亮地满足了所有新的需求的时候，变迁也就悄悄地开始了。

因为Ghost是nodejs平台，目前配置需要root权限，所以我还特意买了linode的vps，使得整个成本一下子上升了很多。更换配置没有花很多时间，但是内容迁移就不同。更糟糕的是我这种有强迫症的人，非要手工将以前的文字从html转成markdown，就更加蛋疼了。加上还有很多静态页面的链接跳转映射，使得原本预计今天前完成的迁移工作，不得不延期到明年…

但不管如何，今天还是要和使用了4年的WordPress道个别。同时也和各位看官道个别，因为Ghost没有内建评论功能，所以，这篇文章算是最后吐槽博主葵中剑的地方了:)

Goodbye, WordPress. Goodbye, 2013.

WordPress在进步，当然也日渐肥胖，很多新功能对于像我这样单纯的博主而言没什么实际用途，反倒是一种负担。我从WordPress2.5开始使用至今，虽然也一直有自动更新版本，但说实话，当真没在意过新版本多了哪些新功能。所以直到同事问我一个关于Featured Image的问题的时候，我的第一反应就是，这货是个啥呀？

原来WP在2.9时添加了一个文章略缩图(Post Thumbnails)，3.0时更名为精选图片(Featured Image)——我没用过中文版，不知道是不是这么翻译的。这个功能允许文章关联一张图片作为缩略图，显示在list页里。好吧，我深深地OUT了。作为一个2.5版本的WPer制作的主题自然也就只有2.5级别，也难怪自2.7以后的WP主题审核之复杂渐渐突破了天际、各种API要求令人眼花缭乱了。

Google了一下，sitepoint 的这篇 How to Add Featured Image Thumbnails to Your WordPress Theme 说的挺清楚的，马上如法炮制一下吧～不过老版本WP里方法 add_theme_support 并不存在，所以为了使主题更好的兼容旧版本的WP，文中直接调用的方式有些不妥，起码应该检测一下再调用：

if (function_exists('add_theme_support')) {
	add_theme_support('post-thumbnails');
}

这种兼容对于像我这种老版的主题来说非常有必要，现在的WP真的是越来越肥硕了，哪天倒回去用WP旧版也说不定。将上面的代码加入 function.php 之后，再在循环里调用 the_post_thumbnail 显示当前文章的 Featured Image 就行了。当然使用前也应该验证下函数：

if(function_exists('has_post_thumbnail') && has_post_thumbnail()) the_post_thumbnail();

再添加一些必要的样式就成了。不过当我做完这些发现一个问题，就是新版媒体管理器在选择 Featured Image 的时候居然无法指定图片的尺寸！我了个去～

这算Bug么？由内容发布者决定图片的尺寸不是理所当然的么？但现在，一旦选择 Set featured image 跳转到媒体库，选择任何图片都不会出现尺寸选项，但这些选项在常规添加图片到文章的时候都是存在而且正常的...似乎这是一个问题，随后我在 wordpress.org 官方论坛找到这么个描述完全相符的帖子：Featured Image Sizes Missing - 3.5，可惜到现在3.5.1问题似乎并没有被解决。

所有设置缩略图大小的方法得到的结果都只是等比例缩放或裁剪原图，并没有调用后台已经处理过的缩略图(150x150)。看来只能通过在主题调用处指定图片尺寸是最快的解决方法，不过有点一刀切了：

the_post_thumbnail('thumbnail')

希望这个问题早点被解决。最后我虽然在主题了加入了这个功能，但没打算去用它。可能出于习惯，自己的WP使用层次似乎永远停在了2.5时期...

众所周知WordPress会对编辑器里的内容再格式化一遍，比如自动分段。但有些时候这些添加的格式反而也会让人很头疼。最近帮助一个客户处理类似的问题，遇到了 WordPress 在 input 和 select 前会插入额外的换行即 <br>，从而彻底破坏了页面样式。

随后，我用自己博客做了相同的Test，没有发现相同问题，可见格式化和版本有直接关系。客户使用的是WP3.3.2，而我始终更新 WordPress 到最新版本(虽然WP越来越臃肿，但软件更新还是必须的)。然后我查了一下，看到是一个 wpautop 函数在起作用，于是立刻查看了对应的代码，以及将新旧版本做了一个比对。这个函数位于 wp-includes 中的 formatting.php 这个文件里：

function wpautop($pee, $br = true) {
	//......
}

不同版本有细微区别，在3.5中的 $br = true ，在3.3.2里，则是 $br = 1。但作用确是相同的，设置为 false 或者 0 就可以阻止 WordPress 添加额外的换行。但这么做未免有些小题大作，很多时候我们甚至非常需要WP的自动格式，原因是并非所有的WP站长或者作者都是前端开发人员，他们不可能用纯HTML代码来编写网站内容。所以，为了解决客户遇到的 input 和 select 前的额外换行并将其移除，其实有更温和的办法。

依然是在这个 wpautop 函数里，两个版本都有一句对 $allblocks 变量的定义，对比之后，它们的细微差别正好就是我所遇到的版本格式化差异。查看代码就会发现，这段代码涉及了一连串的正则替换，其中就有换行的添加。

WordPress 3.3.2

$allblocks = '(?:table|thead|tfoot|caption|col|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|option|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr|fieldset|legend|section|article|aside|hgroup|header|footer|nav|figure|figcaption|details|menu|summary)';

WordPress 3.5

$allblocks = '(?:table|thead|tfoot|caption|col|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|option|form|map|area|blockquote|address|math|style|p|h[1-6]|hr|fieldset|noscript|samp|legend|section|article|aside|hgroup|header|footer|nav|figure|figcaption|details|menu|summary)';

删除这个定义里对应标签就能避免这个标签被 WordPress 额外格式化，也就避免了额外的换行。

到这里，客户的问题就完整解决了。改动也非常小，而且等到他下次从3.3.2更新到3.5的时候，也不需要重置这个问题。因为随着版本的更新，他可能再也不会遇到这个问题了:)

顺便提上一句，其实从 WP 3.5 开始的那个媒体管理器非常好用，虽然WP越来越肥是众所周知，不过这次的更新我还是要顶它的！

2 January 2014 update: 博客迁移至Ghost之后，不会限制任何的RSS输出，下文的内容只针对WordPress。

写博客，越写越杂乱。当回过神来的时候，发觉自己博客已经有了159篇文章，23个分类，295个标签。当初技术博客的影子也渐渐淡化，生活和兴趣也逐渐占据了很大部分的内容。之前我还专门添加了一个 featured 的分类，用来存放一些个人技术类的精选文章，并且希望关注技术的订阅者可以转向到这个分类里，避免被我日渐繁多的个人内容打扰。不过似乎效果不佳，因为我看到 google reader 的统计里，绝大部分的人仍然还是订阅了我整个博客。所以这样做，显然还不够。

于是我必须寻找一些其他办法，然后我就找到了一些从RSS源里剔除某些分类、某些文章的插件，分别是“将某分类从RSS里移除”的插件 Ultimate Category Excluder 以及“将某篇文章从RSS里移除”的插件 Stealth Publish。两者除了能将文章和分类从RSS里移除之外，还能将它们从前台页面以及存档页里一并移除。

后来我安装的是 Ultimate Category Excluder，并将 ACG / Activities / Blog / Life / Movie 这些个人气息浓郁的分类统统从RSS里移除了。这样通过RSS订阅我博客的读者就在也不会受到我的个人博客的打扰，我只需将技术相关的内容提供给他们。而关心我的朋友，仍然可以来到我的博客，看看一个修电脑的好人的其他生活。

当然，其实自己也不得不承认，当自己达到一定的瓶颈之后，博客的成长也随之减缓。随着年龄的缓慢增加，对于技术的敏感度也不可避免有些热情消减。加之最近工作和生活上的忙碌，一转眼，我居然这么就久没有更新博客，这在这些年里，也绝对是少有的事。虽然草稿箱里的半成品稿件已经堆了许多，但真正等我忙完了身边的事，恐怕已经要到今年年底了。

博客还是得好好写的，无论是技术，还是生活，不写往往觉得生活和工作有些飘忽和迷失。“记录”这件事，本来就不应该“停止”。

不知道是从何时起自己博客的Pingback挂掉了，自己也因为长期没有收到什么Pingback最终还是发觉了这个问题，只是，平时就比较繁忙加之这个功能缺失并无太大的影响，于是就一直搁置在一旁，结果一搁就是1年了。在多次自己文章Pingback失败之后我再也无法忍受这种文章的孤立感，在这种积怨的驱动下，我居然整整花了大约有1天时间来查原因，无奈双重问题让我走了一些弯路，不过最后还是顺利解决了。然后，我打算记录下这一路查错的过程，也许需要的人可能会用到。

一开始，我能想到的就是配置问题，我直接Google了 pingback wordpress not working，并查看了前三页所有的文章，结果没有一个有效。我尝试了很多配置，修改htaccess放宽权限、修改config文件等待，不过问题似乎不是出在这种地方。

随后我怀疑是主题的问题，但我切回默认主题后问题依旧。我尝试禁用所有的插件，但问题依旧(后来发觉并非如此)。我尝试升级wordpress到最新，还是无效。我的博客既发不出也收不到Pingback。

出于某种不爽的情绪，我索性阅读了 Pingback 1.0定义。从这份定义文档里，以及 Quest for Self Pingbacks 一文里，我了解了wordpress的Pingback做了些什么：

1. 当一篇文章发布的时候，wordpress检测并根据设置，对文章里的链接进行Ping的操作。它会安排Ping回的事件并立即执行。
2. 目标收到Ping之后，会检查源页面里是否含有目标页面的URL，并检查title等其它要素。
3. 通过检测后，目标页生成一个新的评论。

简单的搜索后没有发现合适的Pingback调试工具，无奈只好下载 xmlrpc for php 库，自己做客户端发送Pingback做测试。又是阅读了一堆使用文档，然后终于断断续续地写了这些测试代码：

require_once('./lib/xmlrpc/xmlrpc.inc');

$site_linking_from = "http://www.swordair.com/blog/2011/07/666";
$site_linking_to = "http://www.swordair.com/blog/2010/12/522";

$host_url = "swordair.com";

$xmlrpc_client = new xmlrpc_client("/blog/xmlrpc.php", $host_url, 80);
$xmlrpc_client->setDebug(1);

$xmlrpc_message = new xmlrpcmsg("pingback.ping", array(new xmlrpcval($site_linking_from),new xmlrpcval($site_linking_to)));
$xmlrpc_response = $xmlrpc_client->send($xmlrpc_message);

echo $xmlrpc_response->faultString();

但光有这些还不够，我还得trace下wordpress的部分代码。在最新版3.3.1里，处理xmlrpc的是 xmlrpc.php，在页面中由下面的代码指定：

<link rel="pingback" href="http://www.swordair.com/blog/xmlrpc.php" />

这个文件里，真正处理xmlrpc的wordpress xmlrpc实现是其引用的 class-wp-xmlrpc-server.php，在 class-wp-xmlrpc-server.php 第3409行就是处理pingback的回调函数：

/**
 * Retrieves a pingback and registers it.
 *
 * @since 1.5.0
 *
 * @param array $args Method parameters.
 * @return array
 */
function pingback_ping($args) {

然后，浏览了一下这个处理函数，其中的错误信息正好就是 Pingback 1.0定义 里的错误类型，只是wordpress检测时的顺序稍有差异：

ERROR 33: The specified target URL cannot be used as a target. It either doesn't exist, or it is not a pingback-enabled resource.
ERROR 00: The source URL and the target URL cannot both point to the same resource.
ERROR 48: The pingback has already been registered.
ERROR 16: The source URL does not exist.
ERROR 32: We cannot find a title on that page.

根据函数代码，这些错误表示下面的意思(光从错误信息其实还比较抽象，但是直接看代码就明白了它是如何检测的)：

• ERROR 33: 无法解析的URL，页面ID不存在或者Ping没有开启
• ERROR 00: 一个地址不能同时作为源和目标
• ERROR 48: 说明这个pingback之前已经被录入
• ERROR 16: wp_remote_fopen 返回false，即无法建立连接
• ERROR 32: 源页没有标题

这样一来，工具就齐全了。出于一些原因，我不得不在线上直接调试，于是我还特意找来Disable RSS插件禁用了wordpress的RSS生成。用上面的测试代码，加上对处理函数的分析，再加上错误信息的列表，一遍遍调试终于，Ping通了。

然而讽刺的是，当我运行测试代码，从输出力看到最后那条错误信息的时候，相当无语：Error: Please enter a valid seccode. 居然是验证码插件在作怪！

这次真心大意了，费了九牛二虎之力，居然问题出在一个插件上。尽管一开始我就禁用插件测试，但似乎是受到了当时服务器阻塞的影响，让我放松了对插件的嫌疑。实际上我从很早以前就开始使用的这个wp-seccode验证码插件一直工作良好，以前也并没有屏蔽过Pingback。不过我记得我曾经升级过一次，也许就是因为那次的升级，wp-seccode就将所有的Pingback挡在门外了。

wp-seccode简单小巧，是我喜欢的主要原因。而且垃圾评论实在很多，把验证码一关掉就蹦出来好多。所以我没打算放弃使用，而是决定直接修改插件。

在 pingback_ping 函数的最后可以看到评论是如何生成的：

$commentdata = compact('comment_post_ID', 'comment_author', 'comment_author_url', 'comment_author_email', 'comment_content', 'comment_type');

$comment_ID = wp_new_comment($commentdata);
do_action('pingback_post', $comment_ID);

return sprintf(__('Pingback from %1$s to %2$s registered. Keep the web talking! :-)'), $pagelinkedfrom, $pagelinkedto);

于是我赶紧找了一下 wp_new_comment 的参考，果然，它有个 preprocess_comment 的 Hook。然后在到wp-seccode插件目录里，找到在 run.php 里的 preprocess_comment 函数，在判断位置添加了下面的代码，让插件直接略过pingback的处理：

if($commentdata['comment_type'] != 'pingback'){}

至此，Pingback终于回来了。

一番折腾终于有了结果，我不用更换插件，Pingback也能继续工作。虽然此次问题的成因非常简单，但是种种原因让我在初期错过了识别，结果导致了杀鸡用牛刀。为此我额外地阅读了Pingback的定义以及xmlrpc库的使用文档，真够蛋疼的...但以后如果再有什么有关xmlrpc以及pingback的问题，我自己都可以回来阅读此文，因为无论是在国内外，这里对于Pingback的调试说得已经相当详细:)

写第一个wordpress主题，我用了约两天的时间，设计绘制PSD稿1天，前端代码1天，但那个主题我完全已经忘记是怎么回事了，显然已经成了豆腐渣工程。一个仅仅外观比较清爽的主题，没有任何额外的思考。于是，琢磨着各种各样的想法，就有了现在这个博客所使用的主题，名字叫iline，就是"爱线条"的意思。而这个主题从开始写到现在，悄然已经过去了半年了...

3个月时间构建结构，3个月时间构建功能，有空就改进一点点，慢慢打磨出来的自己的主题，不过离完成却仍然还有很长的路要走。

最近的变化是增加用jQuery的重写了隐藏侧边栏的动画、自适应宽度和固定960px宽度的转换，以及左上角menu功能的完善。里面增加了一个PPT Extra Mode用来将内容区的文本基准放大到正常尺寸的3倍，而这时POST的文本字号会变大到48px，而标题字号更是可以达到77px。

有什么用呢？这种文字缩放和浏览器支持的缩放并不相同。尽管写这个主题的时候就考虑完全要支持浏览器的缩放，但是使用级联创造的单纯的缩放字体的效果会更好。起初的目的是让我的网页能够用来演示PPT，为此文字需要在投影仪里足够大和清晰，配合菜单提供的功能，一个简单的PPT演示应该不难实现。只是没有想到的是，这种模式同样对手持设备提供更好的访问性。

我测试了同事的Android，iPad以及iPhone，在48px字体显示效果下阅读起来都非常舒适，都不需要缩放，甚至在分辨率仅320x240的屏幕上效果仍然很好。只是这里要记录下一个关于iPhone上的safari的问题——关于-webkit-text-size-adjust这个属性。

iPhone的移动版safari是有点不同的，它会自动调整网页的内容，而其中的-webkit-text-size-adjust属性会被设置成none的默认值，这个值使得safari防止了字体大小的调节——很多时候这很有用，这样iPhone可以舒服地放大这个网页调节出合适的字体大小，但另一个方面也会造成麻烦，em的字体调节还是有着不可比拟的可访问性优势，瞬间放大所有字体，这个网页一下子变得更容易阅读，最重要的是没有多余的滚动条。所以，将这个值设置成100%后safari就不在阻止字体调整，这样调整em值就仍然有效，而且效果很赞:)

关于-webkit-text-size-adjust这个值，Safari Developer Library里有更为详细的参考，就不在这里冗叙。

未来手持设备的发展一定会颠覆一些传统的网页设计的教条。我的主题没有什么漂亮的元素，没有图的纯CSS主题——未来恐怕它也不会漂亮到那里去，但是我希望未来，它的可访问性，是出类拔萃的。

BGM @ Donna Burke - Heavens Divide -Instrumental- @ 神前暁 - あの日の記憶を追いかけて @ 中川翔子 - Ray of Light -Instrumental-

自从尝试做了swordis主题之后，对wordpress的主题也有所认识。于是决定做一个自己的主题。并且这次和上次不同，是很认真地要做完的。名字还没有想好，但是目标很明确：

• 没有图片的纯CSS主题。意味着线条和空间是首要设计元素。
• 必须过XHTML1.1以及CSS3验证。CSS3阴影和变换等，由于有前缀，所以即使使用也会暂时注释掉。
• 通过主题单元测试( Theme Unit Test )。这是一组严酷的内容兼容性检测。
• 流体布局。右边栏，因为我调查下来，比起侧边栏在左面，似乎更多人习惯在右面。
• 弹性em值。
• 兼容所有主流浏览器，包括IE6在内。

这些天从睁开眼睛开始我就在思考怎么把这个新的主题写好。主要考虑的是线条和颜色，实际上和篆刻类似，如何把自己其他方面的知识应用进去，就是这次的主要问题。

最大的挑战应该还是来自IE6的，因为这次不能写违规的hack，也不能用IE的私有属性。其实早该如此，IE6虽然仍旧苟延残喘，但是终究会被历史的洪流冲走的，我坚信这IE8成为下一个IE6的时代的来临。

前端工作类似一道工艺，相同的设计，工艺不同，价值也会天差地远。

上次试作的主题，设计用了半天，HTML化也是半天，总共才一天时间，加上才第一次做主题，自然漏洞百出。虽然大的问题暂时也没有，但是代码级别差距很大。这次截然不同，纯CSS，没有设计直接写，但是style.css我已经写了2天有余，到现在也仅仅只是有一个框架。期间数易其稿，多次改动整个布局。

现在就是主题单元测试的内容，相当周到。有多层次的页面，有混合布局、超长、超短、甚至是无标题或者无内容的文章，也有超多分类、标签的极限测试，还有何种视频嵌入，总之是应有尽有。

这次着眼于快速、准确的CSS，同时也要关注可访问性。当前使用的主题(bito)是我非常喜欢的，但也有很多缺点。这次要尽可能级联样式，并尽可能利用默认UA样式。对于这种轻量化CSS编写，CSS Rest 显得多余所以没有用。把文本字体定为14px左右(0.88em)，这样看起来才不会累吧~虽然其实主流浏览器都支持缩放，但是似乎使用这种功能的人的比例并不多。

前天粗粗看了下prototype的源码，感受颇深。这个核心框架的很多JS写法，都给了我很多启发。所以这次也打算用写JS提升下体验，尽管自己不在行。

精炼的代码，无论是C，JS之流的语言，还是CSS、html这类非语言，都应如wordpress本身所倡导的那样“代码如诗”。我很期待着自己的这个主题，期待着自己也能创造行云流水的布局，期待着自己也能哼出一段蹩脚的小诗~

终于下决心挤个时间出来做个wordpress主题。但是即使做出来估计自己也不会用的囧。

用了半天时间出了个PSD设计稿，又用了半天时间HTML化。还好设计的时候就着眼于简单，所以虽然搞了一天有些头晕，但还算比较快。基于wp的default，总的来说除了comment以外的CSS都重写了。

当然，因为刚刚写好的关系，背景图还么有整合，CSS也没有优化，并且还有众多的bug。不过没关系，作为自己第一个wp主题，慢慢琢磨就行了~

已知的问题有：

• 虽然一开始写完测试环境是通过HTML5验证的，不过自己博客上的文章一加上就超多error。
• 只用IE6和chrome开发的，所以其他浏览器情况完全未知，尽管我都尽可能的按标准来。
• 颜色问题还值得推敲，排版也有很多要微调下。
• 还有好几个小图标在绘制中，所以标签、分类、评论前面现在都还是空的。
• 功能还不全，比如搜索、RSS，还没来得及赶上去。

现在先拿出来用几天，过些时候总结出一堆问题后就可以着手改进。目标版本0.5，基本实现功能完整~

22 December 2013 update: 过往的老主题，基本已经废弃，何况现在改成了Ghost，未来应该都不会再出Wordpress主题了。

原本一天一两条左右的垃圾评论自己手工spam掉问题也不是很大，不过今天貌似特别多。一转眼就十几条，审核得有点郁闷。看来最近自己的运气不太好，被机器人频繁光顾。于是只好花点时间找个验证码插件把把关。

起初找到的是Peter's Custom Anti-Spam，似乎用的人挺多，不过看更新日期，居然还是2008-12-11，所以放弃。然后自己到wordpress插件页去找，这类插件应该不少。查找CAPTCHA(验证码)确实跳出来很多，可是我试了几个发觉不是过于复杂就是没有效果...后来选择了SI CAPTCHA Anti-Spam，这个插件无论是易用性还是功能上，都能满足要求。

这个插件功能很全，在其控制面板里有丰富的选项。可以在注册、评论、登陆启用验证，并且可以对已登陆用户隐藏验证。能改变输入顺序，还包含音频验证，flash音频验证的选项。如果觉得验证图太大，还可以启用缩小的验证图。并且在高级选项里还能设置CSS样式以及帮助信息和标签。

但并不是没有问题。

问题不是在功能上，而是外观上！验证图即使启用缩小也还是太大了~和整个主题格格不入的丑陋的扭曲的字体...都让我觉得还不够完美。另一方面，我只需要一个最最简单的验证，并不希望看到当有人要评论的时候，验证信息要看上个半天。即使我将识别度调为最容易识别，我仍然觉得有的时候跳出的验证码太过复杂难以辨认....

然后继续找，终于找到一个自己喜欢的。wangwei的wp-seccode插件(链接过期已经移出)非常轻量，再加上娇小的外观和简单直接的功能，正是我想要的。解压后仅仅8K，200行代码，相比SI CAPTCHA Anti-Spam那2.9M的体积，实在是苗条太多了: )

做了简单的测试，工作良好~功能强大是好事，但很多时候，真正契合的软件，往往精悍小巧。像我这样的博客，仅仅需要一个简单的验证来稍微阻止下机器人，过于复杂的验证只是一种负担罢了。

不过似乎wp-seccode在评论输错代码后会导致评论丢失，曾经有位朋友和我说过这事。所以现在用的是SidXSpam这个简单的插件，同样功能仅仅只是增加了一个验证码而已，所以并没有对主题风格造成什么影响。

WordPress从2.6开始就多了一个比较烦人的特性，就是 post revision 。这个特性使得作者可以回顾每次更新的文章内容，可以回滚到之前的版本。这对于多人作业的博客系统来说非常有用，但是对于单独作者的个人博客来说，显得非常无用。最糟糕的是，每次还会在wp_posts中添加新的记录，如果修改的很多的话，不一会，就会让整个数据库充满revision，而那些恰恰可能是毫无用处的。

Google后从Lester的博客上找到了解决方法，虽然还有很多其他方案，但是Lester给出的办法很有效。

要关闭post revision特性，只要在wp-config.php中加入如下行：

define('WP_POST_REVISIONS', false);

同时他还提供了删除多余revision数据的SQL语句：

DELETE a,b,c  
FROM wp_posts a  
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)  
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)  
WHERE a.post_type = 'revision'

在执行前先备份数据库。

这样一来，数据库干净了许多，revision不会再生成，但autosave仍然有效。
在Lester博客的评论里我还看到有WP-CMS可以关闭这个特性，并提供更多关于wordpress接口的控制。