等于昨天几个小时，今天几个小时，搞出了一个小插件。就是右侧的一个小挂件。点上去就会链到CSDN的下载页面。

算是我把一年前的债还了。真开心。

插件里面没什么技术含量，就是小小调用了一下Google Feed API。

做这个插件，也引发了我一个思考。

能否在页面的head部分，就知道这个页面会装载哪些Widget呢？昨天折腾了半天，也没有解决这个问题。

解决的好处是显而易见的，现在的Widget，大多数都需要js来辅助了。但是很多高端的主题有数个sidebar，每页不同，如果Widget开发者，为了符合Web标准，把js放在head部分，就不得不无差别地在所有页面插入代码了。那样的话，添加一个Widget就会带来浪费的流量，页面速度也会被不断拖慢。

当然有个替代方案是把代码放到页面的footer部分，不过，个人以为，只要脚本出现在了Html body里面，那么直接嵌入到Widget中和hook到footer上，其实没什么本质区别，都破坏了行为和数据分离的原则。

这也是无奈之举了。谁叫WP设计成了sidebar.php执行前，无法知道页面会载入哪个sidebar这种结构呢？

当然，不排除还有更好方法的可能，如果知道的网友还望不吝告知。

昨天，为了隐藏掉Firefox的状态栏，我已经进行了相当多的努力，要隐藏掉状态来，还要保存状态栏的所有功能，着实不是那么简单的一件事情，老肥的文章只介绍了怎么把显示Active Link的功能搬移到地址栏里显示（使用Fission），还有把Gmail Manager整合到工具栏按钮。而我昨天提出的第三个问题，即firebug按钮，整合到工具栏后，调用方式变成“在新窗口中打开”，我今天终于给搞定了。

以下一段思路分析，可以跳过。

Firebug内部带的工具栏按钮，是一个双重状态按钮，即开关（toggle），按一下开，再按一下关。其上绑定的动作，就是在新窗口中打开，而不是我们熟悉并且喜爱的在同一窗口的底栏打开。修改的思路就是：

1. 找到这个按钮；

2. 找到在底栏嵌入firebug这个命令；

3. 将在底栏嵌入firebug的命令绑定到按钮上；

确立这个思路，完全是一种直觉，建立在对程序运行原理的理解上的，没错，就是函数调用，一般来说，一个按钮按下去，会调用一个函数，这个函数的运行决定了程序的响应方式，既然firebug有两种出现方式，那么可以简单的猜测，是两个不同的函数，一个从底栏嵌入，一个在新窗口中弹出。

好了，思路定了，就开始执行，那么怎么找？那可是相当难了，因为我完全没有接触过Firefox插件开发，对Firefox底层构架不了解，对于插件的结构更是不了解，于是乎，唯一的办法，瞎找。简单看一下插件目录下的代码，就知道，Firefox插件基本上由js代码，css代码，xml代码组成，除此之外，都是些图片。都是纯文本，打开查看没有什么障碍的。

最大的障碍是什么，就是不知道名字，其实昨天也有提到这个，就是改userChrome.css可以自定义外观，但是改哪个id的属性，改哪个class的属性呢？你不知道工具栏上第4个按钮的id或者class到底是什么，你更不知道按钮旁边的那个小箭头叫什么，凭什么叫dropmarker而不叫droparrow。就好像在茫茫人海中找一个只知道特征，不知道姓名的人一样。你只能傻看，不能调动公安局的数据库帮忙。我终于还是没能找到，毕竟傻找不是办法。

结局，办法总是有的，没有直接的，有迂回的。我想起来，firebug在工具菜单下有个子菜单的，哪个菜单里有两种调用firebug的方式，编过一点Win应用的可能都知道的，菜单的工作方式和按钮是完全一样的。那么找不到按钮，找菜单也可以，找到菜单，可以找到菜单调用的函数名，然后再用函数名去反过来定位按钮，也行。菜单项很多，而且一般会写在一个文件里，目标比较大，应该好找。哈哈，结果，还是不好找……囧。

灵机一动，菜单项里有汉字，汉字是字符串，靠，这下终于跟某个名字挂钩了，可以搜了！！直接打开locale文件夹，找到简体中文的配置文件，搜索菜单项，找到：

原来那个方法叫做DetachFirebug，ok，在整个目录下搜索DetachFirebug，一共没多少，一个个判断，终于找到：

最后，修改方法（刚才跳过的童鞋从这里接）：

找到:

文件，把上面那段代码找到，然后把cmd_toggleDetachFirebug改成cmd_toggleFirebug，把firebug.DetachFirebug改成firebug.Firebug，保存，然后重启Firefox，按一下工具栏上的firebug按钮，怎么样？是不是变成和状态栏按钮里一样的效果了？

Enjoy it！

好了，牢骚发完了，想想就玩玩Firefox美化好了，看看能折腾成个什么样子。

先介绍一下我参考的指南，老肥同学的四篇niubility：

Firefox 美化教程（一） Fission 与地址栏

Firefox 美化教程（二） Gmail Manager

Firefox 美化教程（三）隐藏菜单栏

Firefox 美化教程（四）让工具栏更整洁

实际上，还是有很多东西我很难搞定的：

1. %appdata%这个该死的目录在哪里？哈哈，我竟然在这个小阴沟翻船了，原来是系统盘上的Documents and Settings文件夹里的Application Data，唉……老了，一开始我理所当然地冲着Program Files去了，啥效果都没有……

2. 虽然老肥说编辑userChrome.css就可以设定这个效果，设定那个效果，但是，到底是怎么找到该设定哪个class或者id呢？我一直对这个很困惑，如果掌握这个，不是无敌了？要是有个firebug那样的东西能够调试，那就是无敌的无敌了……

3. 隐藏状态栏确实是很爽的，不过呢，现在隐藏了这个玩意儿后，firebug变得不爽了，因为firebug的工具栏按钮是在新窗口中打开firebug的，这真是让我着实不爽啊……难道要让我自己写一个firebug按钮么？头大……

