博客管理

只是为了记录博客管理用的

修复 WordPress 插件 Collapsing Archives 在 PHP8 下不能使用的问题

使用 Collapsing Archives 这个 WordPress 插件很多年了,就是本文右边能看到的历年存档,可以很漂亮折叠起来,而不是官方默认插件只能按年聚合,不能展开看有哪些文章

但是在 WordPress 升级到某个版本,及容器升级到 PHP8 后,只要开启这个插件,必然整个 WP 站都挂的,开 WordPress Debugging 看报错信息也没有头绪,没有可以联系作者的渠道,在 WordPress 论坛反馈也没反应

其中一个普遍的报错是

[error] 1088#1088: *266661 FastCGI sent in stderr: “PHP message: PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, class collapsArch does not have a method “enqueue_scripts” in /home/foo/www/blog/wp-includes/class-wp-hook.php:307

这个问题参考 https://wordpress.org/support/topic/an-error-occurred-11/#post-15472977 获得了解决,具体办法是到 ~/wp-content/plugins/collapsing-archives/ 目录下修改 collapsArch.php 的 42 行,从

if (!is_admin()) {
    wp_enqueue_script('jquery');
    add_action( 'wp_enqueue_scripts', array( 'collapsArch', 'enqueue_scripts' ) );
} else {

改为

if (!is_admin()) {
    wp_enqueue_script('jquery');
    add_action( 'wp_head', array( 'collapsArch', 'get_head' ) );
} else {

但是问题依然没有解决,还有一处拼写错误需要修改,参考 https://wordpress.org/support/topic/great-until-php-8/#post-16349890 的办法,在 ~/wp-content/plugins/collapsing-archives/ 目录下修改 defaults.php 的 27 行,从

  'post_type' => 'post',
  'taxoncmy' => 'category',
  'postTitleLength' => '');

改为

  'post_type' => 'post',
  'taxonomy' => 'category',
  'postTitleLength' => '');

至此,重新启用插件恢复正常

奇怪流量的终结

曾经有爆流量记这一篇博文提到之前租的空间被下 Win7 的请求爆流量, 在迁到自己的 VPS 后发现还是有对 Win7 的请求, 还附加了一个奇怪的隔一小会就发个 HEAD 请求, UA 中带 QQDownload 的奇怪来源 (BuyVM VPS 安装优化记)

