Empty Google Friend Connect Bar in WordPress

[English]
It confused me a lot. Now I found the reason, in short, there is some conflict between Google Friend Connect (GFC) and prototype.js (some plugins of WP used this JS lib).
Workaround - add the code below just before the generated gadget code.

<script>
window.JSON = {
 parse: function(st){
   return st.evalJSON();
 },
 stringify: function(obj){
   return Object.toJSON(obj);
 }
};
</script>

For more detail, see this.

[Chinese]
发现Google Friend Connect (GFC) 小工具在Wordpress显示空白的解决办法,希望对别人有用。
GFC的JS代码和prototype.js相冲突(很多WP插件使用这个JS库),解决办法:在生成的gadget代码前加入以下代码即可。

<script>
window.JSON = {
 parse: function(st){
   return st.evalJSON();
 },
 stringify: function(obj){
   return Object.toJSON(obj);
 }
};
</script>

详情:看这里

blog搬家

蓄谋已久的blog搬家行动胜利完成!
请大家使用新域名[http://nonleaf.net],原来域名目前仍旧可以访问,会自动转向新域名。

本以为很轻松的搬家工作,还是遇到了不少困难,大概清楚了从域名解析到Apache mod_rewrite。

问题记录如下,以飨后人:

1.将备份的数据库用文本编辑器打开,将原来的URL批量替换为新的,然后导入新数据库。随后发现wordpress的侧边拦没法载入,报错总是在wp-includes/widgets.php里面的一些语句。Google未果,研究发现问题出在数据库上,有些表(如wp_options)的文本数据有类似这样的格式:s:6:"string",6表明后面的string的长度,我没仔细看代码,估计这么做是为了快速定位,但是如果string里面含有URL,都被我批量替换掉了,替换前后长度必然不相等,所以造成wp读出奇怪的数据down掉。

解决办法:
自己写个程序改一下备份的数据库文件,将s后面的数字数出来替换。或者对原来数据库只改关键地方--wp_options表里option_name='siteurl'的那一行,其余的通过在旧服务器上写.htaccess重定向解决,前提是原来服务器apache有mod_rewrite。
编辑旧服务器的wordpress目录下的.htaccess文件——
Options +FollowSymLinks
RewriteEngine on
RewriteRule ^(.*)$ http://nonleaf.net/wordpress/$1 [L,R=301]

2.cPanel暂时不支持域名绑定在深层目录下,但是这个对于一个虚拟主机多个人共享是需要的。可以通过mod_rewrite达到目的(写.htaccess)。

解决办法:
例如要从test.nonleaf.net对应到到主机的根目录(/home/user/public_html/)下的一个深层目录/home/user/public_html/nonleaf/test/。
首先在域名商那里将test添加如A记录,IP指向主机(当然你也可以添加CNAME),同时将这个域名加入到cPanel的域名中,让主机能接受来自这个域名的请求。然后在public_html下面创建.htaccess文件——
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/nonleaf/test/.*$ [NC] #防止反复rewrite造成死循环
RewriteCond %{HTTP_HOST} ^test.nonleaf.net$ [NC] #识别出test.nonleaf.net域名
RewriteRule ^(.*)$ nonleaf/test/$1 [L,NC] #rewrite到子目录

当然,如果在test目录下的.htaccess中还有rewrite,需要考虑加上RewriteBase。总之mod_rewrite的功能很好很强大,可是实现机制有些复杂,要多看manual才行。

WordPress 2.0.4 Upgraded

还是升级到了2.0.4,据说修复了50多个bug。升级后一切正常,但是我发现的那个bug让就没有修复,就是友情链接的显示问题(设定的前缀、后缀无法显示)。所以,我还是自己改代码修正了一下,其实是一个很简单的fix。

我本来打算去wordpress.org上面提交个bug report,后来看到了他们搞的一个WordPress_Bug_Hunts,遂进到了一个名为WordPress Bug Database的东东里面。

omg,这帮外国佬还真是仔细,一个整套的bug/新品的提交、解决、反馈、测试系统,谁提交的,现在谁在解决,显示的井井有条,而且谁都可以参与。想到如果中国人也有这份耐心和共享精神,不怕搞不出好的东东来啊。可是我们有这样的机制么?不是技术不行,而是根本没这个概念。记得我以前用的那个exblog就是国产的,结果1.5版难产到什么程度都无法想象,一年内无数次延期,却总是说“快了快了”,到最后编代码的核心人员都走掉了。所以我才愤然抛弃国产,转投WP,不是我不爱国啊~

扯远了,我在Bug Database里面搜索那个bug,竟然有人在9个月前就提交了,而且解决方案也在6个月前就搞定了(和我的修正方法一模一样,嘿嘿)。可我就搞不懂在正式版中为什么没有修正。最后WP的老大在这条bug下面有句话:
02/12/06 08:31:46: Modified by ryan
get_links_list() purposefully hard codes a list. If we honored before and after we would probably break most templates that use get_links_list().

我还是没太看懂,哪位英语牛人帮我翻译一下?get_links_list()就是一个函数名称。

blog故障日志

最近mysql都不是很稳定,所以blog没法访问我也没在意。

回来后,发现mysql可以读取,但php不能get参数。查了点资料,用phpspy察看了一下环境变量,果然php.ini的register_globals变成off了。
sigh,也怪写php时犯懒没用_GET[]...教训啊,现在受php.ini的气。我又懒得和弄服务器的人废话(又和我扯安全性...),难道我就要全改成_GET[]???

还好,查到这样一句,可以把_GET[]之类的自动导成全局,放到config里面一include就完事了。哈哈,看来像我这样的懒人还是有不少...
import_request_variables("GPC");
如我所料,一切恢复正常。

可是blog的问题还是没有解决,症状是白页,就像网页还没有下载完(进度条停在中间),似乎服务器端的php在死循环。没办法,从index.php开始,注掉代码逐渐恢复的方法来查,这可是wordpress啊,天知道我要查到哪里才是头?还好,才include了几个php就出现了问题。最后锁定到wp-db.php的function query($query)。晕死,所有访问数据库可都是这个函数,原来好好的也没人动怎么会出事?

罪魁是这句:@mysql_fetch_field($this->result);函数死在这里怎么也不返回了。还好,整个wordpress也都没用到察看数据表的field名(天知道他写这句干什么,可能为以后升级准备吧)。果然,注掉获取field信息的这一段循环,blog就活了。

后来,索性趁热打铁把wordpress升级到了2.0.3,换了大名鼎鼎的k2,一个k2_mod的清新theme,自己做了个logo,然后装了个据说好用的Sidebar Widgets Plugin。接下来就是烦人的调整,改CSS,调sidebar(插件根本不好用,还得自己写代码,除了那个动态的拖曳比较酷)……

弄了一天才算基本搞定。同时,还发现2.0.3的一个bug,友情链接的分类管理中的“格式”不管用!看了links.php才发现根本没写在代码里,看来2.0.3出来还真是匆忙(记得2.0.1里面没这个功能),改两句话,一切OK。

仔细想想,估计是服务器进行了升级(包括php和mysql),造成运行不稳定(来回调参数:()。mysql_fetch_field可能是管理员限制了数据库的权限吧,可是也没有死循环不返回的道理啊,看来要追究php4-mysql模块的责任:)

总之,现在一切问题都基本解决了,还真是麻烦。以后要注意经常备份数据库!要不然,服务器挂了哭都来不及...