4. 我现在发现那个Fission插件貌似不能完美支持Compact类型的主题，比如我现在用的主题是hmmmXP，结果地址栏的边框竟然被遮掉一块，这个真是相当难看啊……这次我预感是userChrome.css能够摆平的，不过，这个就回归到了第二个问题了，哈哈……

待续……

今天凌晨，Leo提出了给霍霍更换WP2.7，操作完成后，发现WP Thread Comment插件的后台直接评论回复功能失效。

这里特别提醒想要升级到WP2.7并且同时在使用WP Thread Comment插件的朋友，目前的WP Thread Comment插件版本的后台评论回复功能无法正常使用。

除此功能之外，该插件的其他功能尚未发现问题。如果平时就不用后台评论功能的朋友，可以放心。

原因分析

该插件在后台admin_footer部分，插入了一个表单，该表单内部有两个隐藏域，comment_post_ID和comment_reply_ID，还有文本框，其id为comment。大家更新到WP2.7后就会发现，实际上WP2.7在评论系统改进很大，本身就内置了后台评论功能，而这样的功能其实现原理都雷同，恰巧，WP2.7自身也在后台隐藏了一个表单，这个表单里也有两个隐藏域和一个文本框，又恰巧id也是上文提到的那3个。而且这个表单所在的位置比WTC插件插入的表单位置靠前。所以，WTC插入的js代码每次都读到WP2.7自己插入的表单域，这就导致了这个功能的紊乱。

解决方法

手动修改WP Thread Comment插件，将其插入到后台admin_footer部分的表单的隐藏域的id重新命名，如改成wptc_comment_post_ID，将textarea的id重新命名为wptc_comment。

然后将对应的后台评论提交部分代码（其他部分代码，如前台嵌套回复部分的代码不能改）里调用到这两个id的地方改名。

使用建议

没有足够的把握，请不要DIY。

禁用WP Thread Comment插件的后台回复功能，等待其原作者更新插件。

后记

原本以为WP2.7改进评论部分后，将会带来完美的体验，但是实际上，无论是其提供的嵌套评论功能，还是评论分页功能，都不是那么好用的，操作复杂，代码繁杂，定制性有限，极大地增加了主题开发者的负担。

作为用户来说，我本人也不是很想用WP2.7提供的评论系统的。不过，总体来说，我对WP还是有信心的，它的tag功能一开始也是相当地烂，后来也渐渐改好了。我想评论部分也会如此的。

如果用户的信息已经存在了，那么就帮他填好，如果已经填好了，就可以把表单也隐藏起来，并且显示一句欢迎语。不得不说，这个想法非常的有趣，所以，我决定自己来做一下。

第一次看到这个功能是在stephen的博客，然后从他的博客，我链接到了xiaorsz写的文章，然后看到了mg12的文章，再然后是xiaorsz使用jQuery的改进版本。

上述几篇文章已经对这个问题阐述得非常详细了，虽然说实现细节有所不同，但是基本原理是相同的。

1. 首先，读写Cookie这部分工作，WordPress已经帮我们做好了，基本上不用我们操心，也即如果用户发表过评论，则comment_author变量不为空，并且会自动填写到Comment Form的author输入框中。

2. 然后，我们用一段代码来隐藏昵称，邮件，网站三个输入框。

3. 最后，我们加上一句欢迎语，并且加上能够展开输入框的按钮。

我觉得这样一个小任务，使用jQuery来实现，简直再好也不过了，能够非常好的体现出progress enhancement的精神，所以说，我非要亲手实践一下，过过瘾。

我们看到，如果我们什么也不做，就仅有步骤1所表述的功能，自动填写Comment Form这样一个功能本身就是可用的，只不过不是那么漂亮，那么好玩而已！

接着，如果用户浏览器启用了javascript支持，并且，他正确下载了jQuery和页面代码，那么该用户可以得到步骤2，3提供的功能。也就是说，步骤2，3和javascript支持是并存的。

好了，分析结束，讲讲我的实现。因为是增强页面功能，所以，我就不打算去动原来的页面模板文件了。昵称、邮件和网址输入域，各自都有自己的id（分别是author，email和url），对于jQuery来说，这已经非常足够了，所以模板文件没什么需要改动的。只要创建一个js文件，写好上面的功能，链接进去就ok了。

下面是代码：

以后各位朋友跟我联系就会方便很多了。嘿嘿~~

也因此发现了一款非常强大的插件cformsII，真是不错，我目前正在汉化这个插件，虽然说，官方页面上有一个汉化包提供的，不过我个人觉得那个做得实在很差，很多字符串没有翻译，尤其是帮助部分。我估计那个汉化作者只是个英语专业的人才，对于博客，尤其WordPress，还有对于HTML，CSS等等知识很有限，所以，翻成那个样子也不能太怪他。我决定我自己来翻译一下，就当作是一个锻炼好了。

那个插件里有将近1000个字符串，而且很多都是大段大段的文字，估计我的进度会比较慢了，因为工程真的是非常浩大的。届时，我将会在自己博客上放出，供朋友们玩赏~~

好了，有什么好想法，赶快去Contact页面，给我发个信吧！！

今天，我在改进我模板的Archive页面，我希望能在Archive的侧边栏能够根据情景做出一些细微的变动。我希望当一个用户浏览我某个分类的Archive的时候，侧栏能够显示这个分类下展示最多的文章。

正好，我的博客上安装了WP Post Views Plus插件，这个插件就具有这个功能，只需要调用该插件提供的一个模板标签，get_most_viewed_category()即可。但是这个标签需要一个比较特别的参数，就是目标category的id，即一篇文章的cat_id字段。搜索了一下Codex，没有发现有哪个function或者template tag可以提供我需要的这个功能。只好自己找了。

