在Lighttpd上使用wp-super-cache

wp-super-cache是WordPress的一个静态缓存插件，对访问量大的博客或是在系统中使用了性能较差的插件时都是挺有用的。但这个玩意需要Apache的mod_rewrite来支持，lighty下可没有这玩意儿。所以需要咱们自己添加一个lua脚本，配合lighty的mod_magnet模块来代替mod_rewrite的功能。整个操作步骤是这样的：

lighty中博客站点的配置文件要这么写：

$HTTP["host"] == "blog.elias.cn" {
  server.document-root = "/home/public_html/elias"
  magnet.attract-physical-path-to = ( server.document-root + "/rewrite.lua" )
}

这里能用magnet.attract-physical-path-to的前提是mod_magnet已经安装并启用了，否则在lighty的error.log会报错。Debian里mod_magnet是单独的一个包，叫做lighttpd-mod-magnet，安装以后就可以把mod_magnet加入lighty的配置文件了。

然后再在博客站点的根目录新建一个名为rewrite.lua的脚本文件，文件内容为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

function serve_html(cached_page)
  if (lighty.stat(cached_page)) then
    lighty.env["physical.path"] = cached_page
    print("Serving cached page: " .. cached_page)
    return true
  else
    return false
  end
end
 
function serve_gzip(cached_page)
  if (lighty.stat(cached_page .. ".gz")) then
    lighty.header["Content-Encoding"] = "gzip"
    lighty.header["Content-Type"] = ""
    lighty.env["physical.path"] = cached_page .. ".gz"
    print("Serving gzipped page: " .. cached_page .. ".gz")
    return true
  else
    return false
  end
end
 
attr = lighty.stat(lighty.env["physical.path"]) and lighty.env["physical.path"] ~= lighty.env["physical.doc-root"]
 
if (not attr) then
  lighty.env["uri.path"] = "/index.php"
  lighty.env["physical.rel-path"] = lighty.env["uri.path"]
  lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]
 
  query_condition = not (lighty.env["uri.query"] and string.find(lighty.env["uri.query"], ".*s=.*"))
  user_cookie = lighty.request["Cookie"] or "no_cookie_here"
  cookie_condition = not (string.find(user_cookie, ".*comment_author.*") or string.find(user_cookie, ".*wordpress.*") or string.find(user_cookie, ".*wp-postpass_.*"))
  if (query_condition and cookie_condition) then
    accept_encoding = lighty.request["Accept-Encoding"] or "no_acceptance"
    cached_page = lighty.env["physical.doc-root"] .. "/wp-content/cache/supercache/" .. lighty.request["Host"] .. lighty.env["request.uri"] .. "/index.html"
    cached_page = string.gsub(cached_page, "//", "/")
    if (string.find(accept_encoding, "gzip")) then
      if not serve_gzip(cached_page) then serve_html(cached_page) end
    else
      serve_html(cached_page)
    end
  end
end

这个lua脚本源自tempe.st和thedomz.com，不过我对其中的第23行做了修改。原始版本永远不会对博客首页启用缓存，因为lua脚本仅在请求的原始地址不存在时才进行重定向操作，但首页也就是博客根目录总是存在的，因此也就永远不会被重定向到静态缓存。我对这一行的修改就是让脚本在请求的地址与站点根目录相同时也启用静态缓存重定向机制。

这样折腾完之后，调整一下站点的Permalink规则，使之不要掉进wp-super-cache的忽略规则里面，应该就可以了。在页面的html源代码最后，应该能够看到super-cache的时间戳。正常工作的wp-super-cache是不会在频繁刷新页面时每次都更新这个时间戳的。附带说一下，我这个博客是没有使用wp-super-cache的，本文提及的内容应用在了blog.laiyonghao.com。

标签：Lighttpd, WordPress

转换SimplePhpBlog到WordPress

发现一直使用的SimplePhpBlog的防垃圾评论机制被突破了，与其修改源码改进其图像验证功能，干脆把整个博客迁移到WordPress了，或许这样今后的维护成本还小些。这里的数据迁移用到SimplePHPBlog import utility 网址上提供的Perl脚本工具，我进行了少量修改使之正确支持中文处理。我修改后的脚本可以从以下网址下载：WordPressImport.pl.zip 大致使用方法是：

