WordPress在脚本库中添加了thickbox的脚本，调用起来格外地简单。所以我就选用了这个作为WP插件后台管理界面中，用户交互对话框的解决方案。在这里，介绍一点我在开发过程中的经验。如果需要在thickbox弹出窗体退出时执行一些动作，那么比较好的办法是向#TB_Window的unload事件绑定动作，thickbox在退出时会触发该动作，该动作是在tb_remove()函数中触发的。

向这个事件绑定动作的方法有点小窍门，因为页面初始化完成后，文档Dom中并不包含#TB_Window元素，只有在thickbox被触发后，该元素才添加到Dom中。经过阅读源代码后，我发现，可以在触发thickbox的对象的blur事件中，向#TB_Window的unload事件绑定动作。示例代码如下：

一般在命令行下，manpages通过粗体和下划线来标记关键信息，有多种方法来使man命令显示彩色的manpages。

man是调用less来显示manpages的，可以更换这个程序，使用most来显示，这是一个方法。但是长期以来使用less，已经习惯，most又有一套操作方法，后来我又发现了一种方案，非常简单，只要通过在bashrc中设定环境变量，就可以高亮彩显manpages，非常方便。

设定方法如下，在.bashrc末尾添加如下几行：

export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'


如此，即可以为manpages添加红绿两色，虽然不多，但是远好过了单调的黑白页面。

LaTex一般指的就是LaTeX 2e，是一个在TeX基础之上编写的宏包。关于TeX的起源，还有一段佳话，我就不赘述了。乍一接触LaTeX，无论是由于任何原因，也免不了要把这个软件和Word相比较，我同样不能免俗。要说二者的差异，最大的地方还是理念上的差异了，关于这种差异，我同样不想赘述。我只谈体验。LaTeX无论是学习，还是编写文档，初上手给人的感觉就两个字，痛苦。

痛苦有三：

• 环境配置复杂——抛开使用Word需要支付的软件费用不谈（因为此地是D的王国），安装LaTeX环境是一件比较麻烦的事情，为什么比较麻烦，不就是双击一下Setup.exe吗，说起来是这样，但是与Word的别无选择不同，LaTeX有很多可选的环境，CTeX，TeX Live，MiCTex，MiTeX，装哪个？哪个东西好用，基本上是众说纷纭，决定最终装哪个，就要下不少功夫。如果你恰巧装了不是特别“傻瓜”的那个，那配置起来就有点麻烦了，而且，一开始你可能认识不到自己装的那个够不够“傻瓜”。比如一开始，我装的是MiCTeX，后来当我应用论文模板后，发现死活编译不过去，肯定是少了什么重要的宏包没有安装了，但是装哪个呢？鬼知道。无奈之下，又安装了CTeX，这才太平了。
• 纷繁复杂的命令——几乎做任何事情，都有对应的命令，开始一个章节，改变字号，引用图表，插入特殊符号，全部是以一个反斜杠开始的各类命令。要记住这些命令，谈何容易。熟练运用的人，肯定对我嗤之以鼻，就像五笔字型打得快的人，绝不认为字根表是一种负担，LaTeX用的熟的，同样认为记住区区几十条常用的命令，算不上什么负担。另外一点，在LaTeX下，做同一件事情，可能有多种命令可以实现，用哪个呢？这种选择和取舍，也是令人头疼。比如昨晚我要画个表格，一Google，无数的文章，基本上有table，tabular，tabbing三种，搜出来的示例代码，就没有跟我论文模板示例代码相同的，你说这麻烦不麻烦？
• 诡异的错误提示——LaTeX标榜的理念是WYTWYG，所想即所得，完全不同于Word的WYSWYG，所见即所得。所以，要想看到用LaTeX编写的文档的最终效果，需要编译。而写代码这种事情，难免写错，一般程序写错了，可以调试，可是LaTeX写错了，看着那奇妙而诡异的调试信息，只有抓狂的份了。要说是束手无策，也不为过。只能亦步亦趋，写一小段，就编译一次。始终知道产生错误的是哪一段代码，否则的话，整篇写完才拿去编译，你根本不知道是哪条命令用错了。

既然这么痛苦，那就别用了，也是啊，我还真的直打退堂鼓，然而呢，其最终得到的完美效果，也让人爱不释手。

诱惑有三：

• 等长等宽等间距——每行的长度，行距，字间距，字母间距，都堪称完美，绝对是Word没法匹敌的。如果你说看起来差不多，那我没什么好说的了。排版这种东西，就是细微之处见真章的，如果你都是粗粗一看，那还犹豫什么，Word绝对OK了，受这罪干啥。但是如果你对美有所追求，那么你很容易在LaTeX的排版结果中发现美的存在。如果在文字中参杂一些公式，效果更是明显。
• 样式统一无误差——在Word里，写大型文档，免不了去管理那个样式列表，标题1~7分别什么样式，列表项什么样式，段落什么样式，等等等等。还有复杂的继承嵌套关系，相互影响。往往就像是跷跷板，这头压下去，那头翘起来。就算一份确定的样式，也总是时不时出问题。LaTeX的好处就是一旦你有一个固定的模板，那么你只要一心写文章就可以了，所有已经指定的样式，都会被严格执行，绝无误差，只要正确编译通过，所有的样式都能符合你的要求。麻烦起来是绝顶麻烦，省心起来就是一劳永逸。
• 交叉引用参考文献——由于是最后编译，统一机器编号，所以，LaTeX编写文档，都不需要太操心交叉引用和参考文献的问题。人肉编号，或许还会粗心，机器编号，绝对精准。还是那句话，只要你有本事编译通过，得到的效果，就是完美的同义词。

学习新东西，总还是让人充满了喜悦的。尤其是LaTeX这种，虽然麻烦不断，但是总还能够给人惊喜，不知不觉就深入其中，这种感觉很棒。不过我估计，此次毕业论文写完，我可能就与LaTeX再无渊源了，毕竟平时写文档不可能花这么多时间和精力去尝试的。就当做一次美好的纪念继续好好体验吧。

经常要开发一些小项目，实验室里没有统一的文件服务器和版本库，那么只好自己动手来搭建一个。

推荐使用http://www.open.collab.net/提供的SVN，服务器和客户端软件包一共只有11M。是全命令行的界面。

在页面：http://www.open.collab.net/downloads/subversion/

下载：CollabNet Subversion Server and Client v1.6.3 (for Windows) 下载的时候请选用最新版本，一般来说更新得非常勤快的。

下载后双击安装，安装过程中会提示，是否把svn安装成service，选是。

安装完成后，可以检查一下svnserver是否已经启动。

检查方法为进入控制台（开始-->运行-->cmd），输入命令

netstat –an

看看Listen列表里是否在监听3690端口，如果已经在监听了，说明svn服务器已经启动，如果没有启动的话，进入“控制面板”-->“管理工具”-->“服务”，找到CollabNet Subversion，然后点启动。（按照我的理解，这项服务应该在重启计算机后自动启动的，但是不知道为什么，我的没有自动启动，只好手动启动一下。）

到此，服务器已经安装完成了。

按照安装过程中的设置，会在你的磁盘上生成一个svn_repository的目录，从命令行进入该目录，输入命令

svnadmin create my_repository

就会建立一个版本库。

然后进入该版本库，进行配置。进入conf目录，有三个文件需要配置

svnserve.conf

[general]
### These options control access to the repository for unauthenticated
### and authenticated users.  Valid values are "write", "read",
### and "none".  The sample settings below are the defaults.

anon-access = read
auth-access = write

### The password-db option controls the location of the password
### database file.  Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.

password-db = passwd

### The authz-db option controls the location of the authorization
### rules for path-based access control.  Unless you specify a path
### starting with a /, the file's location is relative to the the
### directory containing this file.  If you don't specify an
### authz-db, no path-based access control is done.
### Uncomment the line below to use the default authorization file.

authz-db = authz

这个文件有若干的选项，上文中引用的部分为比较基本的几个选项，主要是控制访问权限的。

