d r i n @ m e l: Wordpress

无题之二

Fri, 15 Aug 2008 01:17:34 GMT

Original URL: http://www.drin.cn/untitled-no-2/

Current Interests:

a. Develop a ‘feed reader’ website aggregating the posts from chinese wordpress users/blogs, which would apply the similar concept/technic of archieye.com.

b. Develop a Xiaonei application named ’same birthday’.

New caching system

Thu, 20 Mar 2008 03:57:02 GMT

Original URL: http://www.drin.cn/new-caching-system-with-wp-super-cache-and-eaccelerator/

Have you ever noticed that Drin.cn now runs faster than before? Sure you have I bet. Please have a look at the brand new caching system assembled for the site. It includes these components:

WP Super Cache
eAccelerator
eAccelerator for Wordpress plugin (object cache)

Fast isn’t it? That’s so cool, hehe. Btw, this site is proudly hosted by Dreamhost Private Server and Private Mysql Server.

WP升级

Fri, 18 May 2007 02:30:22 GMT

Original URL: http://www.drin.cn/wordpress-upgraded-to-23-alpha/

WP 发布了新的2.2版本。本站一向“敢为风气先”，因此大着胆子更新到了Wordpress 2.3 Alpha。更新过程一路顺利，只花了五分钟，哈哈哈。我喜欢这种在Alpha版本阶段就能顺利无错更新的程序。

新的2.2+版本的WP内置了Widgets/Dynamic Sidebar的支持。我于是乎兴冲冲跑到这个菜单下面看了一眼，结果发现我的Tiny Theme不支持Widgets。原因很简单，因为它是个极少主义风格的一栏主题，哪会有 Sidebar 存在呀… Sigh。（只闻听Tiny Theme说: 我不是个完整的男人，哭~）。顺带，推荐一下同样坚持使用Tiny Theme的Leo君 - Leosh.cn。

P.S. 一个小实验，中文Wordpress博客RSS合烧(By 新版Google Reader)

附上这个OPML文件以供下载。其中包含我搜集的共22个中文Wordpress博客的链接信息。

和WP插件搏斗（二）

Mon, 12 Mar 2007 11:31:05 GMT

Original URL: http://www.drin.cn/fight-with-wordpress-plugins-issue-two/

我给自己总结了三条简单规律：

看到越来越多的WP插件，手越来越痒。每个都想装一下。
插件装得越多，出问题的几率越大。
寻找和解决问题的过程富有挑战性，一来二去就上瘾了。

这次我遇到的是一个常见问题 —— WP系统的速度变慢了。

我尝试着按照各种提速建议作了调整，可是速度没有大的改观，也只好将就。有一天，我突然发现自己在Wordpress.com 的博客跑得飞快。两相比较之下，我就再也受不了自己这个博客的蜗牛速度了。我的网站在Dreamhost 的空间上，shared hosting的性能与带宽自然无法和专用主机相比。不过，我还是觉得，速度慢到这种地步，应该有很大的改进空间。如果在页脚模板加上这句：

[copy][-]View Code PHP

<?php timer_stop(1); ?>

那么显示页面生成时间在3~6秒之间。就算打开了wp-cache，速度还是慢得令人抓狂。于是我开始了寻找速度提升之路的过程。

首先我很明确的是，目前的这一堆插件，我是一个都不愿意去掉的。

我花了很多功夫东敲西打。甚至连php.ini都又翻出来收拾了几遍（我用自己装的PHP 4.4.2）。后来，在打开phpMyadmin看数据表的时候，发现了一点端倪。

我发现wp_options这张表异常的大。我这里有两张数据表是上MB等级的，一个是wp_falbum_cache。这个好理解。因为里面存储的是FAlbum插件缓存下来的Flickr图片，而且只在专门的相簿页面才加载，不会拖累整体系统性能的。另外一个就是wp_options，也有四、五兆之大。这就相当诡异了。因为wp_posts不过才几百KB，每天都收不少垃圾留言的wp_comments也还没到1MB呢。而且，打开每个前台页面都会查询wp_options表。如果我们研究一下wp-includes/functions.php，可以发现其中的get_option()函数是这样运作的：