1. 首先，这个脚本是有程序版本要求的，SimplePhpBlog 0.4.8左右的版本应该没问题，WordPress则得是2.3.*，版本不对的话脚本会报错。
2. 先用WordPress程序完成初始安装；
3. 执行“./WordPressImport.pl -noratings -host localhost -user 数据库用户名 -password -wp_password WordPress的admin密码 -database 数据库名 -import sphpblog的所在目录”，然后按照提示输入数据库访问密码即可。
4. 如果报错，通常是因为缺少Perl的必要运行库引起的，已知应该会用到Data::Format和DBD::mysql，可以考虑使用cpan安装。
5. 登陆WordPress后台，检查数据正常之后，可以将WordPress升级到最新版本，并安装喜欢的插件。
6. 建议安装并激活Word Press里面的bbcode插件，因为我遇到原先SimplePhpBlog中使用的一些编辑语法可能未被完全转换，比如有些url链接仍然是用的bbcode语法。激活bbcode之后移植过来的数据基本上又可以正常显示了。（BBCode 1.0.1版本对标签的解析存在一点Bug，会生成带多余等号的链接地址，参见关于本站页面的说明。
7. 目前文章中引用站内图片路径都是错的，所以显示不出来。把原先SimplePhpBlog里面images目录整个传到WordPress的“wp_content/uploads”目录下，然后修改并执行以下sql语句来修复站内图片链接：“update wp_posts set post_content = replace(post_content,’src=images/’,’src=http://www.YOURSITE.cn/YOUR_BLOG/wp-content/uploads/images/’)”。于是图片也能正确显示了。这里的写法和WordPress自带的媒体库管理工具一样，使用的是该死的绝对路径，将来修改博客的域名或地址时还得再重新改站内图片路径。
8. 这样日志、评论、展台都能够被正确移植过来。也许因为我的文章分类信息全是中文，迁移后的文章全部变成没有分类了，可以试着用Word Press的“Batch Categories”插件来批量调整。但我在修改了默认分类的名字之后，Batch Categories就死活搜索不出来已有文章了，最后我手工一个个调整的文章分类。建议尝试一下在导入SimplePhpBlog数据后，在旧版本的WordPress上使用“Batch Categories”试试，如果调整成功了再继续升级WordPress。

Ps:转换完了感觉有一点不满意：友情链接是按字母排序的，恐怕有些兄弟姐妹难免会对排座次有意见。

标签：SimplePhpBlog, WordPress, 迁移

被老板批判了博客

话说老板挺担心我答辩以后颓废散漫的生活风格，并且在百忙之中抽空视察了我的博客，认为提供的有价值信息太少，泛泛谈及个人感受的内容过多，违背了“写作”的基本目标，并且不能给人以启发。嗯～老板说的对，深有醍醐灌顶之感。因此我认为，我对本博客的定位应该就是错的，道理就像大伙儿侃大山聊家常这种事儿登不上大雅之堂道理是一样的，像我这样利用网络出版媒体发布个人性质的叽叽歪歪明显是一种对公共空间的误用。叽叽歪歪这种事情恐怕只有徐静蕾、韩寒之流适合拿来做自己的主攻方向，人民群众也喜闻乐见，毕竟娱乐大众是他们职业生涯的主要存在价值不是～

前些天留言时自称ID：liuwei的同学与老板对我博客的看法是完全一致的，抛开我个人需要因此而自省的启发意义不谈，这说明liuwei同学具有靠谱的科研素养和认真努力的主观愿望，是个培养的好苗子。

当然，老板对我在博客上写搞到了什么好东西这种事情提出了一些看法，我觉得老板说得很深刻。只是，我的本意也只是简单说明“我是如何选择并使用解决一个问题的工具的”，比如上一篇我的意思就是从事计算机科学研究，那么苹果出的笔记本会是一种不错的工具。只是恐怕因为我对文字驾驭的效果不佳，以至于这样的意思没能写出来。总之还是应该反省一下，考虑的一个方向是仔细点儿整理Wiki上的内容，搞得靠谱点儿。

预测浏览某网站/页面的网上冲浪者性别

微软adCenter Labs推出一项有关人口统计学的新预测工具，能够根据你输入的域名/链接来判断浏览这个网站/页面的网上冲浪者性别。链接在这里

此新闻从驱动之家网站看到。

SimplePhpBlog麻烦的安全问题

这两天blog的密码存储文件经常被人改掉，结果就是没法登陆。我关心的主要问题在于，这是如何发生的呢？难道说现在存在的漏洞主要问题是能够绕过用户验证执行SimplePhpBlog中的代码，暂时没细研究。虽然漏洞出现之后官方给出了0.4.5更新版，但总觉得那个版本好像也算不上很稳定，所以也还没把更新集成进来。

改了Blog的名字

把Blog的名字改成了“Elias的邪异门”，是因为忽然想起了《覆雨翻云》中邪异门门主——丈二红枪厉若海的绝世风采：特立独行中又有几分智慧和亲切。

至于为什么Blog的名字里还有一句“谁和谁或是自己”，我却是实在想不起来了……

更换blog程序为simple PHP blog

原来用的Pivot虽然通过修改代码能够解决中文评论和搜索问题，但是我还是不喜欢下载官方版本程序之后每次都手动修改一部分代码。因为安全问题，程序的更新是不可避免的，如果更新频繁，那么每次都要修改几个文件还是挺麻烦的，所以最理想官方版本能解决一切问题就好了。

这两天偶尔浏览，发现一个04年出现的叫做simple PHP blog的程序，简单易用、而且使用的人很多，目前虽然不是很完善，但是对中文的支持还不错，程序改进也不慢，所以犹豫了一天，决定暂时更换为这个blog程序了。pmwiki的blog模块我还是要等，但我估计在05年之内可能还不会很完善。至少05年，我会用simple PHP blog了，用了再说。

也许有人会问我是怎么把pivot中的数据转移入simple PHP blog的，我的答案很简单，是手动贴过来的：在本地架设php服务器，先把系统日期修改为与帖子时间差不多的日期，然后一个一个把帖子和评论手动贴过来。没办法啊，pivot的后台访问模块的代码我实在看不懂……好在目前要贴的东西不多，花了一下午时间算是搞定了。体会是：simple PHP blog目前的文字样式表达能力还不大令人满意，至少，这个东西应该支持直接贴html代码才好吧。

现在看来，很多时间都花在更换程序和转移数据上了，所以具体的东西都没什么进展……

UTF-8格式下Pivot的一个问题。

一般使用UTF-8格式的网上应用程序，只要在输出的页面中指明页面编码是UTF-8的，浏览器就可以自动采用UTF-8格式的编码进行显示。我已经能够使Pivot成功输出UTF-8标记，并且在浏览器中指定为UTF-8编码的时候页面显示正常。但是如果浏览器使用GB2312编码浏览我的Pivot，既不会显示为乱码，也不会自动跳转到UTF-8编码，而是把页面显示为一个空白页。

本条目的正文部分给出此问题的解决办法。

首页的模板中有这样一行：<title>[[weblogtitle]] » [[title]]</title>，我的Pivot设定的标题正好是中文而且是UTF-8格式，这样，当浏览器用GB2312编码来解释这一行的时候，[[title]]也即我指定的标题会变成乱码，而且把“</title>”的左半个括号吃掉，于是<title>标签没有被关闭，后文关于页面编码设置的部分、页面正文部分均无法被正确解析。

我们的目的是：即使使用GB2312来解析<title>这一行，那么仅应该是标题本身的文字成为乱码，但是</title>标签不要收到影响。于是我在“</title>”前面加了一个空格，也即原来的行变成这样：“<title> [[weblogtitle]] » [[title]] </title>”。注意，“[[title]]”和“</title>”之间有一个英文空格。

如法炮制所有模板文件中的<title>行，重新生成Pivot中的所有页面，于是问题解决：大多数时候浏览器可以自动使用UTF-8格式显示我的Blog上的内容了，即使强制用GB2312显示，也能显示出乱码，而不是容易让人以为没有这一页面的空白。

如何让Pivot的评论支持中文？

以前一般都认为Pivot是不支持中文评论的，所以虽然Pivot相当优秀，但是使用它来做中文Blog的人却很少。既然本人现在选择了Pivot来作为我的Blog程序，那么就顺道在这里介绍我所使用的让Pivot的评论支持中文的办法。我自己在1.14版本测试成功了。

事实上，最近Pivot的支持论坛上已经有不少讨论如何让Pivot支持亚洲语言的办法了。其中有个叫envia的韩国人做了很多工作，而且最近给出了一个让Pivot支持韩文的补丁。对PHP有经验的兄弟不妨直接参考他的方法来搞定中文。我的方法不如他的完善，但一定可以工作，否则你也就不会看到我这个Blog了（我采用的是Pivot1.14版本）。

根据他的工作结果，我进行了简化（并不是说简化更合理，而是为了方便，以及，我能够理解……）。需要完成下面几个步骤：

　1，在Pivot的所有源代码中将函数"htmlentities"修改为"htmlspecialchars"； 　2，在pvlib.php文件中，把函数"entify"和"unentify"的函数体都注释掉； 　3，把pvl_chs.php另存为UTF8编码格式（Windows自带的记事本就可以完成这件事情），并更名为pvl_chs_utf8.php； 　4，修改Pivot的所有网页模板，把"ISO-8859"这样的编码信息全部修改为"UTF-8"。 　5，照一般步骤安装Pivot，在语言设置中选择使用pvl_chs_utf8.php。 这样，Pivot就能工作在UTF-8格式下了，评论能够正常显示了。

我的这个方法的局限性在于无法让搜索功能正常工作，或许得借助Google完成这件事情了。