authz

[/]
sexywp = rw

password

[users]
sexywp = 123456

另外两个文件分别是authz和password，里面的内容如上述。主要的含义是创建了一个用户，名字为sexywp，其密码为123456，对整个版本库的根目录有读写权限。

至此，服务器端的版本库已经建立完毕了。下一个步骤就是把项目代码导入到版本库了。

导入版本库非常简单，可以从服务器端导入，使用import命令，也可以从客户端导入，我接下来介绍一下从客户端导入。

首先找到一个目标目录，你要在这里管理你的代码，比如E:/MyProject目录下，然后执行命令

svn checkout svn://localhost/my_repository --username sexywp --password 123456  

然后，你就会得到一个my_repository的空目录，进入后，里面有一个.svn的隐藏目录，除此之外，没有任何其他的东西了。

你可以在这个目录里建立好你版本库的结构，比如，我会建立三个目录trunk，branches，tags（使用svn mkdir命令），然后，将项目代码拷贝到trunk目录下，然后执行

svn commit –m “first version”

命令，将所有代码导入到服务器的版本库。

我前几天，写过一篇关于E63的文章，主要初上手E63时的一些感受，包括对手机外观和功能的简单评价。在这一篇中，我将介绍我最近几天来安装各类E63软件的一点经验。

证书

使用其他手机操作系统，以及使用Symbian S60第三版以前的系统，可能都不需要跟这个麻烦的东西扯上关系。证书说白了就是允许在一部手机上安装软件的一种许可。这种许可只对某部特定的手机有效，识别办法是手机的IMEI号，（在手机上按下*#06#即可查询）。

每个需要安装到你手机上的软件，都需要与证书进行绑定，否则将无法安装或无法使用。

证书的作用，其实是限制了手机软件传播的自由，这样做当然给手机用户带来很多麻烦，但是也增加了安全性，病毒在手机上根本无法传播，从一部手机转到另一部手机，就必须要去和那部手机的证书进行绑定，这样一来就根本无法传播了。

一般来说，能在手机上进行的各类操作，有若干种（使用网络，使用文件系统，读取用户数据等等），每种操作的安全级别不同，需要的权限也不同。因此，也就有着多种规格的证书，有些无论如何也不会侵害的用户安全的软件，比如小游戏这样的，只要最低规格的证书签名或者不需签名即可使用，但是另一些高级功能的比如使用网络的软件，就必须签名。

综上，要想在你的E63上顺利安装各种软件，首先，拥有一张证书和与其相对应的签名软件是必不可少的。

塞班论坛（bbs.dospy.com）上提供了对证书的详细说明，申请办法和签名工具的下载。

这里想说一点，就是事实上，证书带给我们的麻烦，并没有想象的那么大，因为软件虽然需要签名，但是并非所有软件都需要用户自己来动手签名，有些手机软件开发厂商，本身是Symbian的合作伙伴，一般Symbian会授予这类开发商相应的认证证书，这类开发商出品的软件，都使用这样的证书进行过签名，所以，手机用户如果直接从其官网下载软件，得到的都是不需要签名的软件。这样的软件有（搜狗拼音输入法，Opera Mini，UCWEB，twibble，尚邮，金山词霸等等知名软件）。

我安装的软件

搜狗拼音输入法——对于使用拼音的用户来说，我想这是一个非装不可的软件了。在我的上一篇文章中其实就提到了，Symbian S60III系统自带的中文输入法实在是差地匪夷所思，而且自带输入法在E63这样的全键盘手机上更是显得格外的难用。搜狗拼音实现了整句输入，高精度的联想，识别等等等等功能，简直堪称完美。有些人可能会更喜欢点讯输入法，但是窃以为，那个输入法在触摸屏上更能大显身手，在全键盘领域，并非搜狗的对手。也有人说，搜狗拼音输入法占用资源太高等等，但是使用E63，这么高性能，这么快速度的手机，你就算用了搜狗拼音，就算它真的占用资源，也是很难被觉察到的，谁叫咱性能好呢。

i-短信（Free-iSMS）——S60III系统上的软件界面，是又一个我不得不批评的东西，只能用“太恶”这两个字来形容。简直到了怎么不人性化，就怎么来的程度了。无论是排版，还是短信管理功能，都是很不实用的。各种不便中，最大的一个，就是短信无法“会话式”浏览，在黑莓上，Gmail里，这都是很普通的功能了。按照会话来组织消息，大家你来我往，思路清晰，而原本的收件箱里，都是错综复杂的交织在一起的，十分混乱。这款软件基本上就是解决了这个问题的。而且，软件是中国人设计的。当然，如果这款软件可以更多的模拟出黑莓的短信操作界面，我会爱它更甚的。

Opera Mini——非常著名的手机浏览器，人性化的操作界面，高压缩率，在手机浏览器市场享有盛名，Opera Mini在移动终端市场的名誉远远高于其在PC上的名誉，不过我认为，无论在哪个领域，这都是一款卓越的浏览器。感兴趣的朋友也可以在自己电脑上试用一下。

twibble——这是来自德国的一款手机上的Twitter客户端软件，不但支持黑莓，也同样能在Symbian 系统上运行。Twitter是一个马上就将拥有1亿用户的网络服务，其现在的形式只能用火爆来形容了，如果您还不知道这是什么，赶快Google之吧，不然您就太过out了。twibble就是在手机上玩Twitter的利器了。S60III上的twibble给我的感觉比在黑莓上的要好，可能过于灵敏的轨迹球，在操作twibble时候反倒要吃点亏了，哈哈。

尚邮或Gmail——不用说，这两款都是收邮件使用的软件，虽然，在上一篇博客中，我将尚邮狠狠批判了一番，事后回味，觉得这个软件并非一无是处，虽然说其非Push Mail的本质是没有什么改观的，不过这款软件本身的界面做的还是比较漂亮的。另外就是，尚邮还推出了几个邮件订阅的服务，非常和我的心意，比如新闻快报，Geek新闻，沪江英语，天气预报等等，都是非常实用的咨询，冲着这几个东西，我想我还会继续使用尚邮的，再给它一次机会。Gmail我想我对它是无可挑剔的了，不过，对于不使用Gmail的朋友来说，可能尚邮更适合您。当然，最好的是您来申请使用Gmail。

柳丁来电——这款软件是我最近刚刚装的，感觉非常不错。是一款类似黑莓之上的来电助手的软件。来电归属地查询，个性化来电界面，防火墙，GPRS流量检测，都是非常的有用。另外还不得不提到就是这款软件是国产的。

小结

若说S60III的软件有数百上千种，我想并不为过的，我上文中列出来的，只是沧海一粟，但是仅仅是这么几个软件，就让我觉得拥有E63的生活是何其的美好。今天就写到这里了，我不太想一次性把所有的软件都给用禁了，还是慢慢发现比较有趣一些，那样，以后，我还可以继续多写一点博客文章，哈哈~~~

我写的这几篇系列文章，并非是手机评测，或者评论，仅仅是我作为一个最普通的E63用户，S60III用户的一点点经验心得，我希望我写的东西能给同样使用S60III的机友们一点点参考，那样就算是没有白写了~~~

上一篇介绍E63的使用体验的文章中，我已经提到了这个东西。但是，事实上，我对其的了解是非常有限，我只是根据心目中的想象，将我现在享受到的服务，认为是Push Mail。而实际上，通过在互联网反复搜索，我还是没有实现对这项服务的深入了解。感觉国内做这个的有好几家公司，包括著名的尚邮，另外就是一些移动运营商和知名度较低的公司，但是我觉得这些公司里，不乏玩弄概念，欺瞒客户的现象。

什么是Push Mail？

Post Office Protocol（邮局协议），就是我们常说的POP3，是互联网上广为使用的邮件投递协议。接收邮件时，用户通过客户端，登录邮件服务器，从服务器上检索新邮件，并下载到客户端查看，而发送邮件之时，却是客户端将邮件直接发送到了目标服务器（也即直接发送到了收件人地址所在的邮件服务器）。以上所描述的方式，就是传统的邮件处理方式，也即与Push Mail相对的Polling Mail。