[copy][-]View Code PHP

$alloptions = wp_load_alloptions();

它调用了另一个叫做wp_load_alloptions()的函数，把wp_options表里的所有记录全部取出放在一个数组变量里面。而这个wp_load_alloptions()函数中的的关键内容就是：

[copy][-]View Code MYSQL

SELECT option_name, option_value FROM $wpdb->options WHERE autoload = 'yes'

然后再根据调用get_option()时候的参数来取得具体某个option_name的option_value。当然，对于$alloptions这个变量WP有相应的缓存机制，所以每个页面打开的时候，这个变量只要查询一次，就可以用来获取所有option_name的值。但是，这个表有几兆之大呀，这究竟会不会影响速度呢？

于是我在页脚模板里面加上这句：

[copy][-]View Code PHP

<?php  print_r($wpdb->queries); ?>

这样就可以详细察看所有SQL查询的耗时信息了。一看之下，大惊失色。就是之前列出的这句SQL花费了0.x秒甚至1.x秒的时间。作为参照来看，其他所有的SQL查询都是0.0x秒。差了一个数量级。所以，在每个页面都要反复查询这些尺寸很大的数据，很不经济呀。

既然问题明确了，我就开始一条一条地翻看wp_options里面究竟有些什么，竟然把数据表撑到几兆之大！

我总结了一下，大概有以下三种信息：

WP自己的设置信息
插件的设置信息
一些以rss_开头的纪录

主要问题集中在第二、第三这两项上。如果你想我一样每天不装上一两个插件就浑身不自在，而且频繁安装卸载插件的话，第二项就是一个大问题。因为卸载插件以后，在数据表里的设置信息仍然保留着！有的插件（比如WP-ECommerce），一下子就在wp_options表里面扔了几十条纪录。如果这样的插件来上四五个，林林总总的残留纪录就是个可观的数目了。

对于这个问题没有好的解决办法，只能一条一条删除了。不过，好在就算误删除问题也不大，把相关的插件重新禁用再激活一下应该就可以了。

第三项其实才是本文的重点内容。在我删除了这些rss_纪录之后，wp_options的大小只有60多KB！它们究竟是什么呢？其实就是缓存下来的RSS内容。大致包括了两类：

第一类，就是WP后台里控制面板首页的那些RSS。具体来说有三个，在wp-admin/index-extra.php里面一目了然，分别是

1. Incoming Links:

[copy][-]View Code PHP

$rss = @fetch_rss('http://feeds.technorati.com/cosmos/rss/?url='. trailingslashit(get_option('home')) .'&amp;partner=wordpress');

2. Dev News

[copy][-]View Code PHP

$rss = @fetch_rss('http://wordpress.org/development/feed/');

3. Planet News:

[copy][-]View Code PHP

$rss = @fetch_rss('http://planet.wordpress.org/feed/');

第二类，就是你的Blogroll/链接栏目里面网站的RSS（前提是你在添加链接的时候填写了相应的RSS地址）。为什么呢？因为如果打开菜单 > 选项 > 杂项页面，就会发现WP有个功能是跟踪书签更新时间。在有些模板里，凡是最近有更新的网站，这个书签是用斜体或者其他颜色凸出显示的。这个功能需要抓取RSS来判断更新时间。

所以，这些rss_纪录对于普通的前台页面来说，根本就是冗余无用的。不过，只是删除它们是没用的，因为WP定时更新这些数据的。如果只在数据库里面删除它们，那么过不了多久就又回来了。真是讨厌啊… 而且，毕竟这些数据还是有用的（比如在后台的控制面板页面）。因此，如果你像我一样决定要对付这些记录的话，恐怕就非得修改代码不可了（也就是Hacking了，所谓get your hands dirty罗，呵呵）。

我的解决方案是个笨办法，就是另外建立一张叫做wp_rss_data的数据表，把那些rss_开头的数据记录统统存放在这里。