首先，这个功能只有在Archive页面显示分类的Archive时候才能出现，平时不应该出现，这个很简单，可以用is_category()这个tag来判断，但是怎么能够知道现在展示的这个category的id呢，我第一个想到的就是去is_category里面看，先看看wp怎么判断is_category或许能够找到思路，进去一看，答案就揭晓了。

上面代码中的term_id就是cat_id了。到了这里，得到我们要的变量已经很容易了。

ok，这样，我们就拿到了我们要的东西了！万事大吉了~~

不过呢，我们继续去看看get_queried_object()函数的源代码，我们发现其实wp_query这个对象把它查询的某些内容抽象成一个query_object来对待，其实几乎那一系列的conditional_tag都有对应的query_object。更进一步，我们在这个函数里发现了，对于每一个query_object来说，都存在一个query_object_id。对于一个category来说，我们要的query_object_id就是我们要的category id。再往下一点，我们就看到了得到cat_id最简单的方法了。

哈~

为何使用Google自定义搜索？

减少数据库查询？使用Google搜索的话，当然可以减少对自己博客服务器的查询次数，但是作为一个普通博客，每天能有多少人去你的博客搜索呢？5,000人够多么？50,000人又如何，这确实是服务器的负载，不过这对于服务器来说，不是什么很重的负载，毕竟一台主机上绝大多数人，达不到5万这个量级的。不过，能省则省，何乐不为？

速度更快？对于一台高性能，低负载的博客主机来说，Google的优势并不明显，毕竟1s和0.8秒的差距不是什么人可感知的差距。但是，对于某些架在国外主机上的博客来说，对于某一部分访问不畅的用户，Google搜索的速度绝对要快于博客主机本身搜多的速度，毕竟Google服务器遍布全世界，总能有一台相对快的对用户请求做出响应。

结果更精确？哈哈，这个说法其实是有相当问题的。因为，Google对你的博客的搜索结果，直接取决于对你博客的收录数量，如果某篇文章根本没有收录，就不可能搜出来，那么谈何精确呢？Google连你博客的一个完备的数据集合都不具备。另外，从时效性上来看，Google的搜索也要落后，你认为Google对你博客的抓取频率是多少呢？无论有多快和WordPress博客本身还是有区别的。

能整合广告？能赚钱？呵呵……对此，我只能苦笑了。

好吧，貌似我已经把必须使用Google搜索的理由都推翻了，至少，从我自己的视角来看，使用Google搜索的必要性是不存在的。得出这么一个结论，是不是让诸位看官有点吃惊了？不过呢，我个人还是选择了整合Google搜索到我的博客。接下来，我来谈谈我是怎么想的。（以下内容，不喜欢的可以跳过）

首先，请大家去看看WordPress里面关于搜索的那段代码是怎么写的。那段代码在wp-includes/query.php中。wp2.5.x的是966行附近。wp2.6.x是979行附近。wp2.7.x是1740行附近。当然，内容是相当雷同的。简单说下，首先处理查询字符串，怎么处理的，我也看不大明白，结果我是知道的，查询内容被分解成了一个个关键词。然后，生成SQL语句中的条件字符串，类似于post_title LIKE %term_i% OR post_content LIKE %term_i%，对于每一个关键词i来说，都要生成这么一个串，于是乎，如果用户在搜索框中写了一长句话的话，那么结局可想而知了，博客主机的MySQL服务器将运行一个十分冗长的SQL语句。其效率也可想而知了。

其次，不知道有没有高手了解数据库的原理，即，这个LIKE操作，到底是怎样搜索的呢？就我所了解到的非常有限的知识来看，这个LIKE是使用了近似于正则表达式的方法，逐条检索数据库中的每条记录的。好，问题来了，现在数据库里只有一点点数据，1,000篇文章够不够多？有这个量的人很少吧，哈哈。10,000又如何？博客很难达到那个量的。所以，WordPress的搜索功能，看起来总是那么迅速。但是，WordPress博客自带的数据库搜索的发展趋势是明确的，文章越多越长，速度越慢。数据库里的内容本来是没有顺序的，索引给数据库带来了高速检索的机制（排好序的数据），但是，大家从代码里可以看到，这么样子写查询，跟索引是八棒子打不着的。

那么，搜索引擎的工作原理是如何的呢？第一步，蜘蛛爬取网页，博客的每个页面，由Google蜘蛛统一抓取到Google的服务器上；第二步，对所有得到的网页的内容建立索引，这里所说的索引，是搜索引擎内部使用的索引，非是数据库那种索引。基本上来说，一篇文章到搜索引擎里面，所有的词语会被切割开来，这个过程叫做分词，然后对每个词语建立一个索引，非常庞大的工程吧，简直令人叹为观止的庞大，因为全世界的网页约有600亿之多。而且，一般来说，搜索引擎会建立倒排索引（reverse index），简单说，就像英文技术书后面的Index一样，某个词，出现在第几页，第几页。；第三步，就是等待查询请求了，如果请求来了，搜索引擎就会去它自己建立好的索引中去查找，然后返回结果集合给用户；第四步，对检索结果进行排序，一般来说，搜索引擎的排序是按照跟关键词相关的程度来排序的，一篇出现WordPress十次以上的文章，肯定是比只出现了一次的要更与WordPress这个词有关了（对于数据库来说，根本没有这个步骤，你查询密码破解，很有可能查到一篇《黑客帝国》的影评）；第五步，这个步骤只对自定义搜索引擎才有，就是对结果集合进行过滤，将不属于你的域名下的结果全部清除。

搜索引擎是多么一个让人叹为观止的系统啊，一次看似简单的查询，有早先蜘蛛的辛勤工作，然后加上建立索引，最后是成千上万台机器去检索那些索引，一次搜索是无数计算机告诉计算的结果，单单冲着这个，我就要选用真正的搜索引擎了，因为，这真的很伟大。

最后，是搜索引擎对于查询字符串的分析能力，不知道大家知不知道，可以在Google搜索框中敲入及其复杂的查询语句，无论是整个句子，还是布尔表达式，或者许多奇怪的Google语法，这种竭尽全力去理解用户意图的贴心做法，绝对不是WordPress内部那两个正则表达式可以比拟的东西。

