CB's Blog

11 三月, 2006

UT使用的是pLog系统(年初改名了，现在叫LifeType），它的summary页面右栏有一个“最活跃的博客”的排行。现在utblog排行第一的是CB's Blog，紧随其后的一生像戲。一生像戲一直想超越我成为排行老大，但是总不能如愿。我今天特地研究了一下排行的规则，简介如下：

排行依据的Rank=SUM(文章点击数/文章发表的天数)。可见这个Rank和以下2个因数有关：

1. 文章的平均日点击率
2. 总的文章数目

所以，要想排名靠前，不光要积极发言，还要想办法增加文章的点击率。

特地摘录排行前15位的Rank数据：

排行	博客	文章总数	Rank value
1	CB's Blog	197	314.02
2	一生像戲	171	115.80
3	echo	97	88.92
4	吾家有女	127	72.82
5	无产阶级	59	41.57
6	Hasta la vista, baby!	27	30.40
7	UT Blogger	14	22.14
8	事了拂衣去，深藏身与名	13	19.12
9	Java newbie	15	13.05
10	abo的笔记本	7	10.58
11	自由攀登者	7	5.19
12	飞鸟的天空	10	4.64
13	一同的历程	4	2.32
14	sisi	4	1.72
15	无趣	2	1.55

20 七月, 2005

对ADODB不熟悉，这里只陈述现象。

用ADODB4.53或者4.54版本时，无论MySQL的版本如何，数据使用的编码如何，应用程序通过ADODB存取数据都是正常的。

当升级ADODB4.62后，如果MySQL的版本小于4.1，那么一切正常，如果MySQL的版本是4.1以后，而数据库的编码又不是latin1，譬如说实际编码是UTF8，那么，存取数据都会发生错误。参考：[1]

Plog0.32使用的ADODB版本是4.53，而1.0以上使用的ADODB4.62，但是在plog1.0.1正式发布版本中，忘记了ADODB的支持UTF8的PATCH。

如果你后台使用的是MySQL4.1或者以上版本，内码是UTF8，而你又急急地升级了plog到1.0.1，那么很不幸，页面出现乱码不说，多次操作后，这些乱码还将被储存到数据库中，破坏了你原来正常的数据。所以，请尽快补上这个补丁！

我升级本地测试PLOG的时候，就碰到这种情况，当时费了很多劲，还是没搞懂为什么。在personal brain里的记录如下：

06:53 PM, July 09, 2005
升级 plog from 1.0 to 1.0.1过程中，本地mysql库中中文被改，似乎因某种原因，所有的内容被转换成iso8859-1代码后重新写回数据库，未能重现

12 七月, 2005

utblog的方向？呵呵，搞的主题太沉重了。

原先只是想给自己弄一个blog，后来想为什么不开放给周围的朋友呢？再想，闲着也是闲着，如果网上有朋友喜欢，到这里申请一个稳定，快速，干净，功能丰富的blog空间，岂不皆大欢喜？所以utblog就成了现在这个样子。

曾经在每个人的blog里添加了整个utblog网站的导航菜单，后来撤了，因为考虑到那样做就好比粗鲁地侵入别人的领地。

google的adsense广告，也只在summary page页和CB's Blog里投放，不过现在也在考虑是否撤掉，因为google的广告服务器不堪重负，直接影响我这里打开页面的速度。

喜欢干净简洁，属于自己并且可以最大程度控制（需要一定的编程基础）的博客，并且也为有同样需求的朋友提供一块空间，仅此而已^^

补充一点，为什么选择plog。

1. php, mysql is free
2. plog is free
3. 这三个都是Open Source Project，都正在蓬勃发展ing...
4. plog的结构很好，MVC框架实现的不错，plugin机制也很吸引人
5. 很自由。你可以上传自己的模板，任意修改你个人的界面。

ping to: http://www.utblog.com/plog/25/article/477

说说我个人的方向，在rss在线订阅和自助旅游wiki以及personal CMS上，近期会有所动作，敬请期待^^。如果哪位朋友也感兴趣，可以和我联系（回复本文说明即可）

11 七月, 2005

plog有一个特性，就是在发文后，能够向你注册的XML-RPC网站发送PING通告。而这些对外公开支持XML-RPC（XML-RPC2) PING的网站，在接收到你的PING后，会更新他们的最新发文列表并公布出来。也就是告诉他们“嘿，我写了一篇新文章“。plog 1.0版本有bug，会错误地清空保存在数据库中的XML-RPC服务器列表信息。在1.0.1版本中，这个bug已经被fix。

现在utblog登记了以下的ping servers:

http://rpc.technorati.com/rpc/ping
http://rpc.weblogs.com/RPC2
http://ping.blo.gs/
http://ping.feedburner.com/
http://ping.syndic8.com/xmlrpc.php
http://rpc.blogrolling.com/pinger/
http://www.weblogues.com/RPC/
http://bblog.com/ping.php

更多列表请参考此处：

http://elliottback.com/wp/archives/2004/11/21/a-list-of-rpc-and-rpc2-to-ping/

4 七月, 2005

在UTBlog写文章，最后提交的关头，有时候会出现“认证错误”信息，提示再次登陆，再不可能“退回”到刚才编辑的页面，结果是刚才的心血全部白费，痛哉！

究其原因，是因为php session有一个GC功能，就是Garbage Collector。这个GC启动的时候，会清除那些已经“超时”的session。它的工作原理是这样的（以utblog.com为例）：

1. 用户访问并登陆网站http://www.utblog.com，这时候后台会调用session_start来尝试生成一个会话（如果已经有会话，则相当于一次有效会话请求）
2. 对于这样的每一次有效会话请求（Request），apache的php模块会根据session相关的全局变量gc_probability/gc_divisor =>计算出启动GC的概率，并由此概率来决定在这次请求中是否应该启动GC。举例来说，session.gc_probability的缺省值为1，session.gc_divisor的缺省值为100，则启动“垃圾回收”器的概率是1%，这就意味着在每100次请求中，会有可能清理一次过期会话
3. 如果GC启动，则GC会扫描当前会话所在路径（session.save_path）下的所有会话文件，并根据另外一个全局变量session.gc_maxlifetime的多少来判断哪些session已经过期（“当前时间”与“会话文件的atime或者mtime”之间的差大于gc_maxlifetime：过期），并删除这些过期的session
4. 如果你在一个session启动后，长时间没有任何交互操作（譬如，不停地码字，没有提交或者保存为草稿），那么你的保存在后台的会话文件将得不到机会被修改或者访问，在gc_maxlifetime（缺省值1440秒＝24分钟）时间后，它有可能因失效而被清理，这以后你再提交，就会因为会话失效而报错

由此可见，gc_maxlifetime设置为24分钟，对于写某些文章来说还不够。这是一个原因，另外，session.save_path的缺省路径在linux上是/tmp，很少有程序会修改这个设置。如果这台服务器上有多个虚拟主机，那么，/tmp目录下会存放许多不同session_name的会话文件。糟糕的是，php的GC不区分会话归属，它会根据它取得的gc_maxlifetime来清理这个目录下的所有过期session文件。

据以上分析，解决方案是：UTBLOG在.htaccess文件内添加了一条语句，将session.gc_maxlifetime的local value扩大为14400（4小时），同时在后台将session.save_path设置为/tmp/utblog，这样，utblog的会话文件就不受其他网站干扰了，而4小时的失效时间，我想，无论如何应该够用了。

测试下来，一切如我所愿。

另，如果直接改动/etc/php.ini当然也可以。如果没有权限改动php.ini，也没有权限改动apache的conf文件，.htaccess被禁止，那么直接修改plog的sessionmanager.class.php文件，在session_start行前添加ini_alter("session.gc_maxlifetime", 14400)亦可。plog结构良好，只有这一处调用session_start，所以也只有这一处需要修改。我在本地做过测试，可以工作。

ref: http://terra.di.fct.unl.pt/docs/php/ref.session.php.htm

http://www.experts-exchange.com/Web/Web_Languages/PHP/Q_20890175.html

10 四月, 2005

我的blog垃圾评论和垃圾引用通告超多，几乎每篇文章都中过招，而且不止一招。今天看到几个大的搜索引擎(google, MSN Search, Yahoo)和网站(Blogger, Typepad, MovableType, Livejournal, WordPress)为了对付这些通过在大量垃圾评论和通告中引用自己网站，从而提升PageRank（搜索引擎术语，反映一个网站的广泛程度）点数的卑劣行径，开始使用一个新的hyperlink attribute: nofollow. 制定是nofollow的超连接，搜索引擎会忽略它对这个链接指向的网站的Pagerank的贡献。注意，只是忽略，并不惩罚，因为仍旧无法判断来源是否是spam。

Google建议，只要是访问用户（不是weblog作者）留下的链接，一律增加这个新tag，使得这些spammer们的阴谋破产。这些链接包括文章评论内容里的链接，指向作者主页的链接，引用通告中的链接等。