表的结构可以通过在phpMyadmin里面复制wp_options得来，一模一样的就可以了。然后呢，修改wp-settings.php。在这句的后面

[copy][-]View Code PHP

$wpdb->usermeta = $wpdb->prefix . 'usermeta';

加上：

[copy][-]View Code PHP

$wpdb->rss_data = $wpdb->prefix . 'rss_data';

在这句的后面

[copy][-]View Code PHP

require (ABSPATH . WPINC . '/functions.php');

加上：

[copy][-]View Code PHP

require (ABSPATH . WPINC . '/functions-rss.php');

新加入一个文件叫做functions-rss.php，下载点此，要放在wp-includes目录下面。

最后，修改wp-includes/rss.php，把其中的以下变量进行替换：

$wpdb->options 替换为 $wpdb->rss_data
add_option 替换为 add_rss_data
update_option 替换为 update_rss_data
get_option 替换为 get_rss_data

完成了。这是一个涉及代码修改的办法，所以请做好备份。我不保证没有问题哦。总的概念就是，把rss.php中涉及wp_options表的操作都转移到刚才建立的wp_rss_data表。而相关的函数都在添加的functions-rss.php中提供了（其实是一模一样从xxx_options拷贝过来的）。我也想过在add_option，update_option，get_optoin函数中加入判断，来分别是一般的option_name还是rss_那样的，然后操作不同的数据表。不过后来觉得这样修改不利于升级，所以还是用了现在的办法。

现在我的wp_options表一般在60-100多KB之间，wp_rss_data表一般在4~5MB左右。WP系统的整体速度令我满意（因为就算打开了wp-cache插件来缓存页面，这个wp_options表还是每次都要查询的）。

最后指出一点，使用很广泛的Sitemap 插件会在wp_options表中存储生成sitemap的过程信息。这条纪录也略有点大，如果你是个完美主义者，那就记得点一下Clear Log按钮来清除。

就写到这里吧，下次再见吧~

和WP插件搏斗

Mon, 05 Feb 2007 10:32:55 GMT

Original URL: http://www.drin.cn/debug-wordpress-plugins/

网站托管在Dreamhost ，总体来说，还是很喜欢、很满意的。这次升级Wordpress到2.1Ella 之后，不晓得为什么，可视化编辑器总是无法载入。一气之下，通过Dreamhost提供的shell功能，以svn方式更新到了最新的开发版本。所以，如果打开这个介绍本站使用插件的页面，拖到页面最下方，就可看到我用的Wordpress版本是，2.2 Bleeding。Bleeding的意思，就是出血呀（进行时），就想象成全身飙血的样子就好了（笑~），倒是很形象底形容了开发版本千疮百孔的状况。不过话说回来，Wordpress一路走到现在，开发版本也稳定好用底很。就算个别小臭虫，自己也能解决的。

下面，就简单列下我最近作的一些修补：

首先就是那个可视化编辑器无法载入的情况。我碰到的问题，是所谓的“找不到元件（object）”。解释出来的意思就是，相关.js都没载入；因此这个TinyMCE编辑器，根本就是影踪全无。按照以往经验，我先把所有插件停用，然后用排除法一个一个试验。

说到停用所有插件，有一个简便的办法，就是把原来的/wp-content/plugins目录改名为/wp-content/plugins~，然后新建一个空plugins目录。这样子，一下子所有插件都停掉了。如果要重新激活一个插件，只需要把那个文件从plugins~目录移动到plugins目录就行了。当然，你有可能需要在后台的插件列表里面重新激活一下。