综上所述，使用Google搜索，可以获得更相关的搜索结果，可以更好的理解用户的查询，可以调动更多的计算机工作，满足你更大的支配欲（O(∩_∩)O）。所以，我还是选用了Google搜索。当然，对于我个人，还有个原因，我是Google Fans，你看我的主题，使用Google搜索才是理所当然的事情嘛。

如何在WordPress中整合Google自定义搜索引擎？

看看参考【3】，你可以从宏观上把握住这个整合的总体流程。而参考【4】，可以给你一个整合操作的详细指导。

参考文章：

【1】Google自定义搜索引擎重大更新：可自动搜索相连网站

【2】Google推出多语言自定义搜索引擎

【3】我爱水煮鱼：《整合Google自定义搜索到WordPress中》 ：这是一篇简单介绍如何整合Google搜索到WP博客的文章，不过，这篇文章只有简单的1，2，3，... 基本没有什么可操作性。不过讲解的步骤是对的。

【4】網生@誌 | zEUS.'Blog：《给博客添加 Google 自定义搜索》 ：这篇文章介绍了整合Google搜索的详细步骤，包括申请，修改代码，等等，并且给出了代码范例。可操作性很强。

先从文件在网络上传输说起，浏览一个网页，一般就是浏览器从服务器上下载文件的一个过程。举个例子，如果浏览我的网页，你要下载这么几个文件：

• 由index.php输出的一个HTML文件，也就是主页上的文字、链接还有他们的逻辑结构
• style.css样式表文件，决定了页面的外观
• jquery.js和vg.js脚本文件，决定了主页上的一些小功能，表单验证啦，ajax之类的
• 其他若干文件如logo.png，日志中引用的图片，或者留言中的头像，等等

浏览一个网页要下载这许多文件，如果每个文件又都很大的话，得到的结果只有一个，就是网页展现时间相对来说要长。如果能对传输的文件进行压缩，就能缩小文件的体积，加快浏览器的下载速度，减少服务器的流量。

还好，浏览器本身就是支持压缩格式的，比如gzip，现在问题的关键就是怎么让服务器把输出的文件压缩。我在网上搜了一下，一般最好的做法是使用服务器来压缩，Apache带有一个模块，叫做deflate，就专门干这个，如果你的服务器支持这个功能，那么你就很幸运，直接开启这个，然后配置一下就可以了。当然，我没有，所以，我也搞不清楚怎么配置啦。

服务器本身不支持，我们还有别的办法，那就是使用PHP来压缩了，PHP是支持gzip的。当然，又是一样，我讲不清楚怎么写那些代码，也搞不懂，但是这不代表我就不能用。

一个个说，压缩HTML文件，我用的是一个插件，就是WP Super Cache，这个插件自己就可以对Cache下来的文件进行压缩，只要在控制面板里面打个钩就行了。（WP 2.3 以前的，WP本身就有压缩功能）

刚才只说了压缩HTML，剩下的东西怎么办呢？本来我也是没有办法的，是看到了伟大的K2的代码，才知道，原来还可以这样。起作用的是这么段代码，这段代码在js文件夹的gzip-header-js.php和css文件夹的gzip-header-css.php中都有，内容几乎是一样的，其作用就是对这个文件进行压缩，并且要求浏览器缓存这个文件，缓存时间是两个月。

大家要做的也是很简单的，把上面这段代码，插入到你的js文件，或者CSS文件中，然后将他们的扩展名加一个.php就可以了。注意看我写的注释啊，不看清楚就照抄，你肯定搞不定。

现在来举个例子，比如我的页面使用了jQuery类库，那么我原本要这样写：

然后，我把上面的代码拷贝到jquery.js文件的最前面，然后重命名成jquery.js.php，引用时候写法也变成下面的样子了：

jQuery的那个文件原来的尺寸为55KB，经过这样的处理，浏览器实际下载量是17KB，只有原来的三分之一。

但是对样式表的压缩，并非那么一帆风顺，因为主样式表文件是不能重命名的，必须叫style.css，这是WP机制决定的的，如果你换了名字，模板根本不会出现在模板列表里面。

处理这个问题的方法我知道两个：

1，把style.css里面的内容，拷贝到另一个css中，比如，myzipstyle.css中，然后使用上面我说的方法，最后在header.php中加上对myzipstyle.css.php的引用，就可以了。而style.css里面就只有7行注释，你可以把对它的引用从header.php中去掉。但是这个style.css，及其文件内前面那些注释，都是必须的，不能删掉（虽然你可以不用）。

2，像伟大的K2那样，在style.css里面引用另一个css文件，写法如下：

乱七八糟，洋洋洒洒一大堆，希望能对你有所帮助吧~~

当然，还有更高级的方法，也更厉害，但是我是没有搞清楚的，我提提名字，如果你有志于再深入一步的话，可以有个出发点。再后面的方法就是，自己编译一个专门用于压缩的CGI程序（也可以用别人编译好的），然后放到服务器的cgi-bin文件夹里面，然后，手动修改.htaccess，让浏览器访问的每个文件，都从“压缩机”里面过一遍。你可以去：阅微堂（http://zhiqiang.org/blog/posts/speedup-your-blog.html），主人对博客优化有着深入而系统的研究。

改动不大。本来以为我这次添加了CSS Reset的部分，有望解决Opera的不兼容问题，结果发现问题不在默认设置上，这个努力是徒劳的。等于加了一些没用的代码，不过我觉得还是留着好，万一以后有人想用我的样式，那么他或许能有个好的开始，或者一个不至于太差的基础。

简单介绍一下我现在的模板，其实，就是在default上改的，不难发现，还留有浓厚的default的味道。所以，你如果想用，拷贝下我的样式表回去改改估计就可以了。

今天还做了一个事情，就是把样式表按照逻辑分了块，这样就条理比较清晰了，也比较利于抄袭。嗯……