作为日志洁癖者看着 nginx 的 access.log 里都是这种请求那自然是各种不爽, 之前一直怀疑 Win7 的请求来自旋风或迅雷, 但苦于木有证据, 这次特意又去查了下旋风和迅雷的离线服务器列表 (比如百度空间上用于 eMule 避免吸血的这篇: http://hi.baidu.com/asp502010/item/44ac169b289dd2d91a49df6d), 对比了下 IP 范围, 还是不在里面, 有点失望

不过这次有意外发现, 那就是 UA 里带 QQDownload 的那个, 虽然我知道这个 UA 串未必就是旋风发来的, 可能也只是老版本旋风 (这次 UA 是里版本号是 713, 我看了下最新的旋风应该是 783) 安装后改了系统的 UA 串, 但不管怎样总是有可以胡搅蛮缠的由头, 于是通过之前在旋风实习过的 momodi 联系上旋风的工程师, 直接吐槽

叶文/Snoopy阿排 15:43:29
hi, 非常抱歉冒昧打扰

我碰到的问题是这样的:
我自己有一个域名 yewen.us, 曾经指向我前公司内网里的一台机器, 提供前公司可激活的 windows 7 iso 文件下载, 可能被前同事用不同的下载工具 (如旋风, 迅雷等) 下载过, 并被计入链接库, 于是一直有外部请求来下这个文件
但是我一年多前就移除了这个文件, 对应的下载请求都返回 404, 但一直还在被抓 (后来没办法还改过 302, 416 等错误返回码, 都无效)

最近我仔细看了下我 nginx 的日志, 最近有大量带 QQDownload 标识的请求, 同时请求那个 win7 iso 的量也很大, 所以怀疑是不是 QQ 旋风没有正确处理错误返回码, 一直没把这个已失效的地址去除

之前写过一篇 blog 来分析: http://www.yewen.us/blog/2012/02/overflow/

从昨天晚上到今天上午的 nginx 日志分析:
$ grep “QQDownload” vyewenus.access.log | awk ‘{cnt[$1]++};END{for(ip in cnt){print ip, cnt[ip]}}’ | sort
101.226.68.137 196
140.207.54.139 195
183.195.232.138 196
$ grep “cn_windows_7_professional_x86_dvd_x15-65790” vyewenus.access.log | awk ‘{cnt[$1]++};END{for(ip in cnt){print ip, cnt[ip]}}’ | sort
122.141.67.50 329
123.185.52.73 54
14.114.226.18 150
14.114.226.194 14677
14.115.129.55 4040
180.117.68.185 361
59.33.63.137 1476

抽几条完整日志如下:
101.226.68.137 – – [21/Apr/2013:19:44:18 +0800] “HEAD / HTTP/1.1” 200 0 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; QQDownload 713; .NET CLR 2.0.50727; InfoPath.2)”
14.115.129.55 – – [21/Apr/2013:19:44:18 +0800] “GET /ftp/Win7_rtm_with_loader/cn_windows_7_professional_x86_dvd_x15-65790.iso HTTP/1.1” 416 615 “http://yewen.us/” “Mozilla/4.0 (compatible; MSIE 9.0; Windows
NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)”
14.115.129.55 – – [21/Apr/2013:19:44:22 +0800] “GET /ftp/Win7_rtm_with_loader/cn_windows_7_professional_x86_dvd_x15-65790.iso HTTP/1.1” 416 615 “http://yewen.us/” “Mozilla/4.0 (compatible; MSIE 9.0; Windows
NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)”
14.115.129.55 – – [21/Apr/2013:19:44:25 +0800] “GET /ftp/Win7_rtm_with_loader/cn_windows_7_professional_x86_dvd_x15-65790.iso HTTP/1.1” 416 615 “http://yewen.us/” “Mozilla/4.0 (compatible; MSIE 9.0; Windows
NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)”
叶文/Snoopy阿排 15:44:00

请帮验证下那几个大量请求的 IP 地址是否是旋风离线服务器发起的

QQ旋风 15:44:19
你能否自己屏蔽了?

叶文/Snoopy阿排 15:46:01
我现在已经返回 416 错误码了, 流量也不是太大问题, 只是很奇怪为什么我都返回错误码一年多了还在被抓, 而且 IP 不一定固定 (我怀疑可能存在 “某下载工具的地址库存了这个链接, 用户可能会直接请求” 的情况)

后面的沟通基本就是礼节性的再提供点证据, 旋风的工程师没直说这几个请求是否是旋风自己的, 只说可能库里确实有脏数据, 给我看看, 至于老版本如果有缓存了这个信息, 那就没办法了. 隔天早上联系我说确实从库里找到这么一条记录, 已经删除, 让我再看看日志, 这次过去看了下, 果然对 win7 的所有请求都没了

这个事应该就算解决了, 之前虽然有怀疑但一直没去付诸行动, 果然有问题直接找到工程师才算比较快的解决方法, 像我这种 “刁民” 应该也会给他们带来计划外工作量, 不过确实是自家 bug 那也没什么好说的, 上次提到那个多说评论显示错误的问题, 最后也是找多说工程师直接解决. 旋风的哥们帮解决这个问题后还很好奇的问了句, 你还关注日志啊, er, 可以说这已经成职业病了么, 互相呵呵了下也就结了