Push Mail真正与Polling Mail不同的，就是在发送邮件之时，邮件不是到达了目标地址所在的服务器就停止的，而是再进一步地被送到了收件人的客户端之中。听起来，这种处理方式的好处是不言而喻的，最重要的优点，就在于实时性非常的高。

既然这种方式是如此的优秀，为什么没有被广为采用呢？事实上，这是一个历史原因。我们都知道，现在互联网的主要使用的协议还是IPv4，这种协议使得IP地址的数量非常有限，并不能满足给接入网络的每个终端一个地址的需求，现在的方案，是大量的桌面终端用户，接入互联网时，动态地分配其一个IP地址，数量较小的服务器，被分配了固定的IP地址。这种方式，暂时性解决了IP地址不够用的问题，但是同时，也使得每个终端无法享有独一无二的IP地址。回到我们的问题上，这样一来，邮件服务器就无法知道，到底要把邮件投递到哪个地址，于是，只能够放在服务器的存储中，等待客户端主动连接上来查看邮件。

说个题外话，随着互联网的发展，同一时间接入互联网的终端和服务器数量日益增加，IPv4这种动态分配的方式，也开始变得捉襟见肘，IP地址成了日益稀缺的资源，于是乎，IPv6应运而生，这种新的IP协议号称可以给地球上的每一粒沙子都非配一个IP地址，可见其地址数量是何等地庞大，等到IPv6全面使用之时，每个个体（我特意没说是人，被人类管理的动物也包含其中）在出生之时，像得到身份证号码一样得到一个IP地址应该是非常正常的事情。届时，Polling Mail这种方式，也该理所应当地退出历史舞台了吧。

通过手机实现Push Mail

我们都知道，每一台接入通信网络的手机，都有一个唯一的手机号码，这就使得将邮件直接投递到手机上，成为了可能。事实上，很多文章上也提到了，我们所熟知的彩信，其本质就是一种Push Mail，只不过发信人地址和收信人地址都是手机号码，而非邮件地址。当然，可能的事情办起来也并非如此容易，无线通信网络和互联网是两种不同的网络，要从互联网，将邮件穿透网络发送到无线通信网络中，必然无法避开通信运营商这一关。所以，在手机上实现的Push Mail，必须有无线通信运营商的支持。

中国在这个领域起步较晚，所以，刚开始，这样的业务必然资费高昂，但是资费的下降，眼看着就是必然趋势。

我用过的几种手机接收邮件的方案

我用过的使用手机接收邮件的方案非常有限。现在我就放在一起来说说：

手机浏览器——手机通过GPRS上网，从Web页面直接收取。这种方式，就和普通的上网收邮件是一码事。想起来了去收一下，你需要承担的费用只是流量费。当然，这个全然没有实时性可言了，就是你自己想起来，收一下而已。属于彻底的Polling Mail方式。

Gmail客户端——这是智能手机上的一个应用程序，目前在绝大多数智能手机平台上可用。该程序运行于系统后台，每隔固定的时间，就通过GPRS网络访问Gmail服务器，从服务器上下载新邮件。使用Gmail客户端，你需要负担的费用也只有流量费，当然这个程序一直运行在系统的后台，会使手机的电量迅速地被消耗，这也是你所必须承担的，经常给手机充电。通过这个客户端，基本实现了实施查收邮件，你可以把检索服务器的时间间隔设置成3分钟，甚至更短，几乎就是实时，当然检查服务器越频繁，流量消耗越多，电量消耗也越多。这种方式还是属于Polling Mail。

尚邮客户端——尚邮是我在使用了黑莓后才听说的，不知道为什么，尚邮一直吹嘘自己是Push Mail，不过根据我的理解（见上面），至少其免费版本，绝对不是Push Mail。尚邮的免费版本，和Gmail客户端的性质并没有区别。几乎一模一样。甚至根本赶不上Gmail。使用尚邮免费版本，你需要承担的代价和使用Gmail客户端完全相同。区别就是Gmail从来没吹嘘自己是Push Mail，而这个牛皮，尚邮吹了。其原理，从外表上看，也是Polling Mail，如果退出了尚邮客户端，你就无法收到邮件了。所以，你根本无法知道，开着尚邮客户端，邮件到底是被Push过来的，还是客户端自己去刷新出来的（根据Push的原理，尚邮完全没有和手机号码关联，可以推断，邮件肯定不是Push过来的）。当然，尚邮也推出了很多价格不菲的收费服务，也一概说自己是Push Mail，我没有用过，不敢妄加评论他们到底是不是真正的Push Mail，从情感上，我还是相信尚邮没有这么无耻的。

139邮箱——139邮箱是中国移动推出的一项业务，我所在的浙江移动，有这项业务，其他地区不详。139邮箱绝大部分功能和普通电子邮箱一样，区别可能就是这款邮箱带有Push Mail业务。我使用的免费版本，带有邮件到达提醒。在邮件到达的第一时间，发送一条手机短信给用户，告知邮件到达。发送的格式有多种版本。有只发送邮件标题的，发送70字标准短信的，发送350字短信的，和发送彩信的几种方式，如果使用彩信的话，基本上就把邮件完整地发送到手机上了。这种方式，不需要在手机后台开任何程序，不会浪费电，而你真的会在邮件到达的第一时间看到邮件的内容。根据我的理解，这个就是Push Mail了。因为是直接抵达客户端的，而不是你主动去收取的。这个邮箱还带有两个收费服务，叫做Push Mail5元版和20元版，区别是邮箱容量和附件大小。不过收费服务也需要安装客户端软件，我没有用过，不过在网上看到有人用，说是就算不启动客户端软件，还是可以收到邮件。真要是这样，那么邮件也是被Push过来的了。

要是这样的话，就真的意味着在中国，用上Push Mail业务，只要支付每月少于20元的平民价格了，而非黑莓的那个300+的天价。

好，今天就写到这里了，我自己理解的内容，和我自己试用过的方案都在上面了，欢迎纠正我的错误和给我推荐更好的方案。

没有继续选用黑莓是有原因的，8900那典雅精致的外观，强大的功能，还有价格等诸多其他因素，使得我在黑莓的诸多型号中，对其情有独钟。但是，8900也有几个重要的缺点，一是GPRS上网问题，除了内嵌浏览器可以总是正常启动外，其他第三方程序包括twibble，fetion，QQ，Opera统统遭遇了上网问题。后来得知是由于Service Book作祟，但是仍旧没有求得完美地解决方案。以前，用过尚邮的Service Book暂时解决了上网问题，但是不久后又复发了。前段日子，刚在某圈内著名博客上看到了新的Service Book解决方案，还没来得及试用，89已然仙去。悲乎悲哉~

选中E63，就很简单了，起决定因素的就是其高超的性价比。E71的优越表现和低廉价格，使得它理所应当地成为了街机，那么作为其精简版的E63，除了少了几个我不需要的功能外，再加上其更加低廉的价格，基本上就是完美的同义词。最后一个原因，我本人根本就是Nokia Fan，从6610，6280一直上来，竟然没有用过诺记的智能机，在等待下一款完美的黑莓到来的间歇，就让我来体验一下Nokia的智能机吧。

初上手，觉得E63就是中规中矩，简洁大方，外观基本无可挑剔，可惜，比较8900的华丽，还是有相当的差距，毕竟价格只有后者的一半，也就不敢奢求太多了。

用了这段日子下来，手感方面我始终是不能满意的。基本上键盘的触感，软硬程度，力反馈，都和8900差太远了。另一方面，界面上没有轨迹球，也没有滚轮，全靠上下左右四个方向键，这实在是让我很难适应，经常气急败坏地狂按方向键，也没法迅速到达想要的位置。320*240的屏幕分辨率，也不可以和480*360的8900相提并论，不过这个适应起来还是比较快的。