最后就是把K2的CSS压缩技术照搬过来了，这样一来，多了一个http请求，但是样式表的体积减少了一半。不管我换多少模板，还是忘不了K2，可以汲取无数营养的K2，伟大的K2。

经历了几个版本的演化后，Simple Tags的功能已经越来越强。输出相关日志的功能最终也被集成到了其中。在Simple Tags后台页面，通过简单的设置，就可以轻易实现在Feed、帖子页中，输出相关日志。

但是，通过后台设定添加的相关日志列表不能控制其出现的位置，Simple Tags采用filter来将相关日志列表追加到了文章内容的末尾（关于filter的说明，可以参考我翻译的文档），很多WPer都会在文章末尾添加很多东西，比如版权（如本站），社会化书签，有的还有广告等等，如果相关日志列表没有出现在合适的位置，不但影响美观，还会影响用户友好。

解决办法一般就是采用专门的Related Posts插件，比如我爱水煮鱼，就提供了一个这样的插件，使用起来也相对简便。现在，大家又有一个选择了，因为，按照查理的理论，同样是直接在页面模板中插入代码，插入一行和插入三行，是完全一样的。既然这样，为什么要多安装一个插件呢？（关于效率和功能的强大与否，查理没有对比过，所以，也就没有什么发言权了，所以，这也不是非要使用这个方法的一个理由，有兴趣研究的同学，可以把你的结果告诉查理，我会把你文章的permalink，添加在本文中）。

好了，闲话已毕，我们来看正题，首先我就把那三行代码贴在这里吧，全部采用默认设置输出相关日志的话，看到这里就可以大功告成了！在你自己的模板文件的single.php（如果使用K2，那么是theloop.php）中的合适位置，加入下面的代码即可输出10篇相关日志列表，如本站效果。

<?php
if (is_single() && function_exists('st_related_posts'))
{
st_related_posts('number=10&include_page=false&order=data-asc');
}
?>

简单解释一下，st_related_posts()是Simple Tags插件提供的公用函数，可以直接输出相关日志列表。

1. number–输出相关文章的数量
2. order–输出相关文章的排序。可选值：
   • date-asc - 旧日志在前
   • date-desc - 新日志在前
   • count-asc - 相同标签数少的日志在前
   • count-desc - 相同标签数多的日志在前（默认）
   • name-asc - 字母顺序
   • name-desc - 字母倒序
   • random - 随机
3. format–不建议设定此参数，用法参见文档
4. separator–不建议设定此参数，用法参见文档
5. include_page–true表示包括页面；false表示不包括
6. include_cat–需要包含的分类的ID，用半角逗号间隔，不设代表所有分类
7. exclude_posts–不想包含的日志ID，用半角逗号间隔
8. exclude_tags–不想包含的tags的ID，用半角逗号间隔
9. post_id–不建议设定此参数，用法参见文档
10. excerpt_wrap–不建议设定此参数，用法参见文档
11. limit_days–多少天内的相关日志，不设代表所有日志
12. min_shared–包含相同tag的数量，默认1（两篇文章有一个相同tag），设得越大，相关日志越少
13. title–日志列表前的标题，可以使用html标签，如<h4>
14. nopoststext–没有相关日志时候显示的文本。需要一个字符串，请用单引号括起来。
15. dateformat–显示日期的格式，默认和WP的格式相同，想要修改的话参见PHP时间函数的参数设定格式
16. xformat–扩展链接格式，默认的就很不错了，想要修改的，看文档吧，或者在Simple Tags的后台也可以设定

实际上，我大错特错了。我用的是VS2005，里面根本就没有找到类似的选项，最多只能生成一个xml格式的注释提取文件，但是大家都知道，xml虽然是文档，但是not for humen beings。通过搜索，我知道了早在.net 2003的时期，VS是支持这个功能的，但是从2005开始，这个功能就被取消掉了。

一般网上搜索到的文章都会推荐NDoc1.3，这个着实误导了我一会儿，因为这个叫NDoc的开源项目早在2005年就已经停止开发了。其支持的.net framework版本只达到1.1。关于介绍这个NDoc的使用的文章，大家可以看一篇英文的文档如下：

http://www.codeproject.com/KB/XML/csharpcodedocumentation.aspx

上述文档从C#中的xml格式的注释开始，到NDoc的使用，都给出了非常详尽的说明。但是，现在真的还有人用.net 1.1的话，看到这里就可以直接去留言了，呵呵。我现在正在使用的是.net 2.0，我相信还有很多人跟我用同样的版本。刚才提到的NDoc最终版本为1.3，不支持.net 2.0，那么下面这篇文档介绍了如何让NDoc 1.3支持.net 2.0，一共给出了三种方法。

http://forums.asp.net/t/997774.aspx

不过，我都没有实验成功，一个是通过改配置文件的方法，上面的帖子里面可以下载的。还有一个是通过重新用VS2005编译NDoc1.3的源码的方法，这个方法在转换项目的时候有一个链接库找不到，是Html Help Workshop的一个链接库，我的系统里面没有，所以我这个方法也没有成功。

再后来，我找到了微软官方发布的工具，叫做Sandcastle（沙堡？），这个工具是微软官方推出的专门用来生成文档的工具，不过很遗憾是命令行工具，当然我不是一个命令行狂热者，否则我不会这么失望。下面的链接给出了这个工具的博客，可能你会找不到下载链接，呵呵:-)。

http://blogs.msdn.com/sandcastle/

上面的那个官方的，王道的工具，真的很难用，我装上了，完全用不了，因为要好几个步骤，好多命令，所以，骂我白痴吧。但是有个好心的老外，为其开发了一个界面，叫做SandcastleGUI，就是很简单的界面，在下面的页面里，大家可以看到这个工具的介绍。

http://www.inchl.nl/SandcastleGUI/

http://www.codeproject.com/KB/cs/SandcastleBuilder.aspx