行动得不到结果，垃圾评论家们自然积极性大减，这样一来，发送spam评论和通告的人自然越来越少。当然，效果如何，还需实践证明。如果有那么一个损人不利己，白开心，也够头痛的了。不过，发的人少了，我们就可以用其他方法，譬如关键字过滤等技术屏蔽它们了。

这项技术对blog用户来说是透明的，对他们来说，链接还是链接，只是提供blog的系统在处理这些超连接的时候，额外增加了一个新的属性(Attribute)而已。

下面介绍nofollow的格式：

旧的格式：this is spam comment

变为新的：

rel="nofollow">this is spam comment

我准备近日修改UTBlog程序，加入这一功能。苦点累点没什么，绝不能让那些垃圾小人得意。

reference:

http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

http://www.ysearchblog.com/archives/000069.html

http://hompy.etang.com/Document/Doc_doc_list_one.php?USERID=1777&page=14

4 四月, 2005

4/1日,plogworld终于发布大家期盼以久的plog 1.0 release version. 我们UTBlog使用的系统是plog 0.3.2,跟着这阵春风,我也赶紧升级.

管理后台界面有了大改变,大家可能需要花一段时间熟悉.

我又新增了许多模板,大家可以自由选择(控制面板->控制中心->博客设置,选择你喜欢的模板)

更多功能和修改,将会逐次推出,敬请尝试

更多信息,参见

http://blog.markplace.net/index.php?op=ViewArticle&articleId=218&blogId=1

http://www.plogworld.net/blog.php/plog_development_journal/2005/03/31/plog_10_released

12 三月, 2005

近几天，垃圾引用通告成灾，几乎所有的文章都或多或少地中了招，而且每发一片文章，立刻就会有一条新的垃圾引用通告，查看这些Spam TrackBack pings，都有一个共性，或者Title包含"poker"或"texas"，或者它的链接包含这两个单词，和前些天垃圾评论非常相似。一定是某个自动程序在疯狂无聊地发送这些通告和评论。

临时没有什么好的解决办法，又不想关闭整个网站的“允许接收引用通告”的功能，所以针对垃圾引用通告的特征，在trackback.php内增加了简单的过滤代码：
（before addTrackback operation)
    $blockpattern = "poker|texas";
    if(eregi($blockpattern, $params->getValue("url")) || eregi($blockpattern, $params->getValue("blog_name")) ||
        eregi($blockpattern, $params->getValue("title")) || eregi($blockpattern, $params->getValue("excerpt"))) {
        $result = errorResponse( "Spam trackback ping probably, blocked." );
        print($result);
        TrackbackLogger::log( "Sending error response: $result" );
        TrackbackLogger::log( "** End" );
        die;
    }
测试了一下，能正常工作。

只要这个垃圾自动程序不是特别针对utblog的，那么应该能够清静一阵子。有时间的话，一定要好好处理这部分程序，特别是让plog0.32中的内容过滤功能成功运行起来。

4 三月, 2005

echo几次反映，她的文章在首页上的Latest Posts里显示总是为“...”。今天查看了一下代码，发现原来是trauncate这个modifier在处理中文时有个小bug。

in template/summary/recent.template, 相应的语句是{$post->getText()|strip_tags|truncate:200:"..."}
意思是说去除文本中的html标记，截取前面的200个字符，如果长度大于200，后面的文本以"..."代替

truncate是Smarty的一个Modifier，源码在class/template/smarty/plugins/modifier.truncate.php。这个修饰过程处理英文文本工作正常，但是在处理中文文本时，会有问题。
问题出在这里：
...
        if (!$break_words)
           $string = preg_replace('/s+?(S+)?$/', '', substr($string, 0, $length+1));
...
break_words表示是否允许一个单词被截断，缺省值是false，即不允许。英文中有单词这个概念，中文里则没有。S匹配的是所有除了空白、回车、换行、制表等字符以外的字符，而中文字符在UTF-8中是以3个高位为1的字节表示的，和S匹配相符，所以会发生所有的文本被替换为空的现象。

解决方法：
为了让这个修饰过程既能处理英文也能处理中文，并且不影响现在的应用，修改的范围尽可能的小，这里用w替换程序中的S，只匹配[a-zA-Z_]中的字符。这样，既满足不允许单词被中间截断的要求，又能正确处理中文。

12 二月, 2005

松松、Echo和骨头多次提到这个问题，我一直怀疑是IE的问题，但是不知道具体原因。今天我终于也碰到了这个现象，花了点时间，发现果然是IE解析utf-8编码的中文页面发生错误。