过了两天发现那个奇怪的 UA 串发来的 HEAD 请求还有, 这次再问旋风那边他们就也不知道怎么回事了, 放 Google 搜了下找到 http://www.postsila.com/thread-193359-1-1.html 这么一篇, 跟我遇到一样的问题, 也不明所以, 不过还好这个请求来源比较固定, 从 access.log 里搜了下对应 IP 除了发 HEAD 请求没有任何正常用户行为, 那就开 iptables 屏蔽掉就行了

$ sudo /sbin/iptables -I INPUT -s 101.226.68.137 -j DROP

封了几天再看日志, 还在请求, 本来还想 ws 的通过 dnspod 能不能直接拒绝掉, 研究了下 dns 真干不了这事. 算了算了, 自己都屏蔽掉了那就这样吧, 看下日志还在涨

$ sudo /sbin/iptables -L -n -v --line-numbers
Chain INPUT (policy ACCEPT 529K packets, 835M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     3311  199K DROP       all  --  *      *       183.195.232.138      0.0.0.0/0
2     3229  194K DROP       all  --  *      *       140.207.54.139       0.0.0.0/0
3     3304  198K DROP       all  --  *      *       101.226.68.137       0.0.0.0/0

除掉这俩后再看日志, 最大的来源就是 dnspod 的定时监控和各搜索引擎和 Feed 订阅器的抓站. 想了下小破站挂就挂, 没那么严苛的可用时间要求, 去 dnspod 把监控间隔调到最长, 搞定

最后, 看了下之前租的空间还有流量, 再打开日志, 发现都是来自 youdao 爬虫的数据, 话说我都换了域名 IP 指向一周了, 怎么你们还在抓以前 IP 啊, DNS 不更新么

BuyVM VPS 安装优化记

BuyVM 的 VPS

早两周忘了是谁提醒了下, 说 buyvm 家 15$/yr 的 VPS 有货, 非常值得去抢, 当时估算了下这个价格确实算良心价, 虽然只有 128M 内存, 但作为一台自己的 vps 折腾点东西完全都够了的, 果断下手一台

这台机器打算拿来放一些自己玩的小程序, 同时把个人的空间和 blog 迁过来, 本还想拿这个机器做自己私有的翻墙中继, 不过试了下到本地的速度最高也没超过 30KB/s 过, 遂放弃, 等啥时候有烧包需要时去买 linode 在日本的节点好了

系统选择和基本设置

之前自己用 debian-server 做纯服务端的东西感觉很爽, 占资源少文档丰富, 出点问题也能很容易在 Google 帮助下搞定, 所以系统也选的 debian, 然后因为只有 128M 内存, 上 64bit 没意义, 而且会更耗内存一点, 所以选了 32bit 的版本

debian 有几个比较坑爹的地方, 首先就是新建用户默认不建 home 目录, 非要在 useradd 的时候强加 -m 参数指定, 不然还要人肉新建 home 目录兵把 /etc/skel/ 下的几个隐藏文件拷过来做初始化

然后就是如果不是 root 用户, /sbin 和 /usr/sbin 默认是不在 PATH 里的, 需要手动将这些路径打开, 不然连 ifconfig 什么的都用不了. 修改 /etc/profile 里, 将 PATH 设成全用户一致 (此处参考: http://techpoet.blogspot.jp/2010/01/add-sbin-to-user-path-in-debian.html)

自己有一堆常用的配置库放在 github 上, 直接 git 取下来放到 home 目录, 把一堆 rc 结尾的文件前面加点让对应的程序能读到. 特别的是 vimrc, 最好还是放到 /etc/vim/vimrc.local 下, 不然 sudo 的时候碰上的还是没配过的 vim, 挺不爽的

系统自带应用内存优化

因为只有 128M 的内存, 要做很多勒紧腰带过日子的准备, 先就是卸载一堆自带的服务, 释放宝贵的内存, 此处参考了 http://www.yyphs.com/post/475.html, 不过我只去掉了会启动的组件, 即如下操作

# 系统升级
apt-get update && apt-get upgrade

# 去除多余软件
apt-get -y purge apache2-* bind9-* xinetd samba-* nscd-* portmap sendmail-* sasl2-bin

# 清理软件包
apt-get autoremove && apt-get clean

LEMP 环境安装

Web 应用从早两年的 LAMP 现在都在转 LEMP, 主要还是把 Apache 这个巨无霸换成了相对小巧又耐操的 nginx, 自己之前用 nginx 感觉也相当好, 这次也把系统默认的 Apache 干掉换这个

一开始参考的 http://www.howtoforge.com/installing-nginx-with-php5-and-mysql-support-on-debian-squeeze, 安装 mysql, nginx, php 都很正常, 但是这里面提到 debian 没有 php-fpm, 所以用 lighttpd, 不过我装 lighttpd 后内存爆掉, 随便搜了下优化方案都搞不定, 卸掉, 还是用习惯的 php-fpm 方式跑 fastcgi

http://www.webhostingtalk.com/showthread.php?t=1025286 这个提示装上 php5-fpm, 从装 nginx 开始就用不上了, 后面的优化也先不用管, 一会一起处理 (wordpress 似乎还依赖一个叫 php5-apc 的包, 装的时候一起带上)

内存优化

上面那一堆装好后如果不做优化, 坨坨的爆内存, 所以该关的功能要关, 该调的参要调. mysql 的一个优化关键是要关 innodb, 然后 nginx/php-fpm/mysql 都要做的事就是降低同时运行的实例数, 减少连接数, 同时严格控制各处内存大小. 具体怎么配的也忘了, 主要参考的是搜到的这两篇里关于参数的配置

http://blog.log4d.com/2011/11/vps-lnmp-setup-config/ (主要参考其参数配置)

http://keithscode.com/blog/23-running-mysql-on-a-small-128mb-vps.html (主要参考其参数配置)

最后的内存占用如下 (目前运行状态, 装了 wordpress)

$ free
             total       used       free     shared    buffers     cached
Mem:        262144      88972     173172          0          0          0
-/+ buffers/cache:      88972     173172
Swap:            0          0          0

安装迁移 wordpress

先在 mysql 里建对应的数据库, 这个随便都能搜到, 自己碰到个坑是 mysql 分配数据库权限时用已有用户无法登陆, 最后还是删掉用户在分配权限时再新建用户, 用 identify 来设置密码

mysql> create database wp;
mysql> grant all privileges on wp.* to wp_user@localhost identified by 'wp_pass';

装 wordpress, 一切正常, 用老的文件, 改名备份 wp-config.php 直接访问 wp-admin/install.php
用导出的文件再导入 (大于 2M 的话需要修改 php 的上传限制: 修改 /etc/php5/fpm/php.ini 文件修改 upload_max_filesize 项)

之前用的是多说的评论系统, 把插件重新启用, 并绑定原来注册过的站点就能将评论恢复, 一切搞定

奇怪的问题

上面写的好像很容易, 实际上对一个新手 OP 来说还是非常磕磕碰碰的, 最后在 OP 之外还有些奇怪的问题

先是多说, 绑定站点时临时性卡死, 然后再导数据时有延迟, 再后面就有重复的评论出现, 但是又不是所有的评论都被重复一遍, 研究了半天没弄明白, 自己手动删掉了重复的

然后删重复数据时发现有一条奇葩的回复显示在了另一篇文章下, 还是一条二级评论, 但是在后台看对应的又是正确的文章, 而且文章下的评论数是对的, 就是不显示, 自己折腾半天都没弄好, 无奈去联系多说的技术客服, 周末不在线, 留言后觉得不放心, 又去 dev.duoshuo.com/wordpress-plugin 报了一遍才安心

今天终于找上人, 帮着看了下, 先让我把评论模式从嵌套改成盖楼, 发现果然显示在正确的文章下了, 但是错误的引用了一条另一篇文章下的评论, 而且引用的那条评论还在此评论后好几个月才发出来, 顺手看了下 HTML 源码, 发现多说也是按 评论(post-id), 文章(thread-id), 引用(root-id) 来组织的数据 (这跟 BBS 上的 pid, gid, rid 一样一样啊), 然后这条出错的评论应该是两边哪里没同步好, 导致其 root-id 出错, 而 root-id 对应的评论在另一篇文章下, 所以嵌套模式时就显示到那边去了, 而正确的文章下因为找不到对应的父评论所以也没显示, 而盖楼模式下不判断父评论所以能显示, 但是存在错误引用关系, 最后让帮忙手动将出错评论的 root-id 置零, 总算搞定

第二件事是一个陈年老问题还在, 一年多前就写过一篇爆流量记, 里面提到有人抓 win7.iso, 但是当时找不到证据说是谁, 迁到新站后还在被抓, 期间 404/302/416 轮着报了一年多错居然还抓, 怒了去看看到底都哪来的请求, 意外发现有很多标识 QQDownload 的请求, 从 momodi 那联系上 QQ 旋风的人, 跟他们 blabla 说了一堆, 结果估计他们也从来没碰到过这样的事, 说要不你先自己屏蔽掉? 我哭笑不得说现在对我倒没啥影响了, 反正就算屏蔽也耗系统资源, 而且现在每次给个 416 也费不了我多少流量, 只是觉得很不爽而已. 不过后来自己去找了下迅雷和旋风离线下载的 IP 段, 这几个好像又都不在里面, 贴下原始日志, 大家看看有啥想法没:

$ awk '/QQDownload/{cnt[$1]++};END{for(ip in cnt){print ip, cnt[ip]}}' access.log
101.226.68.137 196
140.207.54.139 195
183.195.232.138 196
$ awk '/cn_windows_7/{cnt[$1]++};END{for(ip in cnt){print ip, cnt[ip]}}' access.log
122.141.67.50 329
123.185.52.73 54
14.114.226.18 150
14.114.226.194 14677
14.115.129.55 4040
180.117.68.185 361
59.33.63.137 1476

抽几条完整日志如下:

101.226.68.137 – – [21/Apr/2013:19:44:18 +0800] “HEAD / HTTP/1.1” 200 0 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; QQDownload 713; .NET CLR 2.0.50727; InfoPath.2)”
14.115.129.55 – – [21/Apr/2013:19:44:18 +0800] “GET /ftp/Win7_rtm_with_loader/cn_windows_7_professional_x86_dvd_x15-65790.iso HTTP/1.1” 416 615 “http://yewen.us/” “Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)”
14.115.129.55 – – [21/Apr/2013:19:44:22 +0800] “GET /ftp/Win7_rtm_with_loader/cn_windows_7_professional_x86_dvd_x15-65790.iso HTTP/1.1” 416 615 “http://yewen.us/” “Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)”
14.115.129.55 – – [21/Apr/2013:19:44:25 +0800] “GET /ftp/Win7_rtm_with_loader/cn_windows_7_professional_x86_dvd_x15-65790.iso HTTP/1.1” 416 615 “http://yewen.us/” “Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)”

爆流量记

缘起

过年回家那几天发现此博客垃圾评论暴涨, 从一周几条涨到一天一千多, 当时懒, 人肉删了就没管. 回北京后发现还是这样, 删是删不及了, 只能把 Akismet 打开, 拦的效果还不错, 再要求访客第一次发表评论的用户要过审核, 这下好了, 基本上能拦住, 偶尔一两条漏的人看一下也就砍掉.

这个空间买的就很便宜, 一个月 5G 流量对纯文本的 blog 来说完全够用. 在搞垃圾评论期间发现流量暴涨, 在一月还剩下没几天的时候收到邮件说流量达到 90%, 当时想了下估计是发垃圾评论的在抓站把流量搞的, 等我把垃圾评论处理了应该就没事, 看后台监控好像没怎么涨了就没继续关心. 第二天收到邮件说流量爆了, 而且登空间后台都登不上去. 没办法只能联系空间提供商 flyssh.net, 说我是被垃圾评论搞挂的, 让帮看看能不能处理, 那边很快回复说看我爆的还挺厉害, 但是因为我也是受害者, 免费给我加了 5G 流量, 但是垃圾评论这事他们搞不了, 祝我尽快搞定.

解决

我观察了下空间后台的流量监控, 发现不是实时更新, 而是一天一次. 另外由于服务器在美国, 上面的时区是 -5:00, 所以是每天下午一点结算, 我搞定了垃圾评论后每天流量还是非常夸张, 之前正常时一天不到 100M, 现在却一天 1.5G+. 想不清楚到底哪里有问题, 看了下后台有 Apache 的日志, 就抓下来分析了下, 这一看不要紧, 怎么 404 的次数这么多而且流量都这么大?

HTML 返回 次数 总字节 平均长度
200 4219 103,647,235.00 24,566.80
301 2597 1,750,723.00 674.13
500 4 13,882.00 3,470.50
302 62 49,992.00 806.32
403 4596 15,855,133.00 3,449.77
304 274 57,134.00 208.52
404 10555 1,488,782,649.00 141,050.00

从大到小挨个分析, 最大的是 404. 看错误绝大部分都是因为下 win7 未遂. 想起来 yewen.us 这个域名曾经在度娘内部提供过下载, 放的是度娘发的 X200/X201 可激活的 Win7 Pro, 估计有人用迅雷或旋风下载过, 结果被他们记住这个链接了. 但是我都返回 404 了居然还不停的请求, 真坑爹. 拦不了迅雷旋风就从自己这改变, 将那个 win7 的链接, 以及下载主入口都添加 301 跳转, 让去找正确的 ourfcr.info 下. 另一个 404 来源的大头是最近被搜索引擎抓站, 因为我没显式提供 robots.txt 也返回 404, 应对办法就是加了个空的 robots.txt 到根目录.

404 的另外一个问题是返回页怎么也都这么大? 本来应该跳转到 /404.shtml, 一个不到 1k 的文件, 实际却跳到了 /blog/404.php. 中间换过一次主题, 新主题的 404 页面包括了整个主题框架, 就因为这所以数据大? 在弄不明白为什么 404 不是跳到 /404.shtml 的情况下, 果断将 /blog/404.php 先改成了一个纯 html 的:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>404 Not Found</H1>
</BODY></HTML>

其次是 200 正常返回, 看了下 Agent, 不少还是垃圾评论发送者和搜索引擎的爬虫, 这没办法, 只能希望搜索引擎爬完后不再爬那些过期页面, 垃圾评论被 ban 掉后不再骚扰.

再一个大头 403, 看记录似乎是某些搜索引擎或垃圾评论发送者的爬虫逻辑写的有问题, 每访问我 blog 的一个页面都会再去访问一个受限的链接, 从而引起大量的 403 错误. 这个不知道怎么写 robots.txt, 就放那吧, 等他抓完了应该就好了.

上面的所有所有修改都完成后, 单天总流量下降到 77.0MB, 算下来是绝对不会超过每月 5000M 的限额了.

其他问题

搞定流量问题后, 还有剩下几个不紧急的问题:
1) 404 为啥是由 /blog/404.php 返回?
2) 开 Akismet 防垃圾评论是不是靠谱?
3) 垃圾评论和爆流量都是换主题后导致的, 中间有联系么?