经过试用，我发现，这个东西似乎没有什么作用，就是基本上什么也没有产生出来，所以，真的让我很失望，但是很多人说这个挺好用，第二个链接是另一个GUI的Sandcastle，界面模仿得已经和NDoc很像了，但是我用了以后，发现我程序里面引用了一个第三方插件，造成这个东西异常了，最终也没有能够产生出我要的文档。看来微软的这个工具还真的像沙塔一样不可靠呢。

最后，我知道了一个叫做NDoc2005的开源项目，在NDoc的基础上建立起来的，可以兼容.net 2.0。看来，我的希望来了。

http://sourceforge.net/projects/ndoc05

上面的网址可以获取NDoc 2005版本，但是我提醒想要偷懒的兄弟们，一定要下载源代码包，因为如果你只下载安装包的话，你会发现有个叫做Documenter的东西一直找不到，你什么文档都得不到的，只有那个src包里面才有这个文件夹。我就是把这个文件夹拷贝到了C:\Document and Settings\下面，才能正常使用的。这个工具如同NDoc1.3，可以生成msdn，xml，javadoc，msdn2003（beta）等各种格式的文档。非常强大。而且，如果程序里面引用了第三方插件的话，也可以成功跨过去，编译第一次会失败，第二次就会成功（不知道为什么）。

本来，故事到这里就结束了。但是，如果你像我一样，非常土的用中文写注释的话，那么故事还没有完，有可能你会碰到这个情况。当你编译msdn格式的文档的时候，你把LangID选成2052的时候，虽然能够支持中文，但是英文空格都以"？"来显示，而你把LangID选成1033的时候，虽然英文正常，但是所有汉字都是"？"，怎么样，够恶心吧，不能非得二选一吧，我甚至尝试着自己编译NDoc2005的源代码，解决问题失败。

终于，皇天不负有心人，我找到了这个。NDoc2007，实际上那篇文章是非常简单的，就给了个链接和一句话。见下面的链接。

http://blog.vckbase.com/bastet/archive/2007/07/11/27300.html

如果那个链接已经失效了，我还备份了一份。点这里。

这个东西，我还是按照自己的理解来描述一下。就是等于说在你的对象里面放一个函数指针，这个指针指向某个函数，你还不知道，当对象被创建了，处理事件的那个函数也在程序的其他某个地方被创建了，并且赋值给了这个函数指针的时候，通过这个函数指针，你就可以调用那个时间处理函数了，看起来，就好像发生了事件一样。

所以，事实上你在创建这个函数指针的时候，并不知道这个指针是否肯定要被赋值，也有可能永远不会被赋值。所以，每次调用的时候，应该判断是否已经被赋值。

这就让我想起了以前我在天津的时候，那种住宅楼都有一条专门走垃圾的管道，想让你们家支持扔垃圾这个事件，就要把垃圾管道通道家里，但是你并不知道管道的那一头是不是连接着垃圾箱，或者垃圾箱还没有建好，所以，你必须在扔垃圾前确认一下，当你发现楼下的垃圾箱完好的时候，你在家里，当你需要扔垃圾的时候，你只要打开管道的门，把垃圾袋放进管道里面，就O.K.了，楼下的垃圾箱就会收到一袋垃圾，然后会有专人处理垃圾箱的。

你在扔垃圾前也可以不去确认，那么结果就很糟糕，你知道的，可能当你走到楼下的时候，一转弯，发现一大堆很臭的垃圾，而那恰恰是你自己扔的。嘿嘿……

今天，对这个问题又有了新的认识，基本上访问网络不畅，或者访问国外网络不畅的机器安装了调试环境想要调试WordPress，就会碰到这个问题。

今次，我在Linux上调试WordPress，安装好了，死活进不去，而且，Firefox一直显示正在等待，一直也进不去。而且，没有任何提示，如下面说的错误信息也没有显示出来，好像在Linux下面需要一定的配置才可以显示的。

解决办法倒是一致的。将Update.php里面的那个函数屏蔽掉就好了。虽然，能自动升级是WordPress的一个很好的特性，但是如果刚好访问国外服务器不畅，会造成你的后台无法访问。假想中美电缆又断了，那么很可能你放在国内服务器的WP的后台就不能进了，而且会发生超时错误。

更进一步，我通过修改Update.php进入了后台，如我所料，插件管理页面进不去了，原因很简单，一样的，要检查更新，所以造成无法打开插件管理页面。

这次要修改的也是一个wp-admin/includes/update.php页面。里面有个函数叫wp_plugins_update，这次，我想不用赘述了，方法和下面说的一样的。

====================================
Maximum execution time of 30 seconds exceeded in update.php on line 52

前段日子，机器上的Apache动不动就占用900M+内存，让我十分之烦闷，有时候调试主题，就突然死机了一样。不知道原因，难道说Apache长时间在Windows下运行水土不服？

于是乎我登录了Apache网站，看到其已经升级到了2.2.8，想到新版本比我原来的2.2.3已经多了5个版本号，应该要好一点吧，遂换了上去。连带ZendOptimizer也更新到了3.3.3。谁想，刚刚更新好，WordPress就打不开了，就是第一行那个错误。

看了看update.php的代码，原来那里需要连接到互联网上去检查升级信息，我估计是我新装了Apache但是没有在杀毒软件或者防火墙之类的里面设置规则，造成了Apache 不能访问英特网。因为这次装好Apache，Windows防火墙就始终没有跳出来。

后来想了想，不要搞防火墙了，我反正本地只需要调试样式外观，也没有必要升级什么了，索性将检查版本的功能去掉了。

像上面那样写了个空函数，代替了原来的函数，这样以后想恢复，只要删掉就好了，就这样，我想如果在服务器上也这么搞，会不会让后台进入的速度更加快一点呢？

看了一下CSS文件，发现使用focus伪类来实现当获得焦点时改变背景色的功能，但是，在IE7下面，没有任何效果。网上搜索了一些办法，我觉得可行，正好K2里面也包含了jQuery，可以好好利用一下。