回过头来继续说这个TinyMCE编辑器的事。我花了点功夫把所有插件给试验了一遍，结果发现根本不是因为插件不兼容而引起的问题。真正的问题，出在tiny_mce_gzip.php这个文件上。它的作用，是把tiny_mce的javascript脚本通过gzip协议传输，降低传输时间，加快载入速度。我碰到无法载入的原因在于，php.ini中有错误的设定。因为我在自己的Dreamhost上面安装、编译了自己的PHP（v4.4.2, phpinfo() ），所以之前无意中鬼使神差地修改了php.ini里面有关output_handler 的部分。结果呢，php默认就是通过gzip输出内容，虽然我把Wordpress后台里面“阅读”菜单中的gzip选项关闭了，但是TinyMCE仍然坚持着使用gzip输出，于是，自然载入失败了。值得一提的是，在调试过程中，我还试着下载了最新版的TinyMCE 2.0.9 混进了Wordpress，期望能解决问题。结果发现，还是不行。网上有人指出说，让Wordpress避免载入这个tiny_mce_gzip.php，而是直接载入TinyMCE提供的一个静态.js文件可以解决问题。我也试验了，似乎只是部分解决了问题。因为Wordpress中的TinyMCE是经过特别调整的专用版本（也有人戏称是阉割版本），所以有的按钮会发生无法使用的问题。好在，最终我找到了主要问题所在，算是不用伤筋动骨就恢复正常了。

还有一个有趣的部分是，网上有文章提到说如何打开Wordpress内置的TinyMCE中隐藏的按钮。具体可以去Google搜索，修改很简单，修改以后可以打开一个叫做Show/Hide Advanced Toolbar 的按钮，点击一下就可以显示/隐藏额外的一行编辑器按钮，包括字体、大小、样式之类。要知道，完整版本的TinyMCE可是有着整整三行的按钮呢，呵呵。有兴趣不妨试试看。

第二个问题，是有关AJAX和Comment的。现在的网站，特别是博客，都注重AJAX化（AJAXify）整个系统。和用户体验特别有关的就是评论（或者翻译成留言、回复）部分。之前我一直使用Inline AJAX Comment 这款插件。但最近发现，总是有些不明原因的错误出现，更主要的问题是，这不利于提升站点的粘性，因为大家在首页就看到了所有评论，看完就走了。相比较之下，到单篇文章页面阅读评论，虽然增加了一次点击，但是提供了更多的吸引访客的机会（比如在单篇文章的页面加入最新发表和相关文章两个列表等等）。同时，点击进入以后，撰写留言的表单也出现了，对增加访客留言率或许会有帮助。权衡再三，我还是去掉了这个插件。

取而代之的，并非那个很有名的台湾编程美女“懒懒喵”的作品AJAX Comments Reply ，而是AJAX Comment 。原因很简单，前者属于Wordpress Hack，修改了源代码，过程比较麻烦是小事，不利于系统的升级和完整性才是真正让我有所顾虑的。AJAX Comment我觉得比较优秀，并且支持一款叫做AuthImage的插件，能够提供从Captcha图片验证、无刷新评论提交、错误信息反馈、新留言即时显示的统一解决方案。具体来讲，安装过程也不顺利。使用中总是出现javascript错误（看来这是AJAX特性的一个致命缺陷，因为javascript的错误调试实在不便），我找来找去找不到原因。后来终于发现，我使用的这款Theme叫做Tiny（另有个修改版本叫作TinyMod），也作了一些修改，但是一直没发现，作者把评论表单的提交按钮的名字命名成了submitComment，这不是一个规范的名称。对于AJAX Comment插件来说，提交按钮的名字必须是submit才能正常运作。做了修改以后，就一切正常了。

此外，我特别要提一下AuthImage 这款插件的插件。它提供的设置选项丰富，调试起来相当有趣。具体显示可以看本页面最下方的Demo。它的优点在于，可以动态刷新验证图片；缺点在于，默认设置下的验证图片是在很丑，甚至很难辨认（真人很难辨认… orz）。我选择的是背景图片模式，去掉了大部分花里胡哨的背景图片，只留下来了两张，而且用Photoshop去掉了颜色变成灰度，并且调整了亮度对比度。虽然，相对来说防机器识别能力下降了，但可读性好多了。想来我这样的小站犯不着有人用机器识别来对付我吧？我还调整了字体变形的算法。因为单靠设置还不能达到要求，所以对于源代码略为有些小的改动。