系统方面，有好有坏吧。E63使用的是Symbian S60 v3，出来很长时间了，相当地成熟，相较8900的OS 4.6，有更多的应用软件，而且软件也都比较成熟。另外，这个系统里面的GPRS上网啊，WiFi啊，蓝牙啊都是比较正统的，功能正常到不行，这点是OS 4.6不能比的，如我前面所述的。如果说有缺点，就是装软件偶尔要用到那个该死的证书，这是相当地让人困扰啊。好在各大软件厂商都对Symbian 系统有很好的支持，著名的应用全都是签过名的，不然真的是要被这个东西烦死了。

非常让我惊讶的一点是E63自带的中文输入竟然也是如此之烂，简直跟OS 4.6里的原生中文输入法差不多，甚至还有不及，绝对落后于S40第三版的输入法。真搞不懂，机器智能了，自带的输入法反倒更烂了。不过，这问题几乎不算问题，加装了搜狗拼音1.3后，输入起来那是相当地流畅，全键盘的优势发挥得淋漓尽致，其表现肯定比8900搭配点讯输入法要强上数倍了。当然，如果你不喜欢搜狗，Symbian下面也是有全键盘的点讯输入法，而且还有五笔输入法，选择极多，这一点黑莓望尘莫及。

对电子邮件系统，我本来是没有任何期待的，谁知道，阴差阳错的，我竟然用上了真正的Push Mail。我所使用的浙江移动，推出了一个139邮箱，该邮箱就带有真正的Push Mail服务。有两套方案，月费是5元或者10元。当然，我都没有选用。我只用了一个免费的功能，就是新邮件短信提醒。对我而言，这个350字的免费提醒，就是等同于Push Mail了。我开启了Gmail的自动转发，任何邮件都直接转发到139邮箱，然后，手机上就会第一时间得到邮件到达提醒。然后，悠哉游哉地用Gmail客户端处理一下，虽不是彻底地Push Mail，也近乎完美了。

短信管理界面本来是非常差的，不过装了一个“i短信”，基本上现在也是按照黑莓或者说iPhone的样式，按照会话来组织信息，一键即现也得到了实现。

目前，还有很多功能我都还没有用上，还在慢慢地适应和体验中。我想说的是Symbian系统还是相当优秀的，也难怪那么多人会喜欢使用了。以后如果有什么新奇的发现或者应用，我还会继续发文。

1. Special copy/paste

将编辑器里的内容拷贝成带有格式信息的内容（HTML/CSS），以便拷贝到blog或者wiki中。

2. Copy and Paste History

像Word那样记住剪贴板历史。

3. AutoSave Module

可以帮助你克服习惯性按下Ctrl+S的恶习。

4. Export as Archive

可以将选中的文件夹输出成zip文件包。

5. Java Go to Implementation

可以直接跳转到所有实现了该接口方法/抽象方法的具体实现方法。（绕死了。）

6. UML

NetBeans画的UML图很漂亮的。

其实还有很多插件的，欢迎大家推荐给我几个，嘿嘿……

概念阐述

Template

Template的中文意思就是模板。在WordPress中，数据库里存储的一大堆文章也好、评论也好、链接也好，会按照一定的页面布局、排版形式，展现出来。这个“一定的页面布局、排版形式”，就是一个模板。比如，您的blog主页，使用的就是主页模板（home.php或者index.php），您的日志页面，使用的就是单页模板（single.php），等等。

模板都是由有经验的平面设计师和前台工程师所设计，首先由平面设计师绘制版面，然后由前台工程师编码成php、css和js。对于WordPress这样的开源产品，也有着大量的爱好者，自己身兼二职，独立完成模板制作。主页模板（home.php）、日志模板（single.php）、页面模板（page.php）等等这一大堆模板（最少只需要一个index.php，多的多达13个如hybrid这类的），有着统一的风格，他们往往由同一人设计，并且打包在一起发布。这个打好的包，我们称之为主题（Theme）。

Template Tag

Template Tag的中文翻译是模板标签。（就我个人来看，这个翻译是很糟糕的。至少我一眼看去，不明白这个东西是干啥用的。不过大家貌似都这么叫，所以，我也这么叫。）模板标签的本质，是一个php函数，这一类php函数有一个共通的特点，就是它们一定会在页面上显示一些数据（如评论，日志，链接，任何数据库里的数据）。为了便于记忆，您可以这么想，在php文件中，模板标签，就是一个标记，在最后要给读者展示的页面中，这样的标记会被替换成对应的数据。一个模板就好像是一张完型填空的考卷，模板标签，就好比那一个个横线空格。

模板标签出现在一个模板中，那么该标签代表的那部分数据，就会出现在模板的那个位置。

用法指南

使用模板标签，是一件非常容易，又非常困难的事情。

有多容易？好多人，一上手，就会用了，都不需要学。他们定制自己的WP主题，并且乐此不疲，他们把自己的行为称作DIY。

有多困难？上述那些人里，一大半都不知道什么是真正的模板标签，只知道“那东西，写在那里，就会出现我要的”，以至于他们往往无法正确、全面、自由地使用模板标签，甚至错误地使用模板标签。

到底应该如何使用？

第一，有明确的文档说明此函数为模板标签，这个函数才是模板标签，否则，不一定是。官方文档（去看看吧）里有大量的标签可用，甚至有些插件，通过增加模板标签，来扩充WordPress的功能，典型的如WP Kit CN（去看看它的文档）。

第二，知道了哪些东西是标签，还要明白标签的使用位置。有些标签，随便写在哪里都OK，另一些标签，只能出现在特定的地方（The Loop内部）。一般，没有特别说明只能用于The Loop内部的标签，就随处可用。那个神秘的The Loop，我们后面来解释，这里先跳过。

第三，标签的本质是函数，调用函数就需要传递参数。一个函数调用长得像这个样子：

i_am_a_function(arguments);

我知道，很多人使用模板标签，都这样写，i_am_a_function();，后面是一对空的小括号。括号里是传递参数用的，但是一般为什么不传也可以？因为，这个标签的设计者，为这个标签指定了默认的参数，“如果没人告诉我，该怎么做，那么，我按照预先设定的方式工作。”模板标签如是说。所以，亲爱的读者，如果您希望模板标签按照您的要求工作，请您告诉它，应该怎么做。

参数的用法

模板标签的参数，有多种形态。这种混乱的局面，一方面是WordPress官方的编码规范没有指定造成；另一方面，各类插件开发者的背景习惯造成（有些人是C++/Java派系程序员，有些是PHP派系程序员）。

常见风格1

wp_list_bookmarks('title_li=&categorize=0');

这个是WordPress标准模板标签，括号里面的内容，是一个字符串，就是所谓的参数，这种风格，我们视其为PHP派系程序员所为，另外，整个WP内部提供的模板标签，基本都是这种形态，我个人视其为事实上的标准形态。推荐插件作者都这么写。

对于亲爱的读者您，我来简单解释一下。上述例子中，是一个显示友情链接的标签，其参数字串是很有规律的，以&符号分割，第一段title_li=，这个串指定了链接分类名称，=号后面什么都没有，代表不显示名称。第二段，categorize=0，代表所有友情链接不按照其类分类显示，而是混在一起显示。

常见风格2

get_recent_comments(5, '<li> ', '</li>');

上述模板标签来自桑葚出品的中文WordPress工具箱。这种形态，我们视其为C++/Java派系程序员。这个模板标签作用是显示最近评论列表。第一个参数，表示显示数量，5条，第二个参数表明在每条前面加一个<li>，第三个表示每条后面加一个</li>，如此这般，可以使每条评论成为一个HTML里的List Item，也即列表项。

常见风格3

$args = array(
"number" => 10,
"length" => 30,
"skipuser" => 'Charles'
);
wkc_recent_comments($args);

上述模板标签来自本人写的WP Kit CN。这种形态，是常见风格1的变种。可以和风格1互换。所以，也是PHP派系的。这种调用方式，首先构造一个参数数组，然后把数组传递给标签。条理清楚，含义明确，书写规范。也是本人所倾向使用的标准形式。上述调用，可以写成：