最后，我使用了：

jQuery("textarea").focus(function(){
jQuery("textarea").css("background","white");
});
jQuery("textarea").blur(function(){
jQuery("textarea").css("background","#666");
});

这样四行代码，实现了当获得焦点时候改变背景色的功能。不禁感慨jQuery的强大，以后还要多学学，关键时刻可以拿来救急，呵呵。

===========================

2008年4月11日22:58:06
1、今天字体颜色我已经调整了，亮了一些了。
2、很多图标的显示不正确也修正了。
3、觉得留言时候的那个字体颜色实在是——看不清
4、觉得标签应该在首页显示一下的
5、觉得标签应该显示在文章的最末尾
6、觉得标签应该显示成橘红色
7、帖子页面上，作者的留言颜色和普通留言不一样，但是我竟然没有改
===========================

2008年4月10日23:28:33
不知道为什么，我觉得自己给自己制作一个WordPress模板是超级有乐趣的事情，真的，我乐此不疲。

今天，花了很多时间来做这个事情，就是把一直以来我很喜欢的5U和K2硬给捆绑在一起。这样，我既获得了5U的美观，也获得了K2的强大。我的动机是如此单纯。

这次对CSS的操纵已经是驾轻就熟了，比上次移植禅意花园的主题的时候轻松多了。但是这次却面临了新的挑战。主要是这次，使用了K2提供的特性，就是把自定义Style分离出来，这样不但可以单独发布，还可以避免在K2升级的时候把自定义的CSS文件覆盖掉的危险。

现在大家看到的，就是我今天的劳动成果了。

可以说，很不完善，但是我真的很喜欢这个，所以我迫不及待的把它贴出来了。

我对以下几点不满意：
1、文章与文章之间的独立性不强，就是说整个页面布局看起来还是一长条，不是给人一篇文章一篇文章那种逻辑清晰的感觉。
2、侧边栏的颜色我基本没有调整过，还是K2原来的颜色，出乎意料的倒也不是那么难看，这也是我敢换上这身衣服的原因。
3、Single Page我根本就没有动过。
4、文章字体还没有动过。

自动升级到1.5.1版本后，后台管理界面中，Simple Tags的Option全部变成了英文版，造成这个原因是Simple Tags的翻译文件没有自动加载，也就是mofile。

解决办法：

找到文件simple-tags.client.php，在其中找到：

改写成：

造成问题产生的内部的根本原因，我还没有探究，先这样解决问题吧……唉……

怎么会这样呢？一定是CSS出了什么问题了。我于是到style.css中寻找关于user.png的样式，找到了：

与那副小图标有关的样式设置仅此一条，按理说不会有问题啊，根据这个样式说明的，只有在class=author的容器内，才会在链接前多出那么一个小图标的啊，于是一个恐怖的念头涌上心头，该不会最外层容器也即body的class被设定成了author吧，马上打开一看，晕死，真是这样，怪不得让我的页面变得这么恐怖。

赶快去看author.php文件，看到控制body的class的是一个函数sandbox_body_class()，于是乎又打开functions.php，找到：

如上，第4行被我注释掉了，这样，就把author从body的class中去除了。

其实，我的解决办法肯定算不上是好的方法，不过我觉得这个author放在body的class里面也没有什么大的作用，所以就这么破坏性的改了，老天保佑我不要碰到依赖这个class的style文件吧。呵呵~~~

滚动条出现的原因是容器内部的文字过长，发生了溢出，浏览器根据样式表或者默认的方法对其进行处理。当然，CoolCode插件的样式表，让那个代码显示框出现了滚动条。

出现滚动条可以最大限度地保证代码的完整性，可以让观众看到一字不差，但是说实在的，滚动条很破坏页面的整体感，反正就是让我看着不爽。反正我贴的代码我都很清楚，观众什么的，唉，还是把页面的美观放在第一位吧，不好意思啦各位~~：D

其实就是一行CSS的问题啦，但是发现行代码，到使用两种浏览器对各种参数设定的显示效果进行验证，我还是费了一些事情的。好，我还是把最简单的结果告诉大家吧。

找到coolcode.css文件，在其中找到：

将overflow的属性值改成hidden，就可以实现不展示滚动条了，但是，其缺陷也是很明显的，顾名思义了，如果字太长，就会被hidden咯~~这个就看自己怎么取舍了，如果以后都能在这个问题上注意点，效果应该不会太差的。

顺便说一句，hidden也并不是不分青红皂白的就给砍掉，而是如果你的这行字很长，而且中间一个空格都没有，才砍掉，因为这个时候浏览器不知道在那里斩断换行，所以只好砍掉了。这也就是大家看到的，上面引用的代码中，为什么font-family那一行没有被斩断，而是自动换行的原因。

不过，今天我发现，不知道从什么时候起，CoolCode不能正常工作了。

我发现，coolcode.css和coolcode.js两个文件，无法加载成功。

我本来还奇怪呢，怎么CoolCode现在的外观和以前不一样了，原来CSS根本就没有加载。为什么没有加载呢？经调查，这两个文件的URL填写的根本就不对。WordPress有一个功能，就是可以将你的安装文件放到一个文件夹里，但是把主页放在根目录下，这样可以让你的根目录看起来很整洁，如果你还在根目录下安装了别的程序的话，不会搞乱掉，而且，这么做以后升级也方便。

进行过我这样的操作的人，使用CoolCode都会在这个问题上遇到麻烦吧。打开coolcode.php看这里：

大家注意一下，上面用的两个函数，get_settings("home")，这个函数返回的是你的主页的url，并非你的wordpress的安装目录，当然，如果你的WordPress刚好安装在了根目录下，那么你使用这个插件是一点都不用改的（改了是对的，不改是凑巧对），但是如果你的WordPress像我一样，安装在自己指定的目录，那么这里就必须改了。

改的方法也很简单，将get_settings("home")函数，替换成get_bloginfo("wpurl")就可以了，好了，赶快再实验一下吧，怎么样，这回是不是真的很Cool了？