第三个修补，是使用广泛的Admin Drop Down Menu 插件。一切都好，就是不晓得为什么，不论我使用谁出品的中文包（就是zh-CN.mo文件），后台的撰写和管理的中文翻译就是不出现。一直是Write和Manage。这不是什么影响使用的问题，但是不彻底的菜单中文化总让人觉得看着别扭。忍了很久以后终于发现了原因。在插件的adminmenus.php 文件中的aws_correct_core_menus() 函数里，作者加了一些关于后台界面措辞的修订。

// make some corrections
$menu[5][0] = “Write”;
$menu[5][1] = “edit_posts”;
$menu[5][2] = “post-new.php”;
$menu[10][0] = “Manage”;
$menu[10][1] = “edit_posts”;
$menu[10][2] = “edit.php”;

因此，中文语言文件找不到可以匹配的英文单词进行翻译，后台菜单就显示出来Write和Manage了。修改很简单，只要把这两行给注释掉就可以了。看一下你的后台，是不是有“撰写”和“管理”的字样出现了？

最后说一个插件问题，是有关Google Sitemap 插件的。我很喜欢这个自动生成.xml格式站点地图文件的插件，效果可参见本页面最下方的xml sitemap 图片。只是有个问题，它有时候会无法显示图片。因为这个图片是通过插件动态生成的（作者把Gif图片用二进制格式包括在插件的.php文件里了），所以只需要直接把这个图片的地址拿来单独放在浏览器里面一看，就看到出错信息了。

原来，在发送图片的Header之前，已经有插件提前给浏览器送出了Header，就是这个叫作Display WP FeedReader 的插件（WordPress美女懒懒喵的又一个插件作品~）。归根结底，问题出在我为了中文化这个插件，把插件里面的几个英文翻译成了中文；为了避免乱码，整个文件使用了UTF8的格式来存储。而UTF8格式的插件.php文件在被系统加载的时候，似乎就已经送出了Header了。解决办法也简单，把中文改回英文，然后把文件存为普通的非UTF8的格式就好了。或许这个不是最好的解决办法。不过先凑活着用吧，等我有了更好的解决办法再说。

呼，说了这么多。目前我的Wordpress运作健康。可我总有不停尝试安装新插件的坏习惯。不过，在不停的Debug修补过程中，对于Wordpress的理解也加深了。或许有空的时候会写一个自己的插件吧？呵呵，倒是有一些想法了。

本站Wordpress升至v2.1

Wed, 24 Jan 2007 13:25:34 GMT

Original URL: http://www.drin.cn/site-upgraded-to-wordpress-21/

如题。2.1算是Wordpress 的一个主要版本升级，我就抽空跟着把本站的博客系统更新啦。新东西用起来的确舒服，虽然陆续出了各样的小问题… 主要是模版和部分插件不兼容新版本引起的。比如说，新版本的友情链接的分类不再单独出现，而是整合进了文章的分类表里。所以$wpdb->linkcategories这个咚咚就要报错地。改成$wpdb->categories就好了。另外无意中发现codex.wordpress.org 不支持wp_get_links的文档了，因为根本就不存在这个页面了？真的假的？我还要确认一下。看来有些被放弃的tag真的被毫不留情地丢掉了。

顺带想到，其实提高PHP编程水平有两大途径，一个是“和谐社会”（就是多装开源程序除错，让程序运行“和谐”起来），另一个就是“与时俱进”（就是多多更新程序到最新开发版本，例如nightbuild、snapshot这类的）。这两个提高编程水平的办法都是很累人的，因为开源程序带着错误发布是太常有的事情了；至于更新版本就更加头痛了——如果你没有定制（customisation）还好，如果你喜欢在源代码级别修修补补（有时候也是逼不得已，因为要除错嘛），如果一更新，之前的努力就前功尽弃，要重新来过了！不过啦，也就是这么折腾，才能飞速学习。这就是我自己很浅薄的几点心得了。

最近在自己公司做了两个网站，算上去年帮Serena做的一个，和帮Cindy的公司做得一个，还有教会青年团契的网站。勉强凑足五个放出地址来，大家随便看看吧。第三、第四两个都是短时间内做出的小东西，最后一个是WP架的站，入不了各位的法眼，包涵下罗。