wkc_recent_comments('number=10&length=30&skipuser=Charles');

代表显示10条评论，每条评论30个字，不显示Charles发表的评论。

参数说明

到这里，您可能会说了，“我怎么知道应该用那个参数？参数的名字是啥？”，OK，这个问题有两个地方可以找到答案。

第一，文档，上文给出过WP文档所在地，带有超链接的，可以点进去看，一般都带有说明，一共有几个参数，每个参数设定格式，有效数值范围等等。

第二，源代码，很多模板标签没有给出文档，那么只有一个地方可以看，即源代码。源代码之下，了无秘密。“我没有能力看源代码！”，那么，很抱歉，您可能还不具备使用不带文档的模板标签的能力，请不要去使用它。

一般，如果一个模板标签不带有文档有这么几个原因。第一，该标签原作者不推荐用；第二，实验产品，不推广使用；第三，作者超级懒惰，懒得写文档（狂晕，但确实如此，比如我曾经就这样）。

总结

亲爱的读者，模板标签，说难不难，说易不易。要想正确使用，还是需要下一番功夫，阅读文档。想要挑战一下的，或者您真的是一个DIY爱好者，请您一定要阅读源代码。那样，您肯定可以看透每个模板标签的秘密，成为DIY界的一代大侠，用上人人羡慕的，“与众不同”的主题。

谢谢！

好了，牢骚发完了，想想就玩玩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功能一开始也是相当地烂，后来也渐渐改好了。我想评论部分也会如此的。

Different Posts per Page的管理页面截图

让不同的页面，显示的帖子数不同。

WordPress博客支持设定每个页面显示的日志数量，但是这个数量是一个统一值，比如我设定成10，则我的首页显示10篇日志，归档页面也显示10篇日志。对于我这样的人来说，这个功能还不够强大。

我希望我的首页显示的帖子数或者说文章数少一些，这样有几个好处，第一，首页显示的日志少，那么首页就会比较短，然后首页的尺寸就会比较小，下载速度就会非常快，第二，我最近更新频率比较低，如果首页显示的帖子比较少，那么我更新一篇文章，相对来说，整个页面变化就比较大。

另一方面，我又希望我的归档页面显示的日志数量能够多一些，我想，朋友们应该有这种感觉，比如使用google的时候，结果页面一页只有10条，老得不停地翻页，如果有50条，可能在第一页就可以找到要的东西。那么我想，如果一个读者如果进入到我的归档页面，那么他可能真的要找东西了，所以，应该尽可能多显示一些，让他快点找到他要的东西。当然，如果数量太多，页面就会变得很长，要用滚动条滚动半天，我的解决办法是用jQuery把归档页面的所有帖子给折叠起来，只漏个标题出来。这样页面就短了。（以后我可能会写篇文章介绍这个方法）

Different Posts per Page插件，就是能够实现我说的功能的插件，不但可以随意的指定不同页面的日志数量（分类页面可以指定不同分类的显示日志数量），还可指定排序方式（按日期升序或者降序）。使用非常简便。不过，值得一提，该插件需要注册，当然注册是免费的。如果讨厌注册步骤，本文最后的链接是我修改的版本，不需要注册。当然，我还是推荐使用注册版本，因为可以使用自动插件升级。

插件页面 | 官方插件目录

http://www.box.net/shared/of0hh10jvr

呵呵，已经有两位朋友对我添加了Contact Form的举动表示不理解，或者是认为没有必要了。stephen认为，他提供了专门的留言板，并且在那里公布了他的email，这个功能不是那么有必要了。另一位匿名的朋友认为，已经有了日志后面留言的功能，完全没有必要添加一个Contact Form了。

既然这样，我决定写一篇文章谈谈我自己的想法，我为什么要添加Contact Form联系表单。

我为什么要添加联系表单呢？

更醒目便捷地沟通方式

Contact Form以menu tab的形式出现在站点导航菜单上，更方便我的访客发现我的联系方式。他们如果想要发信给我，只需要填个表单即可，完全不必到处搜索我的email地址的所在。我的邮箱的后缀是foxmail.com，对于大多数人来说，我想这不是一个为人熟知的域名，那么就算真的找到了我的邮箱，给这样没听说过的域名发送邮件，很有可能也是一件让人充满疑虑的事情。

更加直接地投递

我的博客设定了将访客的留言自动发送到我的电子邮箱，也即一般的留言，我也会在邮箱里看到。但是，如果，有一天我一天会收到100条以上的留言，我想我一定会取消这个功能的，那一定会烦死的。就好像我在垃圾留言最猖獗的那段日子取消了评论待审阅的邮件通知一样。使用Contact Form，访客的话会直接送到我邮箱，而使用评论，不一定可以在第一时间让我看到。

消除访客对他们想表达的对内容的疑虑

当然，每篇日志我一般都会允许读者评论。但是，那是评论，Comment，就是让人发表看法的地方。如果访客只是想跟我表达一些观点，但是并非跟某篇特定的文章有关，那么在没有Contact Form的情况下，他该选择在哪篇文章下面留言给我呢？或许，对于有些人类说，他会毫不犹豫，胡乱找一篇文章在后面发表他的跟文章无关的意见。但是，我相信，还是会有很多像我这样的评论者，会觉得在一篇文章下面发表完全无关的评论是一件很痛苦的事情，仅仅因为这个事情不符合逻辑。

如果有个专用的留言板，我想事情会好办得多，因为那里是一个纯粹的留言板，毫无针对性，当然也可以畅所欲言了。不过，这种留言板，就像是一种公开场合一样，你可以想象一个站满人的大厅，如果让你用所有人都可以听得到的声音说话，你会否随便开口呢？想想这么几种情况，访客想问我问题，但是他可能觉得自己真的很菜鸟，问的问题非常stupid；某个朋友使用我的插件出了问题，有很多很长的错误信息想让我看，但是这些错误信息一方面很不美观，另一方面可能会暴露他的隐私；某个朋友有很好的插件创意，希望我能帮他实现，他不想这个idea被更多的人知道；某个女孩子非常仰慕我，想向我表白（我胡乱意淫下），总之，有很多情况下，不便于公开说话的。

更加便于管理

所有使用Contact Form发送的邮件，都会以一种非常统一标准的格式发送到我的邮箱里。主题里都会写着发送者的姓名，邮件主要内容，发送日期。正文的格式也都非常地一致，而且邮件尾一般不会带有一句广告语。这样的话，对于我来说，管理起来是非常方便的。光看着就非常清爽。

结论

综上，使用Contact Form，有着非常多的好处。我能比较清晰表述的，也是最直接说服我去添加这个功能的理由，我已经罗列在上面了，当然，还有许多的好处，我想，我可以把这个空间留给大家。欢迎大家反驳我，或者补充我的观点。谢谢！

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

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

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

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

为何使用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搜索的详细步骤，包括申请，修改代码，等等，并且给出了代码范例。可操作性很强。

WordPress自带的这些js类库有个弊端，就是基本上都没有经过minify和zip（这两部操作的作用，就是将js代码的体积，尽可能减到最小，以加快下载速度），所以引用WordPress自己的js类库，往往会浪费很多流量（比如，没有zip过的jquery有30KB，prototype有122KB，而压缩过后，jquery只有17KB，prototype只有28KB）。

我是否使用了类库？

WordPress是一个灵活的系统，用户可以通过插件扩展系统的功能，所以，一个博客上是否使用了某个类库，取决于你博客用到的所有的插件对类库的使用情况。如果你想看看自己到底使用了哪些，你可以用一个简便的办法，就是查看源文件。

看上面的代码，是我模板中的一段代码，类似这个样子的就是对类库的引用了。这是我的本地调试系统，使用的是wp2.5.1，引用到了jQuery类库，版本1.2.3。