对 404 那个检查实验了半天, 应该是在 WordPress 开启固定链接时, 在根目录的 .htaccess 里加的 rewrite 参数将不存在的访问默认的都导向 /blog/ 来处理, 所以空间后台的错误页面管理失效, 我那个改动是正确的, 丑点就丑点吧, 反正正常人类浏览遇到 404 点下后退好了, 发垃圾评论什么的我才不管呢.

Akismet 固然是有效的, 但是很多时候也担心是否有性能和流量的问题, 搜了下果然还有更 ws 的解决方案, 那就是中文验证. 之前发到我 blog 的垃圾评论都是英文的, 而考虑到我的 blog 应该不会有全文非中文的评论, 所以只要限制评论必须带中文就行了. 修改主题的 functions.php, 在最前面加上这么一段

function scp_comment_post( $incoming_comment ) {
    $pattern = '/[一-龥]/u';

    // 禁止全英文评论
    if(!preg_match($pattern, $incoming_comment['comment_content'])) {
        wp_die("You should type some Chinese word (like "你好") in your comment to pass the spam-check, thanks for your patience! 您的评论中必须包含汉字!");
    }
    return( $incoming_comment );
}
add_filter('preprocess_comment', 'scp_comment_post');

这下整个世界清静了, 连偶尔一两条 Akismet 放过去, 但因为访客第一次发言进入审核队列的垃圾评论都没有了. (上面那段代码很好理解, 就是把汉字在 utf-8 里的编码位置开头结尾过一遍, 看评论中是否有文字在其中, 不在就报错)