所以，至少（我总是舍难求易）我要模仿个样子过来，(*^__^*) 嘻嘻……

侧边栏的Search框，是WordPress里面自带的，怎么才能把那个按钮给隐藏掉呢？

嘿嘿，我去参考了K2的代码。说实在的，一开始，还真的没有找到。后来经过多种手段（我偷师有多种办法，以后慢慢介绍，哈哈）分析，终于发现，原来K2使用的是javascript脚本代码做到的这个事情。

毫不留情地偷过来，啦啦啦~~~

首先，我编辑了一段代码，存成了js文件。如下：

有了这段代码，就可以使有“搜索”两个字的按钮给隐藏掉了。
然后要做的就是把这段代码插入到模板主题中。
打开index.php，找到：

在前面加上：

好了，现在试试看吧，什么不行？使用多种手段（靠！又是这个……）发现，原来没有jQuery对象。只好又去下载了压缩版的jQuery.js（这是什么东东？我以后的文章会说的啦~），然后再加上一句：

好了，这下大功告成了。
（我是基于SandBox1.3改的，实际上，要根据自己模板的不同，来决定是否加入jQuery，有的模板可能本来就有了。）

我也被SandBox的这种特性所吸引，更让我看重的是使用这款主题，可以像CSS 禅意花园那样，只通过更换CSS样式表，就使整个界面风格改变。虽然我对CSS也有兴趣，但是实在没有时间和艺术细胞去自己搞一个CSS，好在有很多的爱好者，做了无数的美丽主题，使得我可以不费吹灰之力，就把自己的主页变成了现在这个样子。

然而，非常遗憾，对于用惯了K2的我来说，SandBox还是有很多功能上的不足呢。不过人家本来也不是以功能强大和动态效果著称的，没法子，只好自己动手了，谁叫这个模板叫“SandBox”呢（A low box filled with sand for children to play in.）。

以前，真的用了很长时间的K2，后来由于使用K2模板的主页不知道为什么一直在我的虚拟主机上运行超时，才不得已换掉了。但是K2带给我的那完美的印象却没有因此损失分毫。所以，我最想做的，就是让我的SandBox在常用功能上，更接近K2。

好，首先就是把主页导航给补充完整——添加“首页”的链接，其实，这是一个很简单的事情（难的我也不会），就几行代码就可以搞定了，但是不知道为什么，那么多模板，都没有考虑到这个问题，一个最最一般的网站也会有这个链接的。

不废话了，直接说怎么改吧，打开/rootdir/wp-content/themes/sandbox/functions.php，找到下面的代码：

将上述的代码改成：

简单解释一下上述的代码，show_on_front是WordPress的一个属性值，指的是WordPress默认展示的页面，可以是最新发表的文章，对应的值为posts，也可以是静态页面，对应的值为page。如果你自己指定一个页面作为默认展示的页面，那么那个页面就应该是真正意义的首页，你说对吗？所以这种情况下，我们是不用多此一举添加一个首页导航的。

接下来的一些代码是确定，什么情况下，给首页链接的class添加current_page_item类的代码，这主要是为了在CSS里面控制current page的导航标签的显示样式用的，如果你的导航是那种纯粹的没有任何变化的导航条，那么下面这段if中的代码也就没有用了。

最底下，我加了一行wp_register()函数，这种wp_xxxx()的函数，叫做WordPress Template Tag。按照文档，这个函数的功能是在没有登录的时候显示“注册”，登录后，改成显示“网站管理”。熟悉这些的人一定知道，这也是在学K2，但是其实，K2导航上是不会显示“注册”的，我在自己机器上调试的时候，也不会显示注册，难道说这是WordPress 2.3.2和2.3.3的一个差别？不得而知了。

首先，我说一下为什么要更改。

一般来说，更改这个东西没什么必要的，只不过我这个人比较神经而已。有人说，修改可以提高显示速度，但是我不以为然。因为，速度什么的，实在是提高不了多少的。至少我改了，没啥感觉。倒是去掉了些我根本不会看的英文新闻和消息，让我觉得很舒服。当然，WordPress中文团队早就想到了这个问题，我这次下载的WordPress中文版里面包含了他们写的中文Dashboard插件，就是替换掉那些英文消息用的。如果用那个，就完全不用看我的文章了。

后台管理的首页是/rootdir/wp-admin/index.php，打开这个文档，就会看到下面的一段代码。

上面一段代码，使用jQuery框架，将实时获取的内容，填充到了管理首页上。

第一行是传入链接，就是今天，互联网上有哪些页面链入到你的页面。根据代码来看，使用的是Google的blog search，不过本人觉得，对于像我这样的汉语博客来说，好像百度更加亲切一点吧（毫无根据的胡言乱语）。

第二行是WordPress的开发博客提供的内容，其实就是wordpress.org上的东西。不过，都是英文的，说实在，我么兴趣。

第三行是国外WordPress联盟什么的，具体我也说不清，反正我也是不看的。

于是乎，你可以根据自己的需要，注释掉一些，或者全部注释掉。就可以了。

然后大家来看看下面这段代码，这个是在管理首页显示一下有多少“计划发布文章”的代码。

WordPress很强大，这种定时发布的功能都有了，但是实际上，我用过，好像我写的文章立刻就发出来了，不是在我设定的未来发布的。而且，一般上，我也不会定时发布日志，所以，在这种地方浪费一次数据库查询，实在是没什么必要。所以我去掉了。

再看下面这一段：

这是显示等待审核的评论的显示，对我这种基本上只有我一个人看的博客，10天也没有条评论，这东西好像根本没用，再说，我现在用了Akismet来屏蔽垃圾评论，并且开放了发表评论权限，所以，根本就不需要审核什么评论。这段代码对我没用，直接砍掉了，可以节省两次数据库查询。

这样，我已经砍掉了很多的代码了，后台管理首页也就显得比较清爽了。哈哈^^