如果你看到了类似“xxxxxxxxxxxxxwp-includesjsxxxxxxxx?ver=xxxxxx”的字符串，那么，你的博客里，调用了类库。

使用Google AJAX Libraries API

什么是Google AJAX Libraries API（GALA）？使用它有什么好处？简单来说，Google是个很牛X的公司，很乐意做好事，它专门优化了这些类库，包括代码精简，压缩，然后用高性能地服务器来Host这些类库，供用到的网站调用，帮助这些网站节省流量。我爱水煮鱼写了个小短文，介绍过这个，大家可以看看（点这里）。Google为什么做这种事情？好吧，这个问题，我不知道。

怎样用GALA来替换WordPress自带的类库？

关于这一点，首先我想说说WordPress对于引用脚本的一些机制，那就是scripts loader。这是个什么东西呢？一句话：对于博客使用到的所有脚本，进行统一的管理的一个装置。这个装置是怎么管理的呢？首先，所有的脚本登记注册，包括名称，路径，版本号，依赖关系，一一详细记录。然后，是对脚本的调用，通过这套系统来调用。最后，由系统负责把所有需要用到的脚本，无重复的，满足依赖关系的，满足前后顺序的，有条不紊的加入到你的最终的博客页面里面。怎么样？是不是非常酷？不过呢，总是有“不过”，这种秩序高度依赖模板作者和插件作者的自觉性。

好吧，我们的方法不得不建立在所有的模板作者和插件作者都自觉使用scripts loader系统的基础上。在这种情况下，一个模板或者插件使用到某个类库，会使用wp_enqueue_script函数来调用需要的类库，使用这个方法，一般不会直接指明类库的路径，只是说明类库的版本号和依赖关系（因为，WP默认就会给所有wp-includes/js目录下的类库进行登记register）。

发现又废了很多话，到这里，我们的替换方法，已经呼之欲出了，因为所有的类库引用都是对已登记的类库的调用（建立在我的假设之上），所以，我如果想要替换，那么只要替换登记在册的那个名单就OK了，完全跳过了去修改每个有可能引用到类库的插件这种繁琐的事情。而且，WordPress确实提供了能够替换那个名单的方法。使用wp_deregister_script可以注销一个脚本，然后使用wp_register_script可以重新注册一个脚本。用这个办法，我们可以把wp自己注册的脚本给注销掉，然后换成GALA的，重新注册，就OK了。

根据WordPress的源代码显示，所有类库的引用，是在最后页面生成的时候才真正进行的，准确一点并且专业一点来说，是在wp_head这个action发生的时候，对类库的引用才通过wp_print_scripts函数写入到页面里面。我们的替换动作只要在此之前完成就OK，所以，我们把替换这件事情，写到functions.php里面，当然，更好的做法，是使用一个单独的插件里。

具体的写法，我曾经在侠姐的文章里见过，大家可以去看看，我就不想进行重复劳动了。《wordpress里js文件的调用》from 轶侠的网上小窝

有没有学习写插件的小朋友写个干这个事情的插件呢？亲爱的读者，如果你写了，请告诉我，我会把你的作品列在下面的。

Updated:

经由侠姐提出，如果直接替换掉WP自带的js类库可能会在后台造成冲突而导致某些功能失灵（比如Simple Tags的标签推荐功能，详情可见讨论），不得不在使用的做出一定的修正。

通过is_admin()标签，可以将前后台区别对待。但是这种情况还不能涵盖所有的例外，如果某个插件正好引用了prototype或者jquery，并且正好利用了WP对齐进行的无冲突修正，那么以上方法可能导致部分功能失灵。有经验的用户可以酌情使用。

Updated2：

经小墨提醒，已经找到了一个这样的插件的实例了。我看了代码，是利用了两个hook，一个是我说过的wp_print_script，这个hook用来探测jQuery和prototype是否同时存在，然后解决冲突问题，另一个是script_loader_src，用来替换里面的src地址，并指向到google提供的js库。不过，我个人觉得，这个方法很可能还是不能完美解决后台的类库冲突问题，但是我没有验证过。

插件主页：

http://blog.clearskys.net/2008/05/28/google-ajax-libraries-api-plugin/

TrackBack最早是MovableType上的一个小功能。可以说就是这个小功能在blog界却掀起了一场革命。

TrackBack为将全世界无数个blog连接起来的功能。例如，当你读了某个网站的文章，想对此写下自己的感想。这个时候利用网站准备的讨论功能进行投稿是很最常见的做法。但这样只是把自己的评论意见写下来向别人的网站投稿，而你自己手里却什么也没留下。

TrackBack 则与之有很大的区别。可以把评论写到自己网站上。然后向刊载原始文章的服务器发送该网页的URL及标题、部分正文、网站名称等信息（注）。尽管这一过程只是称之为“发送TrackBackPing”，但通过这种办法，在原始文章的地方就留下了你的评论的URL、标题等部分信息。当然别人也可以向原始文章发送TrackBack Ping，所以在原始文章中就将包括你的TrackBack Ping在内的所有评论都记录了下来。

此外，如果你在自己网站上也设置了TrackBack Ping功能的话，那么谁都可以通过TrackBack Ping来发表针对你的意见了。这样，多家网站就通过相关话题而联接起来。各种评论在因特网上就像网眼一样联接起来。这样就创造出了与日记网站完全不同的文化。

注：发送地址采用原始文章指定的URL，这一URL就称为“TrackBack Ping URL”。最后的“128”为原始文章的专用数字，称为“TrackBack ID”。另外，TrackBack的技术标准刊登在“LowLife.jp”的blog网站上。

以上一段文字，讲解了Trackback的含义，我是在一个叫做“雨吁”的博客上抄过来的，我之所以会关注这个问题，是因为我今天在调整自己模板的comments.php。我也想把留言和pingback区分开来，而这个时候，我发现，除了留言和pingback，还有一种trackback。这就让我有些糊涂了。所以，就研究了一下，这一研究，我倒觉得这个问题原来非常地有趣。

我现在对pingback、trackback和comment建立起这么一种印象：

comment是一个读者对你的这篇文章有一点点想法，或者同意，或者不同意，发表下意见。

trackback是一个读者对你的话题有深层次的理解和独到地看法，并且自己也有相当的兴趣，自己撰写相关文章，并通过trackback的方式通知原作者。

pingback则是某一个作者（注意，角色变了）在写作一篇文章的时候，碰巧援引了你的观点，文章中包含了你的链接，你会收到pingback的通知。

综上，我个人认为，对于一篇博客文章来说，最有价值的反馈，应该是trackback，这是一种话题的展开，使得同一个话题得以链接在一起。而comment则是文章作者和读者的一种简单互动，能够增加博客的亲和力。pingback则表明了一篇博客文章的价值，这个就好比你发表了一篇paper，从某种程度来说，这篇paper的价值和其被引用数是成正比的。

其实，WordPress对于这三者有着相当好的理解，在模板标签中，也有着足够的技术上的支持。只是，我们作为博客作者，模板作者，插件作者，往往把这个地方给忽略了。期待着在将来看到WordPress这个博客圈子，能够率先在这个领域做出示范，进而带动整个博客圈子完善这套系统。那个时候，博客的世界应该更有趣吧！

嘿嘿，我的一点感想就发表到这里了，如果没有问题，此文应该给原作者自动发送一个pingback，因为我加了他链接，而我还会额外给他发一个trackback，以表示我对此问题发表了自己的看法。我这么做也希望能够亲身实践一下这个有趣的功能，嘿嘿…………

经历了几个版本的演化后，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的后台也可以设定

美味书签（del.icio.us）的成功在互联网上掀起了一场社会化书签的旋风，自此，社会化书签成为了社会化网络服务大家族中非常重要的一员。

社会化书签允许人们使用Web服务来保存自己的书签，而不是向传统的那样保存在IE收藏夹。我可以在这里做个寓言，不久的将来，IE或者其他浏览器的新版本，将不再带有本地书签功能了。