对于换主题导致的问题, 不知道垃圾评论是否有关系, 这个主题用的人挺多, 作者还有几个其他主题也在被很多人用, 应该不至于在主题中嵌代码通报垃圾评论发送者, 只能说是个巧合, 或者说垃圾评论发送者对这个主题有匹配模板, 能快速从搜索引擎那搜到且自动发垃圾评论. 爆流量则是有一定关系了, 一是主题允许换色, 导致多个 css 加载, 二是 404.php 等处理页面太大, 换色的问题想了下让大家忍受下我的审美观, 不准换就行了, 404 的问题前面解决过了.

附小广告
flyssh.net 提供的 ssh/vpn 都挺靠谱, 推荐下, 要折扣优惠码的可以私聊我. 他家虚拟主机如果最便宜那几档还有卖的话也非常划算, 可惜现在最便宜的也是 100RMB/年. 管理员都很 nice, 出问题时都很快很友好的帮助, 都是搞技术的, 沟通特别舒畅.

原校内日志迁移完毕

感慨: 本来我是一多么热爱生活的好少年啊, 结果活生生被憋成了愤青, 后来愤不动了就开始走技术大叔的路线, 偶尔装下人生导师

另外, 互联网上资源的生命周期实在是太短了, 迁移过程中想看看以前的一些转载, 结果原始链接点过去都失效了, 只有域名贩子的广告