修补WP插件FAlbum

Fri, 18 Aug 2006 16:35:55 GMT

Original URL: http://www.drin.cn/fixing-error-97-of-falbum/

使用Wordpress插件FAlbum的用户很多。但是最近不少朋友遭遇一个编号97的错误。一个典型的出错信息如下:

FAlbum has encounted an error while processing your request.

Flickr returned an invalid status code:
97 - Missing signature

Backtrace:
FAlbum.class.php:1524 - /home/*****/public_html/*****/wp-content/plugins/falbum/FAlbum.class.php
falbum_wp->_error()
FAlbum.class.php:1423 - /home/*****/public_html/*****/wp-content/plugins/falbum/FAlbum.class.php
falbum_wp->_parse_xpath()
FAlbum.class.php:176 - /home/*****/public_html/*****/wp-content/plugins/falbum/FAlbum.class.php
falbum_wp->_call_flickr()
FAlbum.class.php:99 - /home/*****/public_html/*****/wp-content/plugins/falbum/FAlbum.class.php
falbum_wp->show_albums()
falbum.php:29 - /home/*****/public_html/*****/wp-content/themes/k2/falbum.php
falbum_wp->show_photos()
album.php:12 - /home/*****/public_html/*****/wp-content/plugins/falbum/wp/album.php
include_once()

在Flickr官方网站给出的解释链接。那个叫做Eric的Flickr工作人员解释说:

hub, If you are seeing 97 errors, it is likely because you passed a token but not a signature in your API call. If you pass a token, you must pass a signature also. (So, yes, your authentication is outdated in the sense that we fixed a bug that allowed for unsigned authed calls to the API to be honored, so you must update your code to follow the spec.)

大意就是，如果你遇到97错误，很可能是因为在你通过Flickr提供的开发API呼叫时，传递了一串暗号(Signature)，但没有包括一个签名(Token)。也就是说，签名和暗号必须同时被传递过去。然后Eric接着解释说，Flickr刚刚修复了一个小错误，之前的认证过程允许未签名的请求认证呼叫。而现在这种方式行不通了，所以必须通过修改代码来跟进。

所以问题就很明白了。FAlbum的代码由于Flickr对于这个问题的修补而不能正常工作了。

我去FAlbum的官方论坛察看，有一个专门的帖子反映了不少用户都遭遇了相似的问题（btw，帖子里面的drin就是我）。

我想，若是等到作者Eli来解决问题，不知道要多久了。而每天看着自己博客的照片栏目一直出错是在心理不舒服。所以就打算自己动手。研究一下，就发现其实不难解决。下面是我小补丁（需要修改代码，请做好备份工作）。

首先，打开在插件目录中falbum子目录下的FAlbum.class.php文件，寻找“function _call_flickr”，大概在第1403行左右。

寻找以下代码:

if (!empty ($this->secret)) {
$api_sig = md5(FALBUM_SECRET.$auth_sig);
}

替换为:

$secret = FALBUM_SECRET;
if (!empty ($secret) || $this->_show_private() == ‘true’ || $post == true) {
$api_sig = md5(FALBUM_SECRET.$auth_sig);
}

$args = array_merge($args, array (’api_sig’ => $api_sig));
ksort($args);

然后保存，上传覆盖原来的文件。再打开你的FAlbum页面看看？一切都正常了吧。

呵呵，祝使用愉快。

插件修改

Sun, 02 Apr 2006 10:51:42 GMT

Original URL: http://www.drin.cn/modification-of-display-wp-feedreader/

只修改了一样事情——可以看到feed的内容了。代码照搬自WP FeedReader插件。

Plugin Name: Display WP FeedReader
Plugin URI: blog.nahoya.com/archives/2005_10/50
Description: 在前台顯示 FeedReader 網誌聯播項目
Author: Beata
Modified By: Drin (April 1, 2006)
Author URI: blog.nahoya.com/

source: display-wp-feedreader.phps
demo: aggregator of feeds at this site