社会化书签允许您通过网络访问您的收藏，在互联网普及程度如此之高的今天，这就意味着您真的可以随时随地地翻阅您的收藏。

社会化书签的另一个重要的意义就是分享。您的收藏可以通过社会化书签的方式实现和朋友，亲人，或者任何人进行分享。

综上，在您的博客中添加社会化书签，无论是出于访客友好的考虑，还是出于提高流量的考虑，甚至出于SEO的考虑，都是必然选择。

这里，介绍两个我用过的，觉得非常好的，适合WordPress使用的社会化书签插件：

Blog It 2-这款插件是著名的CoolCode.cn出品的。其最大的特色是全。用图片显示，包括抓虾、del.icio.us，Google，Yahoo，Windows Live Bookmarks, Digg，365key，baidu搜藏，新浪Vivi，和讯网摘，Spurl，Wists，Simpy，Newsvine，Blinklist，Furl，Reddit，Fark IP，Blogmarks，Smarking，Magnolia，Segnalo，BumpZee。此外还有些热心的网友补充了饭否，QQ等。使用这个插件，会在您的帖子中，您指定的位置，出现一行漂亮的小图标。这款插件内的服务无所不包，推荐那些比较国际化的博客一定要使用。

17fav Bookmark&Share-这款插件是WordPress中文团队的Denis和LiuYang开发。其特点是比较本地化，对于纯中文的博客，一般的读者也是中国人，针对这个特点，其收录服务有了一定的删减，安装后，会在帖子下面出现一个按钮，悬浮鼠标于其上，会弹出一个面板，可以将帖子收藏到国内常见的社会化书签服务中。这个插件的另一个特色是可以在您的Feed中也添加这个按钮，在用户友好方面，这款插件考虑得更加周到一点。

赶快行动起来，给您的博客添加订阅到社会化书签吧~~

补充一点：17fav Bookmark&Share这个插件有些问题，其引用图标的时候，其根目录被设定为博客主页的URL（应该是WordPress的安装目录），但是很多网站，例如本站，WordPress的安装目录和主页的目录不是同一个，这就会导致无法显示按钮。

修正方法：

打开bookmark-share/bookmark-share.php，找到

将其中的get_bloginfo(’home’)都改为get_bloginfo(’wpurl’)即可。其实已经有用户提出过这个问题了，但是其作者没有将其改正，盼望此插件的下一个版本能修正这个问题。

实际上，我大错特错了。我用的是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

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

不过，我们运气非常好，WordPress选用的数据库是久经考验，功能强大的MySQL。而为了防止服务器出现故障，造成数据丢失，我们只有通过不断地备份自己的数据来弥补WordPress在这方面的不足。

备份方法有很多。

第一招，WP-DBManager，这无疑是最好的选择了，非常的方便，通过该插件，可以优化、修复、备份、恢复数据库，可以有效管理备份文件，删除空表（插件留下的遗物）。说了这么多，最关键的好处是自动备份和自动优化。按照自定义的时间表把数据库备份文件发送到你的email。本站网友stephen，花生，都曾得益与此插件的功能呢。 但是呢，我要说，不是所有人都有福气使用这个插件的，这个插件需要MYSQL Dump和passthru()、system()、exec()等PHP函数的支持。（system函数和exec函数可以执行shell命令，是非常强大的php函数，强大往往是双刃剑，也就意味对安全有一定的威胁，所以有些服务器提供商会禁止调用这样的函数，一了百了，干脆连门都堵了，也省得设立什么门禁了，麻烦，盘古就是这么做的，所以我是无福之人了~~）如果你自己不知道服务器支持不支持，那么装上一试便知，如果它告诉你不能用，那就是不支持了。

第二招，使用PHPMyAdmin，这个就是专门的管理MySQL的一个PHP界面，非常强大，非常不友好（是的，我没写错，真的很不友好，至少我用不来），如何使用这个东西做备份呢，请看这里，看图识字吧XDJM们，我暂时还比较懒，不想去翻译这个文章，遗憾的是文档中文计划里面也没有翻译的，如果你不懂英文，那么请跳过这段吧。通过phpmyadmin，可以将数据备份成一个sql文件，什么是sql文件呢，就是一系列的sql命令，通过这些命令，可以活生生建立一个数据库，而且还是塞满了数据的，猛吧。一半虚拟主机提供商都会提供这个phpmyadmin比较常见的后台如cPanel和DirectAdmin都有这个东西的。

第三招，我最喜欢的其实是这招，就是WP后台“管理”里面的“导出”。这个功能可以将文件导出成xml格式，xml格式可是一个非常美丽的格式，导出的东西用途也非常多，我们仅提一下其备份的用途吧。这个功能随着WP的不断升级已经日趋完善了，今天我实验了一下，竟然连tag也可以完美地导出了（以前导出再导入，tag会全变成数字，非常恶心，现在没有这个问题了），导出的文件包含所有的文章，分类，评论，标签，页面等等一应俱全，然后再用导入，就可以完全重新恢复wordpress的数据了。（似乎没法导出插件生成的数据，比如很多模板和插件都会在数据库里面记下些东西的，如果用这个备份，就都没法保留了，所以这是个只关心数据的备份方法）此方法最大的好处是只通过wp后台就可以实现，不需要任何额外的手段，对于很多BSP上的WordPress博客来说，这是备份数据的很好方法，比如yo2，七十二松，wordpress.com，wordpress.com.cn等等，都是WordPress博客提供商。不过，这个方法的局限性也是非常大的，wordpress导入功能限制了文件的尺寸为2M，也即超过了，就无法导入，如果你的博客字很多的话，可能这个方法备份的文件没法完全导入（大概在100万字那个数量级的吧）。不过，如果按照作者来导出，可以把导出文件变小，今天在Weblog Tools Collection看到，已经有人按耐不住要写一个插件，可以允许按照天导出，按照分类导出等等功能了，那样，基本就无敌了，等着吧大家。

备份，绝对是安全，而且无敌的招数，一旦出错，恢复即可。

我在恢复的方面，只有一点心得（也是从某个网友那里看来的，就在最近，忘了是谁，不好意思，^_^），就是有时候，WordPress不知道出于什么原因，就会运转不正常，我以前碰到过的，比如首页莫名其妙老是运行超时，这个时候，我们往往会重装。重装的时候有个小技巧，大家如果碰到了可以试一试（前提是你有很完备的备份，否则出错了，你就没救了），就是在重装WP，其实不用重新上传，也不用删掉数据库重建，只要把wp_options表删掉就可以了，wp_users表也是可以删掉的，如果没删掉，重装的wordpress就不会给admin生成密码，保留原来密码。期间产生的Warning不要害怕，影响不大。这样的好处是非常省时间，几乎20s就可以完成了（说明毁灭比创造简单），如果效果不佳，再用前文说的备份恢复也不迟。

上图就是我用的主题Leopard Admin了，就是把后台模拟成苹果风格的。这款插件主要原理是使用自定义的CSS样式表效果去覆盖原来样式表产生的效果。不会对WordPress源文件有任何的改动。只要简单的在后台启用插件即可。这仅仅是一个样式。