• 问题：有时候，我们使用IE打开某人的Blog或者查看某篇文章时，整个窗口一片空白，无论如何刷新都是如此
• 分析：查看源代码，发现这个Page的所有源码都已经成功下载；查看菜单中的“编码”选项，发现IE选择的是缺省解码，而不是UTBlog页面制定的UTF-8。手工选择UTF-8，页面显示正常
• 原因：当HTML页面内，TITLE中含有中文，且META Charset的位置在TITLE之后时，IE（我碰到这个问题时，使用的IE版本是IE6）解析存在BUG。
• 解决：修改模板，将置于HEAD修饰块的第一行，保证这个META之前没有中文字符

注：我是用的是blueish模板，修改的页面header.template。

      IE出错，但是firefox可以正确处理

9 二月, 2005

其实早就开通了，但是一直没编辑过，今儿整了一下。顺便测了一下两边的“引用通告”。

see http://spaces.msn.com/members/leonsun

结果：

MSN Spaces -> UTBlog 发送引用通告，MSN侧不报错，但是UT这端未成功。两边都是用的UTF8编码。具体原因不明，猜测可能是MSN不支持向其它blog空间发送引用通告。

下面测试UTBlog -> MSN Spaces

本文向http://spaces.msn.com/members/leonsun/Blog/cns!1p7S-ZiA-Y2zXoFaYAcyOuXw!171.entry 发送引用通告，报告成功，但是MSN那端没有显示。看来MSN虽然是blog，却似乎只允许在内部通讯。若果真如此，则微软未免气量太小，真没出息

当然，这只是猜测。容我在google上查一把。

未果。

看来要等我看了Trackback的设计文档后，手工测试了

2005/04/04测试

http://spaces.msn.com/members/leonsun/blog/cns!1p7S-ZiA-Y2zXoFaYAcyOuXw!171.trak

http://www.utblog.com/plog/index.php?op=ViewArticle&articleId=174&blogId=1

6 二月, 2005

因为plogworld.net论坛上有人反映当文章数目多的时候，summary.php（也就是我们utblog的首页）装载的速度非常慢，这次推出的patch主要解决这个问题。

你可以从这里下载patch，原文here

在patch之前，我用diff看了一下更改的详细情况，分别简述如下：

1. summary.php :

   60c. //$siteBlogs   = $blogs->getAllBlogs( true ); getAllBlogs这个function非常耗时，而且也不必要。

2. recent.template : 因为去除了AllBlogs对象，模版中使用blogInfo来替代$blogs[$blogId]
3. summarystats.class.php : 这个Model中，主要修改的是最近回复文章列表和最多阅读文章列表。从原先查询所有文章改进为查询当月文章，Base减小了，DB Query的速度自然大大提高。

我们UTBlog打了这个补丁后，浏览的速度没明显变化（blogger太少啊:(），页面倒是变干净le

8 十一月, 2004

因为担心引起新blog user混淆，暂时隐藏“MT引用网址”
 查看全文

7 十一月, 2004

All blueish template refer to blueish.css. In this css file, side, sidetitle and description are all use x-small font-size. When we open these pages with IE, the x-small font text is very small, it makes content difficult to read.

So, I modified the blueish.css, change "x-small" to "11px". ( of side class, I changed the font-size from x-small to 12px)

(04/11/2004 18:56)

In panel.template, "link" sector,

<li>&nbsp;<a title="{$link-">getDescription()}" href="http://www.utblog.com/plog/{$link->getUrl()}" target="_blank">{$link->getName()}</a><li>

4 十一月, 2004

see http://www.utblog.com/plog/index.php?op=ViewArticle&articleId=14&blogId=3

4 十一月, 2004

blueish模版，右边pannel中文title乱码

Bug: When we use blueish template, it showes pannel title on the right of the page. If we use local_zh_CN, the pannel titles are chinese. Capitalize these chinese words will make the sentence mess.

Fix: rewrite the capitalize function. see details below

file: class/template/smarty/plugins/modifier.capitalize.php

function smarty_modifier_capitalize($string)
{

    //-- return ucwords($string);
    $strarr = explode(" ", $string);
    $i = 0;
    while( $i < count($strarr) )
    {
        $w = $strarr[$i];
        if($w && Ord($w)<128)
                $strarr[$i] = ucfirst($w);
        $i++;
    }
    return implode(" ", $strarr);
}

Problems: capitalize is not a build-in function, but php4 does offer this function, it's realized with C codes. It uses toupper() to make the first char uppercase. toupper is locale sensitive function, when it deals with chinese string, the error occurs.

I'm absolutely PHP newbie. There must exist a much better way to resolve this problem, and, perhaps what I updated will bring other unknown new bugs.