原教育网 blog 基本迁移完毕

http://whusnoopy.blog.edu.cn 上的所有文章迁移了过来, 由于其导出功能和 RSS 都有莫名其妙的问题, 所以是人肉弄的, 而且没有导评论过来了. 累死了.

教育网 blog 是第一个开写的地方, 也是认真写了好多年的地方. 导数据的时候, 也一篇一篇看过去, 曾经也过的那么的有声有色, 有开心有难过, 有温馨有痛苦. 里面最多的几个话题, 一是 ACM 相关, 二是大学的记录 (包括后面找实习等), 三是有关感情的思考和故事, 还有一些 BBS 上零碎的转载 (包括世界杯等). 有一些自己都忘记了的事情, 再捡起来, 五味杂陈.

接下来会把百度空间的文章导过来, 这也是个导出功能和 RSS 有问题的地方, 恨, 还好文章没有教育网博客那么多了

简体中文的 Live Spaces 兼容性太烂了

无论是谁的, 只要用简体中文打开, 页面就全乱了, 一开始还以为是 IE8 的兼容性问题, 但是在繁体中文和英文下都是好好的, 太无语了. 每次都是提示 Spaces 没定义, 这个页面模板写的, 中国是哪里管这个? 上海的那个 WLM 还是北京的 STC? 就这样的兼容性, 怎么抢市场啊
 
ps. 为啥每次只要进 live.com 相关, IE8 都要崩一次先? 真的就只有我有这样的 RPWT?