（不过，这个样式只能在Firefox下面才能看到，在IE下面会被自动屏蔽:( 看来还是有了一个理由让我去用FFX了~）

插件主页 WordPress Plugins Directory页面

下载地址：http://downloads.wordpress.org/plugin/leopard-admin.1.02.zip

发现一个事实，就是我的博客实际上是很不受欢迎的，访问人数很少，唉~~~

不过使用计数器一类的工具的兴趣仍旧没有减少。只是现在不像以前那么张扬了，再也不在醒目的地方放多少人访问呢了，哈哈，那是自取其辱嘛~~

介绍一下我一路用过来的一些工具吧，一开始，是各种国外网站提供的小工具，免费的，只是简单的显示一个数字，有的时候，我自己写博客，想看看效果，一天就会使计数器多上十几二十次的。实在是没有意思，根本没有统计的感觉，好像都是我自己点的一样。

后来开始用51.la，觉得相当好，当然啦，现在看来，51.la不差，不过后来用了cnzz后觉得，cnzz更加好，不愧是专门为站长考虑的设计，尤其是我觉得能看到很多信息很好玩，比如多少ip访问了，都来自哪些城市啊，访问了哪些页面啊，回访次数啊等等。尤其有意思的是，还可以看到搜索引擎的关键字，比如别人是通过搜索那些关键字来到的你的页面，这种东西本身就很好玩，数据有什么价值，我也就懒得追究了。

再后来，有了google analytics，就更加有意思了。不过我觉得google analytics就太专业了，项目繁多，不过googel analytics真的是很强大，我还是在网站里面添加了，用途嘛，也懒得钻研，说不定以后会从事这个工作，那时候再说吧。

cnzz是我比较推荐的，我的每个页面最底下就有链接，写着“站长统计”的链接就是。感兴趣去看看吧，就是本站的统计。

接下来，就来谈谈我的体会。

可选摘要这一栏，是搭配着“设置-->输出-->Feed（联合供稿）-->日志内容显示”这个选项来设置的。如果你设置了“摘要”，那么在你博客的Feed中，将会显示摘要。设置了“全文”，那么Feed中就输出全文（并非绝对如此，有一个前提的，后面会说）。

对于Feed来说，我个人觉得是给别人提供方便的，读者订阅你的Feed，就是表示对你的博客内容比较关心，而对别的并不是那么关心，对于一个个人博客，一般来说，不会产生海量的文章，更加不会产生门类繁杂的文章，所以，如果个人博客，只输出摘要的话，那么你的Feed就会变成完全没有价值的Feed，因为到时候，读者还是需要点击一下超链接，才能到你的页面上看文章，那完全没有必要订阅的。所以，一般来说，建议能在Feed中输出全文。

那么这么一来，“可选摘要”是不是就没有用了？并非如此。

在WordPress博客中，按照给类方法的存档页面中，会以摘要的形式给出。比如月存档页面，分类文章页面，tag页面等等。这个时候，如果你的文章在写作的时候填写了“可选摘要”，那么就会使用你写的可选摘要。否则，就会自动截取你文章的前面一段，作为摘要。

但是，大家都知道，WordPress不是中国人写的，所以其内部的摘要函数，在设计的时候，没有考虑到汉语言的特点，有位前辈，曾经研究过WordPress的摘要算法，节选一篇文章中前55个字作为摘要，拉丁语系的单词之间以空格分隔，所以55个字，就是55个空格，那么对于汉语来说，可想而知了吧，我们几乎不会在文章中使用空格。解决这种问题，当然是有办法的，大名鼎鼎的“WordPress中文工具箱”，就提供了这种针对汉语的真正截断的算法，截取的是前面255个字节，然后去掉半个字产生的乱码。

或许，有些人觉得用中文工具箱就万事大吉了，但是对于写作习惯一般的XDJM们来说，前255个字节，可能就是前126个汉字，真的能摘要你的整篇文章吗？有些时候还是认真填写一下“可选摘要”吧。

然后我再来谈谈上文中括号里面的问题。在使用WordPress写文章的时候，如果文章太长，我们需要对文章提供分页，使用<!--more-->标签。但是使用了此标签后，就算是全文输出，也只能输出到该标签处，然后是一个read more的超链接。可以说，这也不是我们希望看到的。不过，解决这个问题就没有那么简单了。又想使主页的文章不要太长，又想在Feed中可以全文输出，怎么两全呢？

一个并不怎么完美的答案，就是使用@Feed插件。为什么说，并不完美呢？因为该插件在屏蔽more标签的时候，强制WordPress在Feed中输出摘要。真是很矛盾的对不？我也觉得很奇怪。

待续……

上一篇我说的同名文章在这里：http://sexywp.com/set-permanent-links.htm

写前面那篇文章的时候，我对WP的认识没有现在深，现在我来谈谈，经过了这两个多月后，我对永久链接的一些新看法。

我是学计算机的，所以对程序性能这种事情特别敏感，正好有幸在阅微堂（http://zhiqiang.org/blog/)看到了有关性能的文章，很感兴趣，最近一段时间，都致力于优化自己博客的性能。他其中有一篇文章提到，WP本身有些函数的撰写，是有性能问题的，比如很常见的一个函数叫get_permalink，这个函数非常好用，只要输入文章的ID，就可以得到文章的永久链接。但是此函数好用的背后，是从很大程度上牺牲了性能得来的。这个函数每调用一次，就要产生3次数据库查询。

1. 查询option表，永久链接的格式什么
2. 查询posts表，提取文章信息
3. 根据永久链接格式，查询需要的表，提取字段

上述中，第三点不是必须的，为什么呢，这就牵扯到你永久链接的结构问题，如果你的永久链接结构里面，包含了一些posts表中没有的字段，那么就必须到那个字段所在的表里面去找，所以必须查询。

官方推荐的永久链接结构是这样的

/%year%/%monthnum%/%day%/%postname%

这个结构是没有问题，这些字段都在posts表中。但是，有些网友喜欢一种看起来很美丽的结构

/%category%/%postname%

这种结构不能说不好看，有着很明确的逻辑性，看着很亲切，但是这个却有性能上的牺牲，因为%category%代表了一个分类的名字，这个名字不是放在posts表中的，必须到另一张表去查询，这就使得多使用了一次MySQL查询。所以，从性能角度来看，这个结构绝对是不美妙的。同理，在永久链接中包含一些%tag%也是降低性能的。

然后来说说那个函数的问题，那个get_permalink函数，其实是个模板tag，我自己实际尝试过，如果在the loop中使用get_permalink函数，并不会增加查询次数，究其原因，是WP在内部使用缓存机制，the loop本质上是一个非常复杂的查询，几乎查出了所有需要的东西，为了能在模板标签中反复使用，缓存了查询结果。

问题出在哪里呢，主要就是侧边栏，侧边栏已经出了the loop的范围，缓存的查询也失效了，所以侧边栏上的任何东西都是直接查出来的，所以有人在侧边栏上放很多文章标题列表，比如，最近发表文章，访问最多文章，留言最多文章，随机文章，每个列表有十篇，然后每次都用get_permalink来取得永久链接，那是非常恐怖的一件事情，你的页面会被拖得非常慢。

有些SEO高手给出了永久链接结构的建议

/%ID%

或者

/%postname%

这些结构很简单，而且在SEO过程中有一定作用，也存在这优化查询次数的可能。

为什么说只是可能，其实，就算你把永久链接改得很简单，也是降低了get_permalink函数取得链接的难度，并不能从根本上减少查询，因为那个函数调用的查询并没有完全去除。唯一的法子其实是不调用get_permalink函数。所以，要手动修改代码。如果你的链接结构足够简单，你在取得文章列表的时候，得到的信息已经足够自己手动拼接永久链接了，但是如果你的永久链接结构很复杂，比如带有分类信息，那么就算是由你手动拼接永久链接，也免不了要多查一次数据库。

希望我写得条理足够清晰。

我就照着做了，按说，也没啥好说的。就是让你的链接不要显示成：

http://sexywp.com/?p=7

而是显示成：

http://sexywp.com/set-permanent-links/

设置的方法也很简单，就是在“设置-->永久链接”那里，选择自定义。

我以前这么设置：

/%year%/%monthnum%/%postname%/

我现在按照上面说的文章的建议设置成了：

/%postname%/

呵呵，你一定发现了，为什么地址栏显示的却是：

http://sexywp.com/set-permanent-links.htm

如果你能举一反三，就一定知道我又play了哪一个trick，哈哈，但是我不建议你学我，因为我只是觉得这样看起来像回事，但是有没有什么坏处，我可是没有论证过的哦o(∩_∩)o。

现在我发现坏处了，就是trackback的链接会变成xxxxxx.htm/trackback。这个……我觉得看起来挺不和谐的。但是还是美观比较重要啊~~算了，就让它去了，反正我的博客看的人也没几个。