事情的起因是插件中的一个函数hook到了一个action上，名字是publish_post，顾名思义，在文章发布时候被激发的。为了要更清楚地掌控这个action，我想在源代码中，把触发点给找出来，这一找，问题来了。理论上，我们hook任何action，WP内部都会有对应的do_action来激发这个钩子，这一次，一搜，根本没有publish_post，那就有点小麻烦，说明具体激发哪个钩子，是运行时决定的，再明白点说吧，这个action的名字，应该使用变量拼出来的，所以我们直接搜publish_post很难找到调用点。

具体寻找的过程，我也不想赘述了，无非是查文档，搜代码。这里想要一提的是，我发现一个新的小技巧，给技巧取个名字叫“农村包围城市”，因为一下无法定位到想要找的代码，那么能准确定位其周边代码也是可以的，至少可以缩小查找范围。从文档中我们看到，在publish_post被激发的点附近，应该还有save_post，那么搜一下save_post，乖乖，准确找到了，然后就看到还有wp_insert_post，pre_post_update等等。然后，马上写一个小插件，向4个感兴趣的点hook，然后随便发布一下文章，根据打出的log，基本确定了publish_post就在pre_post_update和save_post中间激发。这时候就剩下80行左右的范围了，那一行行找还是很快的。

最终结果还是比较有意思的，有个函数叫wp_transition_post_status，这里面提供了3个hook，也可以说n个吧，因为这里面就看到了那个运行时才决定的hook名称的代码。最后不但搞清楚了publish_post的激发原理，还发现了原来可以随意通过hook监测每篇文章的状态变化。虽然短期内看不出来有啥用，但是以后一定可以想出来一些应用的。

• transition_post_status 当一篇文章或者页面状态变化时触发，三个参数，分别是原状态，现在状态，文章对象本身
• 状态_to_状态 某个具体的状态流转时候触发，可以是draft_to_pending，private_to_publish等等，只要是合法的status取值，可以随意组合。一个参数是文章对象本身。
• 状态_类型 一个状态+一个类型，可以知道publish_post这个钩子，本质上就是这种，真实含义是有一篇类型是post（还可以是page）的文章，状态变成了publish，而不是已开始我理解成的发布一篇文章时候激发。说起来差别不大，但是你对其的理解已经完全变掉了。以此类推，你可以hook到private_post，还可以是draft_page等等。随意组合。

通过上述非常灵活的3种钩子，我们就可以随时掌控任何文章的状态变化了。

您可能也喜欢：
WordPress插件开发实例--（01）	WordPress插件开发实例--(02)	插件开发全攻略（08）---构建一个WordPress插件用户面板	WordPress:插件开发API（Plugin API）	使用NetBeans IDE 6.5作为WordPress的开发环境
无觅

OK, well done!

您可能也喜欢：
[新闻]WordPress新特性预览—主题自动安装（多图）	WordPress主题：GoogleCode	WordPress到底在整啥？—(10)	WordPress备份及灾难恢复	免费WordPress主题
无觅

所以，作为WP插件的开发者，最好不要对插件最终的运行环境做任何假设。而且，最好能够在插件被启用的时候，进行必要的检查，给用户以提示，对于自己没法兼容的问题，应该明确指出，避免用户遭遇不必要的麻烦。

在我个人的WP插件开发过程中，我主要遇到的问题，基本上都是PHP相关的问题。

第一个是PHP的版本问题，现在主流的PHP版本是PHP 5.x，而事实上，PHP 4.x仍旧大行其道，如果插件中用到了PHP 5的特性，那么就要想到，插件可能出现兼容问题。比如PHP 5和PHP 4在面向对象方面有一些不同，应用了新特性的插件，在旧有环境下，可能无法正常工作。

我自己遇到的一个例子是DOM Document函数扩展，在PHP 4 和PHP 5中，差别很大，没法兼容，对于这种情况，我也没有很好的办法，只能为两种版本各创建一个函数的版本。做这样的事情非常吃力，乃至我后来已经决定不再开发支持PHP 4版本的插件，只是在插件的说明中写明，未进行过基于PHP 4环境的测试工作，请用户慎重，可能无法运行。这也是一种权衡利弊，有的时候，你的时间精力都有限，可能不愿意做这种吃力不讨好的事情，那也是无可厚非的，但是最好说明这一点。

另一个问题是，个别函数的问题的。比如我遇到一个是mb_str*系列函数的问题，这个系列函数，对于中国用户来说，可能意义特别重大，因为这个系列函数可以正确处理亚洲字符和兼容UTF8字符集。而事实上mbstring这个扩展，并非是每个服务器环境都会配备的，如果调用到了系列的函数，必须要进行检测，好在有好多此系列的函数，可以通过自己实现来弥补。

一般来说，对于有可能不存在的函数，都可以通过自己实现来解决，但是这其中也有一些小陷阱，在解决这种类似的兼容问题后，最好进行全面的测试。举个例子，如果运行时php环境没有包含mbstring扩展，那么当需要调用mb_strlen函数的时候，很简单，可以用自己实现的版本；可是另一些情况就不行，我这里想举个例子，就是scandir函数，这个函数是PHP的内置函数，但是在很多服务器环境中，出于安全的考虑，可能会被禁用，常见的被禁函数有（passthru, exec, phpinfo, system, ini_alter, readlink, symlink, leak, proc_open, popepassthru, chroot, scandir, chgrp, chown, escapeshellcmd, escapeshellarg, shell_exec, proc_get_status），如果插件中用到了，最好认真针对其进行测试。我在处理scandir函数的时候，也用了自己实现函数的法子来解决，谁知道，一测试才发现了不对劲，看看这个提示：

Fatal error: Cannot redeclare scandir() in E:\Green_Software\xampp\htdocs\demos\index.php on line 24

这是我遇到的错误提示。后来写了一小段代码进行了测试，才发现这个问题，scandir是内置函数，在php.ini中，通过disable_functions选项将scandir屏蔽掉后，function_exists('scandir')函数将返回false值，然而，这个函数的状态却是declared。也就是说，这个函数明明“声明”了，却并不“存在”，那么一般套用的先判断函数是否存在，再决定是否实现自己版本的做法，就失灵了，会引发上述错误。这个问题让我相当头痛，在我看来，想要完美地解决，几乎是不可能。我用了一个非常笨拙的方法，就是对这一类可能会被禁止的函数进行封装。然后在实际调用的时候，调用自己重命名过的函数版本。

综上可以知道，就算同样是function_exists返回false情况，用同一种方法，也不能一并解决所有问题。最好的办法，还是用不同的办法综合起来解决问题，并且进行尽可能全面的测试工作，最后对插件可能引发的问题进行详细的说明。

在具体开发过程中，还是不要进行任何假设，对runtime环境进行一遍检查比较稳妥，下面贴一个本人进行环境安全检查的例子：

如上，用户会在打开后台页面时，就发现一条警告信息，说明此插件可能无法正常工作。

您可能也喜欢：
使用NetBeans IDE 6.5作为WordPress的开发环境	WordPress插件开发实例--（01）	WordPress插件开发实例--(02)	插件开发全攻略（08）---构建一个WordPress插件用户面板	插件开发全攻略（06）---WordPress插件Filter
无觅

WP的后台本身就已经加载了许多的脚本，包括各类类库和基础功能的脚本。过多的脚本文件引入，会增加HTTP请求，增加流量，拖慢速度。好在，WP的后台已经采取了相当多的措施，来管理后台加载的脚本。首先是用wp-dependency管理依赖关系，用load-scripts来压缩、并加载脚本，使得各种类库被合并到同一个文件中进行加载，节省了HTTP请求数量和流量。

在开发插件管理后台的时候，窃以为还是遵循WP本身的开发习惯比较好，也将这一套措施应用到自己的开发过程中，这样一来，会有很多的好处。首先，不会给WP的后台带来太多的负担，使用WP本身的脚本加载机制，就不会为WP的后台增加多于的HTTP请求，而且，WP后台中，将脚本在页面的最尾部引入到页面之中，这也遵循了比较优秀的实践经验。

其次，使用WP自身的脚本管理机制，不会重复引入相同的脚本，也可以合理地管理依赖关系，在进行WP相关的开发过程中，如果需要引入特定的脚本库，只需要调用wp_enqueue_script函数即可，比如引入jquery类库，wp_enqueue_script('jquery);就可以实现在页面中正确引入jquery类库。WP_Script对象会自动判断重复，如果已经有别的插件或者页面本身已经引入了jquery，那么就不会重复引入。另举个例子，假如需要一个拖拽排序的效果，那么需要选用jquery ui中的sortable组件，那么只要调用wp_enqueue_script('jquery-ui-sortable');即可，在页面中，就可以发现，ui.core.js也被加载了，ui.core是sortable依赖的库，但是却不需要开发者自己去操心了。

从上述描述中，也可以看到另一个好处，就是wp其实已经包含，并且注册了很多常用的类库和效果库，使用其自带机制，调用这些脚本都是非常容易的，并不用费心去管这些脚本到底存在何处，其url到底是什么，只需要简简单单用一个名字既可以引入页面中。此外，如果插件中引用的脚本类库升级了，那么也会随着用户端WP的升级而自动更换是上升级的脚本，省却了更新插件的麻烦。

下面是我个人在开发中的实践作法。

在插件开发过程中应用脚本库和特定脚本需要调用的函数就是wp_enqueue_script，上面已经介绍过了，接下来介绍一下这个函数调用的位置。

比如说，我现在要开发一个插件，叫做detail info，在其后台管理页面中，需要用到jquery ui selectable组件。引入这个脚本的方法如下：

一般我个人开发一个插件的时候，都喜欢将所有的插件初始化工作放到一个init函数中，然后将这个函数hook到plugins_loaded之上（这么做的原因就不赘述了）。在init函数中，就可以调用wp_enqueue_script函数了，当然也有不按照这个结构来写插件的，但是道理是一样的，就是此函数要在action wp_head和admin_head发生之前被调用，plugins_loaded这个action发生的顺序是非常靠前的，所以此函数放在这里，一定可以正确引入脚本。

当然，这么做只是可行的做法，却不是正确的做法，这么做的话，由于是添加到了plugins_loaded这个action中，那么所有的页面中，至少会多出几个脚本文件，一个jquery，一个是ui.core，一个是ui.selectable，这个组件仅需要在后台中引入，却不得不在所有的页面中加载，可以说，是一种很不经济的做法。对于开发者来说没什么，但是对于用户来说，就增加了他们服务器的负担。当然更多时候，用户可能并不懂得其中的意义，他只知道一件事情，就是插件装得越多，自己的博客运转速度就越慢，很多WP用户都经历过热衷于安装各种插件，到头疼安装了很多插件，到最后一切从简对插件望而却步的一个转变过程。其实，我个人觉得，在这个转变过程中，插件的开发者是负有一定责任的。

上面是更加常用的一种做法，通过is_admin()条件判断函数，来使得脚本只在后台加载，这样的话，就不会在博客的页面上添加可能根本就完全不会用到的脚本。

做到了这一步，基本上，事情已经做到差不多了，但是，这离尽善尽美还很遥远。使用上述第2个代码范例，可以使脚本不在前台页面加载，但是在后台页面还是没有区分能力，简单说，就是会在后台所有的页面中都添加了上述几个脚本文件。这样，会拖慢博客后台的速度，好在后台用户并不多，访问压力并不大，一时半会儿，也不会出什么问题。但是，短时间没问题不代表永远没有问题，在后台所有页面引入相同的脚本，有一个后果，很有可能在插件安装数量多了以后，出现脚本冲突问题。虽然这种冲突，可以通过脚本地开发技巧来解决，一般比较成熟的类库都不会互相发生冲突，但是，如果有开发者用这种机制引入了自己的编写的专用脚本，那就很难说了。

最佳的做法，无疑是只在用到的那个页面，才引入相关的脚本。其他页面一律不加入脚本。做到这一点，并不容易，乃至是相当苦难。我个人在开发过程中也试过几种方法，但是效果都不是很好。

起初，我的做法是，直接将脚本写在插件的管理页面的代码中，这么一来，肯定是可以实现脚本按需加载的，但是这样一来，就会使js脚本代码和页面代码混在一起，开发起来，维护起来，还是调试起来，都不是很方便。另外也破坏了web开发行为和数据表现分离的准则。不过，这种做法，确实是一种比较稳定而且比较容易想到，又比较好实现的做法。对与自己写的脚本来说，也没什么太多不便，不便主要体现在类库的引入上面，前文提到的好处一个都不复存在了。

后来，我又发现了一种方法，就是通过$_SERVER系统变量中的QUERY_STRING来判断当前所处的页面。比如，在上述范例的插件中，其管理界面的url显示成这个样子：

http://localhost/wordpress/wp-admin/options-general.php?page=detail_info_manager

从这个URL中，就可以判定出来，当前打开的页面确实是这个插件的管理页面，这样一来，以此为依据就可以决定是否要引入脚本，其示例如下：

上述这个办法在后台脚本引用管理方面的效果还算不错，基本上按照我的要求做到了按需加载。

您可能也喜欢：
WordPress:插件开发API（Plugin API）	使用NetBeans IDE 6.5作为WordPress的开发环境	WordPress插件开发实例--（01）	插件开发全攻略（04）---WordPress插件的结构	插件开发全攻略（09）---WordPress插件和数据库交互
无觅

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

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

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

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

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

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

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

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

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

您可能也喜欢：
WordPress:插件开发API（Plugin API）	Simple Tags 升级到1.5.1后，语言包失效	WordPress插件：选项查看器	WordPress插件开发实例--（01）	插件开发全攻略（08）---构建一个WordPress插件用户面板
无觅

我在研究Extended Live Archive（ELA）插件的代码，发现一个问题，这个问题具有一定的共性，而且，我现在也没有什么好的解决办法，所以我把它描述一下，看看有没有高人高见。

WP插件一般目标有两个，一个是增强博客页面功能，让观众有更好体验，另一个是增强博客管理页面功能，让博客管理者有更高管理效率。无论是哪一种，我们都经常会用到脚本，比如指定样式的CSS脚本，指定行为的JS脚本。好，现在问题来了，一般来说，我们使用插件增强的功能，都是在某个特定的页面上的功能，只有少数才是全局功能，直觉上，我们希望，在这个特定的页面上引入需要的脚本，而在其他的页面上不引入这段脚本。

我这个话说得有点绕，举个具体的例子。比如，某个插件，用于显示一个漂亮的相册，这个相册有一个自己专属的相册页面，这个相册的翻页功能需要用到prototype类库，你作为一个博客的主人，肯定是希望只有用户打开相册页面时，用户才需要下载prototype，平时看你的博客，不用每个页面都去下载一下prototype。（这个类库在没有pack的情况下128k大。）

希望我说清楚，这个问题概括成一句话，就是按需加载脚本，用到时，才下载。

事实上是这样的，我说得很轻巧，但是做起来却很难。就拿我手头的这个ELA来说事，这个插件是一个AJAX应用，用来展示一个结构化的归档目录。插件通过一个template tag提供用户接口，在调用这个template tag的页面，就会有归档目录出现。这个归档目录，必须要CSS文件来指定其样式，结果，我们的难点是，不知道用户会在哪个页面上调用这个tag，所以只能草草地把这个样式表hook到wp_head，导致的结果是，所有的页面上，都会链入这么一个样式表，而真正起作用的，只有一个页面而已。

我初步想了想，几乎想不出漂亮的办法能解决这个问题。这个问题的根本就在于，程序在执行到wp_head的时候，我们还没法知道后续的部分是不是会出现那个tag，而在真的执行到这个tag的时候，头部的内容已经形成了，我们回天乏力。一个直觉的办法，就是把那个样式表，直接也塞到tag的内部，事实上，插件的作者就是这么做的，不过，他只是把用到的JS脚本这么处理了，却没有把CSS这么处理，我猜想他代码写到这里的时候，可能内心也是非常矛盾的。（因为一个优秀的页面，就应该是数据、表现、行为分离的，这么做等于破坏了这个原则了）

好，到这里，问题应该算是说完了。其实这个问题相当普遍，只要我们需要将一个脚本添加到wp_head或者admin_head（对应的还有各自的footer部分），我们就面临着这个问题，你添加的东西，真的每个页面都需要么？如果是大多数页面需要，那还不是很浪费，最浪费的就是只有一个页面需要，而其他所有的页面都跟着增加负载。

WP的圈子里，有一种论调，就是插件用得越多，博客速度越慢，性能越差。我想，脚本没有能够做到按需加载，也算是造成这个论调的原因之一。

大家一起开动下脑筋吧~

您可能也喜欢：
使用NetBeans IDE 6.5作为WordPress的开发环境	WordPress:插件开发API（Plugin API）	WordPress插件开发实例--(02)	插件开发全攻略（08）---构建一个WordPress插件用户面板	WordPress插件开发实例--（01）
无觅

我不是一个撰写readme.txt的专家，但是我经常需要做这件事情，我自己也很不在行，从来没有仔细研究过这件事情，今天在这里写下的是我第一次研究的笔记。对本文内容的权威性，大家请自己斟酌。

首先来看一看例子：

• Templates : You can add custom templates for your theme.
• Media RSS feed : Add the Cooliris Effect to your gallery
• Role settings : Each gallery has a author
• AJAX based thumbnail generator : No more server limitation during the batch process
• Copy/Move : Copy or move images between galleries
• Sortable Albums : Create your own sets of images
• Upload or pictures via a zip-file (Not in Safe-mode)
• Watermark function : You can add a watermark image or text
• JavaScript Effect : Use any available popular image effect : Shutter, Thickbox, Lightbox or Highslide
• Multiple CSS Stylesheet : Use a nice shadow effect for your thumbnails with your own CSS file
• Slideshow : Full integrated flash slideshow
• TinyMCE : Button integration for easy adding the gallery tags
• Sidebar Widget : Show a slideshow, random or recent picture at your sidebar
• Language support : Translated in more than 30 languages
• Upload tab integration : You have access to all pictures via the upload tab
• Tag support for images : Append related images to your post, create a image tag-cloud
• Meta data support : Import EXIF, IPTC or XMP meta data
• Sort images feature
• Cool flash addons here : url

这份列表，撰写得有其特色，这是NextGen Gallery的features list。其采用的格式为：“特性名称：简述”。特性名称，一般采用的是名词，可以是具体名词，也可以是动名词，其格式基本上比较统一。

而其简述部分，则比较自由。

第一句，you can do sth. 是一个简单句。以第二人称描述，这跟人的感觉像是一个推销员，在与你说话，隐含了一层意思，“如果你用了本插件”，“你就可以用这款插件做……”。第二句，是一个动宾短语，我们可以猜测其隐含主语，窃以为，仍旧是“你”，“(you are able to) add Cooliris Effect to your gallery (with it)”。看到这里，我们就可以统计一下，这么多features里，使用这两种用法的句子，暗红色为第一种，浅蓝色为第二种。除却这两种，我们还看到其他的例子，用绿色标出的，是我个人认为有一些共同点的例子，第一个是简单句，但是是以第三人称为主语的句子，后面两个，则是分词开头的关于，而我猜测其主语，也为第三人称。

看了看原作者的blog，基本上是英文写成的，而也有少量的德语，我们可以视其为是native speaker。从他撰写的特性列表里，我们可以学习到一些西方人传达信息和接受信息的模式。他们更关心的是，可以用这款插件做什么，他们应该怎么使用这款插件。一款插件的使用方式和其提供的可能性，是他们关心的东西。而插件本身利用的技术，插件本身的性质和特性，不是他们关注的东西。

如果你的插件，有许多的特性，你在描述的时候，应该转换一种表达思路，即这种特性，能够带来一种什么样的使用上的可能性。尽量使用第二人称来描述，“你用它，能够干……”。这是西方人，更能接受的一种方式，也符合他们的表达习惯。

行了，本文就写到这里。其实，我还看了两个插件的features list的，但是基本上雷同，大家可以自己分析。本文主要写给自己看，作为自己学习写作的一些笔记。

您可能也喜欢：
WordPress插件开发实例--（01）	插件开发全攻略（08）---构建一个WordPress插件用户面板	WordPress:插件开发API（Plugin API）	插件开发全攻略（07）---构造一个WordPress插件管理员面板	WordPress插件开发实例--(02)
无觅

上一次是整顿了Widgets API接口，现在又是大规模变动管理界面。WP关于Widget方面的更新，带给我很大的焦虑，因为我开发了巨量的Widget，一旦这些新的API和界面投入使用，就意味着我要增加很多工作量。另外，我看到了一个可怕的问题，就是有些用户可能不会升级到新版本，那么是否意味着一个Widget要维护两个版本的代码呢？太可怕了，希望WP能够处理好这个问题。

不想多写了。

When I am debugging a plugin, I always want to konw, whether the options in this plugin are saved exactly or not. Usually, I add var_dump statement in my source code to print the options out. Everything looks good, but when I finished my job, it bothered me a lot to remove this debug statements. What annoyed me even more is that when I change my mind and changed the structure of the option, I must use additional statement to alter the option or directly use SQL in phpMyAdmin. Finally, I created this tool to assist the plugin development.

Features:

• List all options order by option_id.
• Search option through keyword.
• View unsierialized value of options.
• Modify option use PHP code.

Demo: (Click to see the full size.)

Download: Options Inspector v1.0.1

选项查看器是一款开发辅助工具，用于显示，修改和删除选项。免去了使用打印语句和使用phpMyAdmin的调试后台选项的麻烦。愿大家能够更轻松地开发WordPress插件和主题。

一般，不建议您在您的主力博客上尝试该插件的修改和删除功能。

论坛本来想选Discuz的，无奈，学习成本太高，于是还是选择了bbPress，和WP同一个体系的微型论坛。代码看着分外眼熟，也有那么几分亲切，操作依然简便。功能嘛，真的不敢恭维了，比一无是处稍微强点。

目前开设四个论坛：

WP Kit CN——希望在这里收集到插件用户使用过程中碰到的疑难杂症。

Hybrid Theme Framework——在这里探讨关于Hybrid模板框架的使用技巧。

Plugin Development——希望与插件开发爱好者交流经验。

General——不符合以上三类的话题。

目前，我是个bbPress菜鸟，所以，论坛可能潜在一些不稳定因素，我会竭尽所能地去修复问题的。

Updated:

鉴于发生了有同学找不到论坛入口的事件，特在此添加一个入口链接。

点我进入论坛

NetBeans IDE是一款非常优秀的IDE环境，我以前曾经介绍过，如何使用NetBeans作为WP的开发环境，今天，再来介绍一个直接链接远程服务器进行调试的技巧。那就是FTP，记得在Dreamweaver的时代，配置远程服务器就是非常方便的一件事情，对于NetBeans这个更加现代和超前的开发环境来说，这当然也是必备功能了。

跟着我做，只有3个步骤，就可以搞定。上一篇《使用NetBeans作为WordPress开发环境》已经介绍了如何将WP导入到NetBeans工程，在其基础上，我们来配置FTP。

第一个步骤如上图，在项目面板，wp27项目上，单击右键，点属性，打开属性面板。下图为弹出的对话框。点击查看清晰大图。

遵循上图中蓝色字迹标注的1、2两次点击，会弹出FTP服务器管理面板，创建好一个FTP服务器配置。确定后，回到属性面板。如下图所示。

在上图中，我们配置运行配置为在远程Web站点运行。配置的选项可以参考图片中的配置。注意，刚才我们配置ftp服务器的时候，远端路径为wp安装目录，现在我们本地的目录只要填写一个/即可，代表项目根目录。

上面三个步骤，已经配置好了FTP服务器。在具体开发过程中，像下图的样子，点击你开发的主题中的文件，点击上传，就会自动上传到正确的地方，覆盖源文件。一般我在用NetBeans开发主题或者插件的过程中，都配合有SVN支持，所以不用担心覆盖会出问题，可以恢复到上一个版本。

好，希望对您有帮助~~

特性：

1. 拥有Hybrid主题所有的内在美
2. 两栏
3. 主页（Primary）、帖子页（Secondary）、归档页（Archive）、页面页（Page）有不同的侧边栏，括号里是边栏名字
4. 标签式页面菜单
5. 其他Hybrid主题框架所拥有的一些功能

版本：0.1beta

截图：

下载：点击这里

注意事项：

• 这是Hybrid的子主题，对应的Hybrid版本是0.5（不装Hybrid是无法使用的）
• 不要对这款主题的外在美有什么过多的期待，如你所见
• 0.1而且还beta，代表很多潜在不稳定性，未必好用
• 这款子主题的作者，不是专业的

作者笔记：

就像各位看到的那样，我非常喜欢Google Code的样式，我的站点换过数次主题，但是外观都定格在Google Code的样式上，最早的verygoogle，然后是yui-theme，然后是现在GoogleCode for Hybrid。外观基本雷同。不要嘲笑我，我对复杂的结构没有驾驭能力，只好选择简洁，设计非我所长。

这款主题的发布，我不指望有什么用户真正去用，如果有人真的要采用，希望你三思，因为我很忙，不会提供必要的支持。

我发布这款主题的真正目的，是为了有始有终，我前面发表了一系列的介绍Hybrid的文章。很遗憾，我也没说明白个啥，这是因为真的很难说明白。不过呢，我还是要完成我的计划，就是给大家展示一个实例教程。这款主题于是来到了你的面前。这款子主题的原身为Hybrid子主题Skeleton，那是一个没有任何样式和功能，只包含一个Hello World的子主题，其本来用意也就是为了成为子主题开发的基础。我通过简单的开发，寥寥数行的代码，做出了这个GoogleCode，里面的代码，包含了一些简要的注释，希望看代码的同学能够有个线索。

通过对Hybrid的使用，我发现，这款主题很好用，很容易二次开发，作为一个IT民工，使用Hybrid是非常愉快的，就像你使用任何其他的开源框架一样，这个主题框架同样可以极大地提高您的工作效率。但是，如果您只是一个普通的用户，您大概需要什么样的基础才有能力定制Hybrid呢，仅仅从我的观点，您需要基本的编程素养，您可能需要一点PHP的语法知识，要明白callback是怎么回事，能够查阅文档，然后，您可能需要对WordPress插件的基本工作原理有所了解，分得清楚什么是Action和Filter。在以上的基础上，您可能需要很多的实践才能游刃有余地定制Hybrid，开发子主题。

wp2.5.1——http://wordpress.org/wordpress-2.5.1.zip
wp2.6.3——http://wordpress.org/wordpress-2.6.3.zip
当前版本——http://wordpress.org/latest.zip

其他版本依此类推。

建立磁盘目录：

www
|—phpMyAdmin
|—wp25
|—wp26
|—wp27
|—plugins

我就是按照上面的样子建立的。plugins用来统一存放插件。（如果是xampp的话，根目录是htdocs，phpMyAdmin已经安装好了。）

建立测试数据库。三个wp使用同一个数据库。

配置wp-config.php

关闭老版本WP的升级提示：

找到wp-includes/update.php

//add_action( 'init', 'wp_version_check' );

像上面那样注释掉上面那行字。

在plugins目录下，安装ozh的no-login插件。

现在这套测试环境，我自己使用下来感觉是WP 2.5的支持很不好。很多插件走不通。主要就是路径的问题。WP2.6和WP2.7的问题不大。但是如果插件需要引用wp_blog_head.php或者wp-config.php，在这样的环境下无法正常运行，我想这其实也是插件开发者的疏漏吧。

Actually, I'm lazy, and I hate paper work. My dear friend, Snowblink, created this document. Thank her very much!

非常感谢snowblink的辛勤工作，我不知道如何才能用英语表达对你的感谢。所以用中文再说一遍！

If the following answers do not solve your problem, please contact the author via the Contact Form.

Please describe your problem, the PHP and wordpress version you use, and what you have already tried in detail.

Q1: Which version of the PHP do I need to make the flash mp3 player work?

A: This plugin requires PHP version 4 or higher.

Q2: Which version of wordpress does the plugin require?

A: WordPress 2.5 or newer recommended.

Q3: When I use your plugin, I got the following error message:

Warning: domdocument() expects parameter 2 to be long, string given in /home/8099/domains/funkshoppe.com/html/wp-content/plugins/flash-mp3-player/flash-player-widget.php on line 120
Fatal error: Call to undefined function: loadxml() in /home/8099/domains/funkshoppe.com/html/wp-content/plugins/flash-mp3-player/flash-player-widget.php on line 121
My WP version is 2.6. What can I do?
A: This error may result from using PHP prior to version 5. Maybe you could edit the "playllist.xml" by hand. The file is in folder"flash-mp3-player". Now, this plugin support PHP 4.

Q4: I'm not able to see the plugin in the options panel, where I can change the playlist. Although I can configure the widget, I see nothing where I can change the playlist. What can I do? I try already to reinstall it, but nothing changes.

A: Maybe the options panel does not work under PHP prior to version 4.2. But you can edit the playlist manually instead of using options panel. The playlist file is a XML file in the plugin directory called playlist.xml. You can edit it using Notepad or something like that. There are some samples in this file originally.

Q5: I want to get rid of the title "Flash MP3 Player" which appears above the player and the bar that appears below the player. What can I do?

A: To get rid of the title "Flash MP3 Player", you should go to the widgets admin page, find the Flash MP3 Player widget, and edit its title.

I don't know exactly what the bar you talked about. If you mean the playlist part of the player, you can go to the options->MP3 player page, and input the answer "no" to the question "Show play list,yes or no?"

Q6: When I try to change my playlist, it doesn't change in the player. I changed the song titles and locations in the player settings, and those changes were written to the playlist xml file, but the widget in the side bar is still playing the old playlist. I've tried refreshing the webpage and cleared my temporary Internet files and cookies. I've tried it in Firefox 3 and Internet Explored 7. I've removed and replaced the widget. I've deactivated and reactivated the plugin. I just can't get it to update and use the new list. Any suggestions?

A: It seems that you have tried every method I can find to fix this problem. I still think the real problem is that the browser does not download the playlist xml file, but still use the old one. Maybe you could try another version. Its location is at....(此处有附件，没包括）

Q7: Every time I try to put in my own songs and press save, none of the options save. Actually, I cannot change the default options. Please help me.

A: You could try to edit the playlist manually, it is in the /wp-content/fmp_my_playlist directory. If the playlist is not there, maybe you could try to update the plugin. I hope this could help.

Q8: Is it possible to extend the playlist to approx.15 songs? Is there a way to order playlist into albums?

A: If you want to insert more than 10 songs to your playlist, the only way currently is to edit the playlist.xml manually.This file is in directory "wp-content/fmp_my_playlist".
I am sorry that you cannot manage the playlist by albums, since the player itself does not have this feature.

Q9:I've just tried installing your flash player on my WP 2.6 site.
However, I got the following error when turning the plugin on:
Warning: copy(/home/staff_hosting/vgames_beta/public_html/minisites/blogs.vgames.co.il/public_html/h2/wp-content/fmp_my_playlist/playlist.xml) [function.copy]: failed to open stream: No such file or directory in /home/staff_hosting/vgames_beta/public_html/minisites/blogs.vgames.co.il/public_html/h2/wp-content/plugins/flash-mp3-player/flash-player-widget.php on line 49
In addition, when trying edit the player configuration, I got this error:
Fatal error: Class 'DOMDocument' not found in /home/staff_hosting/vgames_beta/public_html/minisites/blogs.vgames.co.il/public_html/h2/wp-content/plugins/flash-mp3-player/flash-player-widget.php on line 147
What to do?

A:It seems that the copy function fails in your site. You could try this:
First, create a directory "fmp_my_playlist" in "/wp-content".
Second, copy the file "playlist.xml" which is under the plugin directory to the new directory.
Third, try to edit the playlist in admin panel again.
If all of the above don't work, you could edit the playlist.xml mannually.

Q10:When accessing the player configuration menu, I get the following error:
Fatal error: Class 'DOMDocument' not found in /home/staff_hosting/vgames_beta/public_html/minisites/blogs.vgames.co.il/public_html/h2/wp-content/plugins/flash-mp3-player/flash-player-widget.php on line 147
I guess this means I won't be able to use the configuration menu?
I tried editing the XML file manually and uploading it via FTP, but it seems to have no effect.
EDIT: It seems my browser was simply displaying the cached version of the site.
This keeps happening whenever I edit the play list - in both IE and FireFox. Any thoughts on how to make it refresh?
I don't want to require the users to clean their cache every time to see the updated play list.

A:It seems that the PHP on your host does not support the DOMDocument class, so you have to edit the playlist manually.
In fact, there is a way to force browsers to download the new version of the playlist:
First, find this line in the source code(line 69)
$datafield = $base_name . '/mp3player.swf?playlist=' . $fmp_listfile_url;
Second, change it to:
$datafield = $base_name . '/mp3player.swf?playlist=' . $fmp_listfile_url . '?' . rand();
This is a little trick. The random query string will tell the browser, "this playlist is not the same one with you have downloaded last time, and you must download it again." (此处有附件，没包括）

Q11:Would it be possible to make track names right-alighned and right-to-left in direction?Does that require a code change or just an addition to the playlist XML?

A:Sorry,you can not make the player right-align the track name through the configure xml file, and me too. I'm not the author of the mp3 player, I'm just the one who make it a WP plugin.

WordPress phpDoc

WordPress内部使用phpDoc的语法进行注释，这是WordPress.org为其生成的文档。

WP 函数搜索引擎

超级棒的一个功能~ 看看下文的说明。

I want to quickly let everyone here know of a site that one of my good
friends, Andy Stratton (http://theandystratton.com), has setup
recently. The site is called WPLookup and can be found at
http://wplookup.com/. It provides a simple search box for quick
lookups of WordPress functions and template tags. If the appropriate
codex page exists for the function you are looking for it will
immediately redirect you there. If it does not exist you will be
directed to a documentation search on http://wordpress.org/search
which will contain a list of results for you.

To make it even better the site can also integrate into your browsers
search bar keeping you from ever having to actually navigate to the
WPLookup site to do the search.

I have taken his service one step further and integrated his service
into an IRC bot. The bot is sitting in #wordpress on freenode. To
use the bot type something in the form of `.codex get_pages`.

Now what are you waiting for? Check it out now at http://wplookup.com/.

Enjoy!
--
Matt Martz
matt@sivel.net

WordPress源代码交叉引用

WordPress各个版本的源代码交叉引用。

WordPress插件开发模板

尝试一下吧，看看这个东西能从多大程度上提高你插件开发的效率？里面的东西相当全面啊，传达出了作者很多的开发经验。

概念阐述

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界的一代大侠，用上人人羡慕的，“与众不同”的主题。

谢谢！

迫不及待的安装上了，在菜单里面找了一圈，就发现多了两项，（我的判断方法是，没有中文翻译的那项，就认为是新的，不知道准不准），我们先来看最抢眼的一项。

Add New Themes

像插件安装功能一样的主题安装功能，哈哈，此前在邮件列表里面也看到过好几次讨论这个的了。这次终于看到实作了，说实话，效果还是相当惊艳的，想到以后找主题不用漫天海找了，真是幸福。好了，我们先来看看这个界面的样子吧。

在这个界面上，我们可以看到，一共提供了五个主要的功能，默认进入的是搜索页面。可以按照“Term”，“作者”，“Tag”来搜索主题，下面的标签云也可以点击，那样就会直接进入“主题超市”随便选择。还有四个选择是上传，特色主题，最新主题，最近更新主题。上传界面比较简单，我就不截图了，就是一个文件上传框，可以从本地文件中直接上传主题压缩包到你的主题目录自动解压。另外三个都是直接打开主题选择页面了。

主题选择页面的样子如上图所示。跟主题管理页面有点像，每个主题下面有两个链接，一个是预览，另一个就是安装。我在特色主题里面看到了一款主题，相当漂亮，所以，我就预览了一下子，我们一起来看看。

可以看出来，这个界面基本上延续了主题管理界面的那个预览功能。只不过这次是从远程服务器直接下载预览页面来看，而非将远程的主题套用到你现在的博客上。这样预览速度倒是极快，就跟打开一个普通网页一样。好，接下去如果想安装，还要先退出预览界面才行，因为安装链接在外面，我觉得这里可能还会改进吧，为什么不像主题管理页面的那个预览一样，直接把下载链接放在预览窗体的右上角呢？现在这个样子有点麻烦，当然，也有可能，萝卜青菜各有所爱吧。

这个面板倒是十分地简洁，基本上没有什么花哨的东西，有个温馨提醒，主题在您的WP版本上未通过测试。按下安装，这个主题被顺利安装了。看来现在，这个主题从后台直接安装的特性基本上已经开发完毕了，当然样式上还有点乱，这些就是细节问题了，相信不久，大家就能用上这个很酷的功能了。

Post Tags

另一个功能，就是出现在“文章”子菜单里的Post Tags功能了，这个功能也是相当的酷，类似于Simple Tags提供的批量标签管理。这个功能我就不截图了，直接描述一下吧。

首先是发布新标签。在这个界面，你可以直接创建一个空标签。而且，现在的标签都是支持slug功能的，这点已经使得标签和分类没有什么分别了。

其次是一个标签列表，像是管理分类的分类列表一样。提供了快速修改标签slug和标签名字功能，还有删除单个标签或者批量删除标签功能。

目前，这个功能就者有这些吧，从全面性上看，这个功能只实现了Simple Tags的管理标签功能，还缺乏批量修改文章标签，智能标签的功能。不过我估计这个功能里面带有的api，可以帮助插件开发者开发出更丰富的应用。看来，著名的Simple Tags也要和Thread Comment一样，最终退出历史的舞台了。

好，今天就到这里，祝您晚安！！

Home页面流程图

1. hybrid_head()
2. wp_haed()
3. body
4. hybrid_before_html()—action，默认没有被hook
5. div#body-container
6. hybrid_before_header()—action，默认没有被hook
7. div#header-container
8. div#header
9. hybrid_header()
10. end#header
11. end#header-container
12. hybrid_after_header()
13. div#container
14. hybrid_before_container()—action，默认没有被hook
15. div#content
16. hybrid_before_content()
17. /*wp loop begin*/
18. div.hybrid_post_class()
19. h2.post-title inline
20. p.byline inline
21. div.entry-content inline
22. p.entry-meta inline
23. end.hybrid_post_class()
24. /*end wp loop*/
25. hybrid_after_content()
26. end#content
27. hybrid_after_container()
28. end#container
29. div#footer-container
30. hybrid_before_footer()
31. div#footer
32. hybrid_footer()
33. wp_footer()
34. end#footer
35. hybrid_after_footer()—action，默认没有被hook
36. end#footer-container
37. end#body-container
38. /body

hook到hybrid_head()的函数列表

1. hybrid_meta_content_type()
2. hybrid_meta_robots()
3. hybrid_meta_author()
4. hybrid_meta_copyright()
5. hybrid_meta_revised()
6. hybrid_meta_abstract()
7. hybrid_meta_description()
8. hybrid_meta_keywords()
9. hybrid_meta_template()
10. wp_generator()
11. hybrid_favicon()
12. hybrid_head_feeds()
13. hybrid_head_pingback()
14. hybrid_head_breadcrumb()

hook到hybrid_header()的函数列表

1. hybrid_site_title() —提供同名filter，参数为标题包括其html tag，没有被hook
2. hybrid_site_description() —提供同名filter，参数为站点描述，包括其html tag，没有被hook

hook到hybrid_after_header()的函数列表

1. hybrid_page_nav() —启动两个action，并提供一个同名filter，参数为导航条包括其html tag，没有被hook

hook到hybrid_before_content()的函数列表

1. hybrid_breadcrumb() —提供一个同名filter和一个名为hybrid_breadcrumb_args的filter
2. hybrid_get_utility_before_content() —该函数打印位于Content之前的Sidebar，在Hybrid中被赋予一个名称为Utility

hook到hybrid_after_content()的函数列表

1. hybrid_get_utility_after_content() —该函数打印位于Content之后的Sidebar
2. hybrid_navigation_links() —该函数打印WP自带的简单页面导航Prev和Next

hook到hybrid_after_container()的函数列表

1. hybrid_get_primary() —该函数首先提供一个filter，名为hybrid_primary_var，参数sidebar_id，如果传入false可以关闭侧边栏，该函数打印主侧边栏，并在此之前和之后分别触发一个action
2. hybrid_get_secondary() —原理基本上和上一个相同，提供的filter名字为hybrid_secondary_var
3. hybrid_insert() —提供一个同名filter，参数为要打印出来的内容，默认为false，这是专门给用户用来添加sidebar的hook

hook到hybrid_before_footer()的函数列表

1. hybrid_get_subsidiary() —其功能等同于侧边栏，同上面两个侧边栏

hook到hybrid_footer()的函数列表

1. hybrid_copyright() —打印版权信息，提供同名filter
2. hybrid_credit() —与上面一个类似，也提供同名filter
3. hybrid_query_counter() —打印页面生成时间和数据库查询数的函数

由hybrid_page_nav()触发的action

1. hybrid_before_page_nav() —action，默认没有被hook
2. hybrid_after_page_nav() —action，默认没有被hook

由hybrid_get_primary()和hybrid_get_secondary()和hybrid_get_subsidiary() 触发的action

1. hybrid_before_primary() —action，默认没有被hook
2. hybrid_after_primary() —action，默认没有被hook
3. hybrid_before_secondary() —action，默认没有被hook
4. hybrid_after_secondary() —action，默认没有被hook
5. hybrid_before_subsidiary() —action，默认没有被hook
6. hybrid_after_subsidiary() —action，默认没有被hook

页面模板一览

1. Template Name: Archives
2. Template Name: Authors
3. Template Name: Biography
4. Template Name: Blog
5. Template Name: Bookmarks
6. Template Name: Categories
7. Template Name: Log In
8. Template Name: Logged In
9. Template Name: No Widgets
10. Template Name: Profile
11. Template Name: Quick Post
12. Template Name: Register
13. Template Name: Sitemap
14. Template Name: Tags
15. Template Name: Widgets

Action一览表

1. comment_form
2. hybrid_before_html
3. hybrid_after_html
4. hybrid_head
5. hybrid_before_header
6. hybrid_header
7. hybrid_after_header
8. hybrid_before_page_nav
9. hybrid_after_page_nav
10. hybrid_before_cat_nav
11. hybrid_after_cat_nav
12. hybrid_before_container
13. hybrid_before_content
14. hybrid_after_content
15. hybrid_after_single
16. hybrid_after_page
17. hybrid_before_comments
18. hybrid_before_primary
19. hybrid_after_primary
20. hybrid_before_secondary
21. hybrid_after_secondary
22. hybrid_before_subsidiary
23. hybrid_after_subsidiary
24. hybrid_after_container
25. hybrid_before_footer
26. hybrid_footer
27. hybrid_after_footer
28. hybrid_child_settings

Filter一览表

1. show_password_fields <-- register.php(115)
2. hybrid_post_meta_boxes <-- meta-box.php(74)
3. hybrid_page_meta_boxes <-- meta-box.php(121)
4. hybrid_settings_args <-- theme-settings-admin.php(65)
5. hybrid_breadcrumb_args <-- breadcrumbs.php(31)
6. hybrid_breadcrumb <-- breadcrumbs.php(220)
7. hybrid_breadcrumb <-- breadcrumbs.php(222)
8. hybrid_avatar <-- comments.php(67)
9. hybrid_allowed_tags <-- filters.php(95)
10. hybrid_site_title <-- filters.php(115)
11. hybrid_site_description <-- filters.php(134)
12. hybrid_page_nav <-- filters.php(166)
13. hybrid_cat_nav <-- filters.php(189)
14. hybrid_category_menu_args <-- filters.php(236)
15. hybrid_category_menu <-- filters.php(275)
16. hybrid_search_form <-- filters.php(313)
17. hybrid_insert <-- filters.php(328)
18. hybrid_copyright <-- filters.php(350)
19. hybrid_credit <-- filters.php(380)
20. get_the_image_args <-- get-the-image.php(37)
21. get_the_video_args <-- get-the-video.php(37)
22. hybrid_enqueue_style <-- media.php(39)
23. hybrid_enqueue_script <-- media.php(92)
24. hybrid_favicon <-- template-functions.php(293)
25. hybrid_primary_args <-- widgets.php(64)
26. hybrid_primary_inserts <-- widgets.php(68)
27. hybrid_secondary_args <-- widgets.php(84)
28. hybrid_secondary_inserts <-- widgets.php(88)
29. hybrid_subsidiary_args <-- widgets.php(110)
30. hybrid_subsidiary_inserts <-- widgets.php(114)
31. hybrid_utility_args <-- widgets.php(138)
32. hybrid_utility_inserts <-- widgets.php(142)
33. hybrid_widget_class <-- widgets.php(209)
34. hybrid_primary_var <-- widgets.php(402)
35. hybrid_secondary_var <-- widgets.php(420)
36. hybrid_subsidiary_var <-- widgets.php(438)
37. wp_page_menu_args <-- legacy.functions.php(40)
38. wp_page_menu <-- legacy.functions.php(75)
39. widget_title <-- archives.php(26)
40. widget_title <-- authors.php(26)
41. link_category <-- bookmarks.php(145)
42. widget_title <-- categories.php(26)
43. widget_title <-- pages.php(26)
44. widget_title <-- search.php(26)
45. widget_title <-- tags.php(26)

WordPress.org的官方插件目录最大的问题，也是最常被抱怨的问题，就是那令人恶心的搜索。

以后不会再这样了。我们现在使用了Sphinx（一个“免费的开源的SQL全文搜索引擎”）来加强官方插件目录的搜索，无论是从官方网站搜索，还是从你WP的后台搜索插件（插件→添加新插件），搜索体验都会得到提升。

现在，搜索功能更棒了。虽然还存在着一些奇怪的小问题（我们的错，不是Sphinx的），当然我们会在短期内修复的，但是能让每个人用上它，我们十分高兴:)。

目前，只有插件的标题、描述、安装、FAQ等等来自readme.txt的字段被索引，不过，我们很快会补充完整的，包括作者和tags等。

译注：刚才体验了一下，确实提升很大，当然，这是由于原来的搜索实在是太烂了！现在，输入以空格分隔的多个关键字，也可以得到相对准确的结果了，结果列表的相关度还是非常大的。

子主题，就是指，以另一个已经存在的主题的页面元素结构和功能为基础，创建完全自定义的样式，和附加功能。而在制作过程中，完全不修改另一个主题的代码。而“另一个主题”在这个过程中，就自动成为了“父主题”。

/*
Theme Name: Rose
Theme URI: the-theme's-homepage
Description: a-brief-description
Author: your-name
Author URI: your-URI
Template: use-this-to-define-a-parent-theme--optional
Version: a-number--optional
.
General comments/License Statement if any.
.
*/

上面一段代码，我想每个主题制作爱好者都不会陌生，这是存在于style.css头部的一段注释，WordPress使用这段信息，加载一个主题。其中的Template，就是在制作子主题的时候用于说明父主题的字段。具体在制作一款子主题的时候，只要将Template:hybrid填写到style.css的头部，就可以使用Hybrid作为父级主题了。当然，这个说明同样也适用于其他主题框架，或者任何一款主题（不推荐使用普通主题作为父级主题）。

创建子主题，就相当于站在巨人的肩膀上，你要处理的文件数量非常少，一般来说只有两个就够了，一个是style.css，另一个是functions.php。style.css的作用是用于说明子主题的外观样式，而functions.php的作用，是用于附加原来父级主题所没有的功能。

这里要做一个特别说明，就是关于文件加载的顺序的说明。如果你制作了一款子主题，那么WordPress在加载的时候，首先加载的是子主题的functions.php然后才是父级主题的functions.php。这意味着什么呢？在Hybrid的functions.php里，使用add_action函数挂载了非常多的东西，根据Hybrid主题框架综述的说明，几乎所有的页面内容，都通过action来挂载。那么如果有哪部分内容，你不想要，或者你想替换成你自己的，那么你是无法直接在子主题的functions.php里面实现卸载的。你能直接操作的，只是挂载，而不能卸载。那么非要卸载是不是没有可能了呢？也不是。这里给出一个方法，首先，创建一个函数，action_to_remove，然后在函数体内写好你要卸载的action，然后将这个函数hook到全局的action init 之上，就可以实现卸载了。代码如下：（什么是Hook？什么是Action？）

add_action('init','action_to_remove');  function action_to_remove(){    remove_action('hybrid_header','hybrid_site_title');  }

通过上述代码，我们移除了Hybrid主题中的title部分。其实，这个问题也有其一般意义，因为当你想要移除一个action的时候，这个action根本还没有被add过，那么你的移除动作是无效的。以后如果有必要，我会专门撰文介绍这个问题。

上面两段，对于插件开发爱好者来说，可能非常容易理解。一般同学如果不理解，没关系，直接跳过就ok了，毕竟Hybrid没有往主题里挂过多的不必要的东西，一般情况不需要移除任何东西的。

这里总结一下，创建子主题的过程：

1. 在wp-content的themes文件夹下，创建一个文件夹，用作子主题的目录，如my-custom-hybrid。
2. 在my-custom-hybrid目录里，创建两个文件，一个是style.css，一个是functions.php（可以不要这个文件）。
3. 编辑style.css文件，在头部按照上文的格式，撰写注释信息，在Template后面，填上hybrid。
4. 在style.css文件内部，使用CSS语法，创建你自己的样式。
5. 在functions.php内部，添加一些功能，或者嵌入某些插件。

到这里，如果你真的看明白了，想要动手制作了，那么我还要再推荐给你一个非常好的东西。制作一款子主题，并非必须从0开始，也即从一个空白的style.css开始。Hybrid的作者非常贴心的创建了一个子主题skeleton，就是为了给广大主题爱好者创建一个良好的基础。该子主题的style.css文件，按照页面元素的层次结构和出现顺序，罗列了所有的class名称和id名称，比如，导航条部分的代码样子如下：

/**

* Page navigation

************************************************/

/* Wrapper for navigation */

#navigation {}

    /* Page nav */

    #page-nav {}

        #page-nav ul {}

            #page-nav li {}

                #page-nav li a {}

            #page-nav li.current_page_item {}

瞧见没有？是不是结构非常的鲜明，一目了然呢？下载地址。

好了，今天就介绍到这里吧，下次，将要撰写《Hybrid资源一览表》，欢迎大家继续关注！

Hybrid 是 Justin Tadlock 开发的一款主题框架，该框架功能非常强大，下面简单罗列一些。（该列表原文来自原主页，其翻译来自上善若水。）

• 如同 SandBox 主题框架一样，用户可以自定义主题样式；
• 内置了基本的 SEO 选项，基本可以取代 All In One SEO Pack 之类的插件；
• 拥有一个完备的主题选项；
• 内置了常用的13个页面的模板，用户可以利用这些模板来完成许多事；
• 自 WordPress 2.5 版本至最新的 2.7 版本全兼容；
• 原生支持至少15个插件；
• 附件处理功能；
• 迷人的 Tab 式位置导航变体 菜单；
• 基于 960 GS、Blueprint 和 Tripoli 相当可靠的 CSS 样式；
• 可以建立各种样式的站点；

Hybrid 是一款名副其实的“框架”。其整体架构，就是一个良构的XHTML布局，具体来说，就是一个页头，一个页面内容容器，里面分为主要内容，侧栏等；然后是页脚。除了一个最基础的DIV+CSS的XHTML布局之外，剩下的就是Hook，在上述基础布局中，所有可以插入元素，或者有必要插入元素的地方，都带有WordPress的Action。

当然，Hybrid除了是一个框架之外，它还是一个主题。Hybrid主题本身，就建立在其自身搭建的框架之上。为什么这么说呢？因为一个博客模板里，所有最为基本的东西，如<head>标签内部的一些meta tags，博客标题，站点描述，页面导航，侧边栏，页脚版权信息，等等等等，绝大多数主要内容，也即除了“骨骼”之外的那些“肉”，都是通过action来挂载的。既然是挂载上去的，当然也可以摘除。

Hybrid框架最适合作为开发子主题的基础，因为该框架本身布局灵活，通过框架内部带有的action，子主题作者可以从原本基础上摘除任何不需要的功能块，同样也可以挂载任何自己开发的功能块。这一系列的操作，都不需要对Hybrid本身动手术，这保证了Hybrid框架的完整性，为日后升级提供了极大的方便。

上手Hybrid，一定要有框架思维，把它当成一个真正的框架，才是正确的用法。（写给程序员：你在编程时有想过修改.net framework或者MFC或者JFC或者STL的代码吗？答案如果是没有，那么你也不需要去修改Hybrid的代码。）我这里这么说，主要是想告诉一些希望定制Hybrid框架的朋友，直接DIY Hybrid的源代码，是不被禁止的，但是Charles个人及其不推荐的。Hybrid虽然是一款非常优秀的主题框架，但是其目前版本只有0.4.1，其内部代码还有至少3处被标记成under active development，整个框架还处在活跃地开发状态，保持随时升级非常重要。

未完待续

下一篇，拟介绍《使用Hybrid的起点》，欢迎给位在下面跟帖讨论，并给我提供写作建议，谢谢！

Hook机制（就是指Action和Filter的机制）正是WordPress能够有成千上万的插件支持的根源。

尽管我以前可能写过类似的文章来说明这个问题，但是我觉得这个东西是如此的重要，以至于如果你还没有明白什么是Hook，根本算不上走进了WP开发者的世界。又或者说，作为一个普通的玩家来说，深刻地理解Hook，能够帮助您走上DIY博客高速车道。

Hook这个东西，说难吧，很难，说容易吧，很容易，还真的不好解释。我不能保证每个看完这个文章的人能懂，知道个大概就行了。现在，我们开始。

我相信，很多像我一样的80后，会在高中的时候对编程感兴趣，你们很可能选择了一个东西作为入门，那就是Visual Basic（VB）。在VB里面，编程变成了一件非常容易的事情，画一个界面，然后这个界面上的元素会在某个事件发生的时候，触发一个函数，在这个函数里，写好你要做的事情，一个Windows桌面应用就完成了。

这种编程的模型叫做事件驱动。你们一定会写一堆叫做OnButtonClick，OnSomethingDosth之类的Sub，具体的意思，就是说，当一个按钮按下，这个事情发生的时候，执行OnButtonClick这个Sub里面的代码。Ok，我想说的就是，在WP里面，就是一种很类似的东西，一个插件的代码，就好比是OnButtonClick这一类Sub里面的代码，而我们的主角hook（可能是一个action，也可能是一个filter，比如post_content，又比如wp_head），就是一个能够触发那段代码的事件，一旦发生，插件就会开始运行。希望到这里，很多学过VB的朋友能有个认识了。

接着，时代发展了，OO，也即面向对象大行其道了。学OO，就不得不学一点设计模式了，否则，怎么敢说自己在面向对象呢？如果你碰巧看到过一个模式叫Observer的，那么我愚蠢地以为，可以从一定程度上解释hook机制。把整个WP，看作是一个对象，这个对象最终要打印一个网页出来，这个网页会按照PHP代码的先后顺序，一块一块生成，每个插件都分别是一个对象，非常关心它自己要处理的那一小块网页，它们就是各自关心的那一小块网页的观察者们。在WP初始化的时候，这些插件们就把自己添加到观察者的队列里面（即add_filter或者add_action），而它们观察WP内部的这个窗口，就是action或者filter，WP在执行到特定的时候，就会通知这些插件，某个事情发生了（即apply_filters和do_action）。

抽象过后，来一点形象的东西。我又要使用我那不着边际的比喻了。想象一根电线，上面串连着一个接一个的插座。每个插件就是一个小家电，有一个插销，他们被各自地插到了合适自己的那个插座上。然后，电流从这个电线的一头流入，每经过一个插座，这个插座上连接着的电器就开始运转了。所有电器都通电运转了一遍以后，电闸关上了。Ok，这些插座，就好像是hook，有的是action形状的，有的是filter形状的，但是本质上就是插座。

好了，我已经废了很多的唇舌了，我心里很清楚，结果可能是这样的，不理解的人，依旧不理解，理解的人，不用看就理解。虽然是这样，我还是执着地想要尝试着解释一下，因为我后面要写一个介绍Hybrid的文章，这个主题框架里面遍布着action和filter，如果不理解这个东西，无论如何也不可能用好Hybrid，同样，要说清Hybrid这个东西，无论如何也躲不过地要说一下hook。毕竟我还是想受人以渔的。

从NetBeans官方网站下载IDE

打开NetBeans的官方网站，点击Download，可以看到下载页面，如果没有其他的开发需求，选择for PHP的版本即可，大小只有26MB。

上面的语言选择框，大家不要费神去选了，我试过了，选择English和简体中文，下载下来的东西都是同一个，都是Multi-Language版本，而且安装的时候，不可以选择语言，NetBeans会根据系统的语言设定，来自动选择语言。据说可以通过修改配置文件的方式来更改界面语言，想用英文的同学，请自己Google之。

运行NetBeans IDE需要java虚拟机，如果需要开发java的同学，可以只下载JRE，很简单，打开http://java.com，下载即可。有些像我一样，想要以防万一的同学，可能想要安装JDK，那么下载地址在这里。我给出的链接是JDK 6 Update 11 for Win版本。

先安装JRE（或者JDK），然后再安装NetBeans IDE 6.5。下面的图是NetBeans装好启动后的样子。

将WordPress导入到NetBeans中

要开发WordPress的插件和主题，需要将整个WordPress作为项目导入到NetBeans中。

步骤1：选择项目。“文件->新建项目”，然后选择PHP项目里的“基于现有源代码的PHP应用程序”。

步骤2：名称和位置。在源文件夹中填入本地WordPress所在的目录。填入项目名称，可随意。其他如上图所示即可。

步骤3：运行配置。填入项目URL即可，为了在本地调试，一般会填入本地地址如http://localhost/wp27/。其他如上图所示。

使用XDebug进行调试

NetBeans支持PHP的调试。调试功能需要XDebug的支持，这是一个PHP扩展，你的服务器上可能已经装了，也可能没有装，不过，安装起来非常方便，对于Windows下的用户来说，只是下载一个DLL文件，然后拷贝到指定的目录即可。

1. 到这里下载XDebug，注意匹配DLL与PHP的版本号。在链接里的网页上，点击obtaining，进入下载页面，鼠标放在下载链接上，可以在状态栏看到将要下载的文件名。php_xdebug-2.0.x-5.x.x-xxx.dll，后面一个是PHP的版本号，要与你安装的版本相符合。（PHP版本可以用phpinfo()来查看）
2. 下载后，将DLL文件拷贝到PHP扩展文件夹，一般是/php/ext/下面。
3. 修改php.ini文件，这个文件的所在一般取决你php是怎么安装的，可能在system32里（bin安装的用户），也可能在php根目录下（使用zip安装的），也可能在apache/bin/目录里（使用xampp的用户），注意，一定要找到起作用的那个php.ini，这个也可以在phpinfo()里面看。添加下面的代码。
[xdebug]
zend_extension_ts="D:/xamp/php/php5.2.5/ext/php_xdebug.dll"
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
4. 注意：上面的代码段，可能php.ini里已经有了，而是被注释掉了，那么你去掉上述那几行字的注释就可以了。另一个注意点，[xdebug]段的配置和[zend]段的配置不能共存，否则apache启动不了，添加了上述代码，如果启动不了apache，那么查找是否存在[zend]段的配置，然后注释掉，我是XAMPP安装的环境，就碰到了这个问题。
5. 重启WebServer。

做过上述操作后，NetBeans就可以感知到调试器的存在了。

一般项目开发

我们已经将wp2.7的所有文件都导入到了NetBeans里面，那么具体开发一个插件项目，或者主题项目的时候，我们可以在项目面板上，将某个插件的根目录，或者某个主题的根目录使用如下方法添加到收藏夹，以后就在收藏夹面板下工作即可。

收藏夹完全可以充当项目开发面板的工作。下图就是添加后的效果。

配置项目运行

一般，调试主题或者插件，都是某个特定的页面，比如归档页面，静态页面，或者某个单篇日志页面。如果只是主页，那么默认的设置即可了，如果不是主页，那么需要指定启动参数。大家可能习惯了修改永久链接后的WP的页面地址了，但是那个在调试环境下行不通，必须还原到query string的模式。

从上图菜单中打开对话框，配置方式如下：

注意上图中红色框框里的部分，这个例子就是指定显示id为289的页面或者日志。

设置好运行设置，调试时也会使用这个参数。

调试的时候从调试菜单进去，打开调试对话框，如果只需要调试PHP的话，选第一项，如果还需要调试Javascript的话，选第二项，可以选择你喜欢的浏览器。（有些平台上不能选，Win上面没有问题）

使用FF，初次选择Javascript调试，会要求安装一个FF插件，装上即可。

好了，作为一个简要的介绍，就写到这里了。

后记：上述内容，并非完全翻译，只是遵循了原文的条理，大部分内容都是我个人的感受和体验，当然，图也是我自己重新截取的。NetBeans作为一款PHP的开发工具，与Eclipse版本的ZendStudio相比，更加的平易近人，比较简单，没有很多复杂的选项，与UEStudio相比，智能化更强，集成的功能更丰富，而且可以和浏览器联调。

这两天，都在使用NetBeans作为环境开发插件，觉得真的很不错。尤其是在WP下，NetBeans会自动对所有代码文件建立索引，你在某个函数上单击，该函数会被高亮，然后用Ctrl+B或者右键菜单，可以直接跳到函数的声明，非常的方便。仅有的一个小缺点是，NetBeans无法对PHP内建函数使用有区别的高亮颜色，不过大家对PHP的内建函数应该也比较熟悉了，再加上，你在内建函数上Ctrl+B，也可以跳到一个类似C语言H文件的文件里，可以直接查看这个内建函数的函数头和说明，都省了查阅手册的时间，也算是弥补了那个小缺点。

还有一点我比较欣赏的，就是NetBeans支持代码重构，可以自动格式化，支持javadoc格式的注释风格，使用这个编辑器可以创建非常优美的注释格式。最后，这个基于java的IDE当然也是跨平台的，以后可以一直用下去了，嘿嘿~~

赶快试试吧！祝大家新年好运~~

2. 原本，这是我想做好了发布的一款主题。

3. 最终我没能做好，很抱歉。

4. 主题处于开发状态，未完成。

5. 主题里面融入了我的一些理念，可能看起来很奇怪。

5.1 使用了Yahoo！YUI 框架，所以叫YUI Theme

5.2 使用了CSS文件和JS文件的合并压缩

6. 没有Web开发经验的同学，可能定制起来很困难。

7. 支持侧边栏插件。

8. 有问题的同学，在下面跟帖。

9. 我最近很忙，如果问题很简单，我会尽快回答。

10. 如果问题很麻烦，我可能不会回答。

11. 里面有很多我的定制，请自行修改

11.1 Google自定义搜索请替换掉

11.2 Google Friend Contact请替换掉

11.3 footer里的统计代码请替换掉

下载地址

祝大家好运~~

然后就是Reader里面看到无数的童鞋已经升级上去了，然后很多人汇报了各种个样的问题，不过大家看来还是热情很高涨的~~

说说我注意到的两点，一个是永久链接那里，WP自动生成的post-slug现在不会把中文给变成%xx的形式了，哈哈，看上去很爽！

再来谈谈插件兼容性

很多童鞋都提到了，Simple Tagging的那个相关插件是个骗人的玩意！没错！是这样的，那个插件于07年10月停止更新了，不知道大家有没有注意看那个Last Update，唉~有时候英文还是有点用处的……

值得称赞的是Simple Tags的作者火速更新了插件，现在我已经使用的是新版本的了，很爽~~

另外一个值得称赞的是Ozh大牛，他的Admin Drop Down Menu插件在升级后会导致导航条无法出现，很多人只好弃用，殊不知，Ozh大牛也是火速将插件升级到了3.0版本，而且增添了超酷的特性，比如导航条颜色可以改变！

安装了Ozh' Admin Drop Down Menu后的效果

我还是继续使用Ozh的Admin Drop Down了，觉得WP 2.7的那个东西虽然好看，但是不符合我的习惯，还是用原来的插件延续原来的习惯比较好。

最后，批评我自己一下，终究没有跟上大牛们的脚步，WP Kit CN无法以一个全新的面貌跟大家见面了~~过段日子会放出来吧~~哈哈，不过好在我的插件用户不是很多了，毛估估在150~200人左右，呵呵……（大家闲得没事推广下撒~~~）

有的朋友已经发现了，插件里面多了两个template tag，一个是输出相关文章用的，一个是用于输出同分类下文章用的，这两个函数也是因为实际需要才添加到插件里面的，不过，还有一些小问题，所以暂时不公开了，有把握的同学可以自己调用一下试试看，有问题可以使用本站Contact页面向我汇报~~

I built this plugin for one of my friends. But she is now not using it. So I have no reason to improve it.

I put it here and I hope someone will find and like it.

This plugin is just a simple slideshow sidebar widget, the photos it use is in one of your Picasa photo albums.

Ok, you could see the LIVE DEMO here! On the right side, it shows a lot of beauties.

Download Here

If you have any questions, please contact me through the following form:

cforms contact form by delicious:days

今天凌晨，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功能一开始也是相当地烂，后来也渐渐改好了。我想评论部分也会如此的。

一直以来想给自己的博客添加联系表单功能，但是一直也没有碰到好的插件，直到在后台的最流行插件推荐那里，看到了cformsII，一款强大无匹的表单插件。cforms意思为custom forms，就是自定义表单的意思。

这款插件的主要功能有：

1. 设定自定义表单，允许插入到页面，日志中去；

2. 非常强悍的表单定制功能，支持各种表单域，可添加验证码，Ajax提交；

cforms定制表单的界面

特定表单的属性设定界面

3. 可以取代WP的评论表单；

4. 集成了Tell-A-Friend的功能；

5. 强悍方便的后台管理界面；

丰富的自定义功能

在某个页面或者某篇日志插入表单是很轻松的

6. 无比丰富的文档；

第一次看到在插件内部带有如此详尽的帮助

插件主页 | WP插件目录 | v9.3版中文包下载地址 | v10.0版中文包下载地址 | v10.3版中文包下载地址 | v10.4版中文包下载地址 | v10.5版中文包下载 | po文件下载地址

关于中文包的使用说明：

中文包的目录结构:

使用plugins作为跟目录，意思就是想告诉各位，使用的时候要把cforms-zh_CN.mo直接放在wp-content/plugins目录下，而不要放在插件目录内。

特别附加了一个插件目录内的cforms-admin.css，该文件不是必须的，但是用这个文件替换了原来的文件后，会使后台看起来更加舒服一点，因为原来的英文后台字体设定得特别小。

Updated:改插件目前升级到了9.3版，而中文包是针对9.2版本制作，经检查，只增加了一个短小的字符串（Title：标题），所以不对中文包进行更新了。

Updated:插件升级到了9.4版本，字符串基本上没有变化，大家可以继续使用v9.3的汉化包~~

Updated:插件升级到了10.0版本，增加了一个多页表单的功能，字符串更新74处，请升级到新版的同学更换语言包~~

Updated:2009-2-21 15:55:01：插件升级到了10.3版，字符串更新了近30处，请需要更新的同学自行下载~~

Different Posts per Page的管理页面截图

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

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

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

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

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

插件页面 | 官方插件目录

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

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

第一次看到这个功能是在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搜索的详细步骤，包括申请，修改代码，等等，并且给出了代码范例。可操作性很强。

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/

我现在的主题叫做yui-theme，我想，这是我对主题内部构造的设计的一种追求，我希望能把我学到的所有的最先进的技术都用在这个主题上。

当然，现实和理想总是南辕北辙。

首先说说，我进行了哪些尝试吧。

1，css和js文件合并。将模板用到的所有css文件写入同一个文件引入模板。js文件同理。好处就是在相同流量的情况下，节省了http请求数量。当时我在中间引入了gzip压缩，而实际在本地测试的时候，觉得js文件经过压缩的话，页面占线速度会被拖慢3s以上了，可能是本地的服务器性能问题，反正最后是把js的压缩取消了，保留了css的压缩。

2，css框架，这个模板使用YUI的css框架来设计，这是我第一次使用这样的框架，因为对于搞不定css的我来说，使用框架无疑是一种简便的选择。框架文件有好几个，一个是grid，一个font，一个base，除此之外自定义的css放到custom里面，分文件开发，合并引入，这时候也能体现文件合并的好处。

3，大规模应用jQuery，我为这款模板设计了各种个样的jQuery小功能（当然，现在没实现几个）。使用jQuery的指导原则就是，非入侵式，也即，完全不让代码出现在html里面，只使用外部文件；保证可访问性，也即，如果js失效，页面损失的仅有美观，而不损失功能。

目前，这个模板开发完成度在10%左右，即便如此，也是耗费了我好几周的精力，以至于都没有任何继续下去的激情了。所以，我迫不及待地自己先用上了。

然后说说，模板设计过程中遇到的问题：

按照yahoo网页性能提升的最佳实践，应该在页面最底部引入js文件。我实际上就是这么做的，但是这个是有问题的。因为，关键问题就在于我使用了类库，类库是应该比所有js文件都早地被引入到页面，而我只能保证我的模板里先后顺序，而插件里的js一般会被hook到wp_head里面去，所以，总是会出现在头部，顺序乱了，肯能导致js失灵，所以现在不得不重复地在页头也引入了一个jquery，这就是浪费了。

使用文件合并来减少http请求，这个东西同样是很好的尝试，但是这又和wp的结构有关，很多插件又是很随意的在wp_head里面插入外部文件或者直接写代码，根本没有办法把这部分文件合并，这使得这个尝试也变得很鸡肋。曾经在wp的trac里面看到过有人提这个问题，解决这个需要全新的架构。我个人觉得需要全新的机制类支持这个功能。

我其实还为这个模板准备了很多好玩的小功能，但是现在都处于未完成状态，唉……好懒啊……

好久没写技术日志了，记下这几点感受以充数。

期待自己下一轮欲望高涨时刻的来临。

又好久没有写博客了，不过，我确实一直没有离开WP的阵营，每天还在坚持着折腾一下WP，哈哈。由于我又开了一个生活日记类型的博客，所以，这里，我就打算只写些跟WP有关，跟技术有关的东西了。而这些天一直没有更新这个博客的原因，我只能说，有一些与WP相关，但是更加激动人心的事情让我着迷。

终于，又有一个老外朋友碰到了播放器插件不兼容PHP4的问题，让我下定决心把这个问题给解决了。今天，花了好多时间，我终于把这个问题给处理掉了，并且在PHP4.8.8上测试通过了，当然理论上是支持PHP4.3.0以后的版本的。

主要更新：

1. 支持PHP 4.3.0 以后的版本；

2. 将播放列表移动到了wp-content目录下，这么做的原因是，下次再有升级的时候，你原先设定的播放列表不会被覆盖。

更新时间：

3天后吧……

我希望使用这款插件的国内朋友都能看到这个通知，提前备份好自己的播放列表再升级，不然的话，播放列表会被覆盖。外国朋友，唉……，我就照顾不到了，实在抱歉啊~~主保佑你们。

当然，没有看到这个通知的朋友们，主也会保佑你们的……

看到通知，不想等待自动升级的朋友，下载链接：

http://downloads.wordpress.org/plugin/flash-mp3-player.zip

与老肥同来的是Mark，他们是校友，于是就聊了起来，好多零零碎碎的话题，记得也不清楚了。

后来Matt来了，老肥上去合影，未遂，倒是Matt很喜欢他的登录框衬衫，给他来了个单人照，哈哈^_^

后来就是几个演讲，说实在的，挺没劲的，Matt显然不在状态，后来吴海林gg说他头天3点才睡，估计时差没倒过来。他说话声音很轻，速度很快，我这听力水平，充其量也就是听懂了60%。简要介绍了下WP的历史和现在的开发情况，我们不知道的东西到也比较少，哈哈。

然后是吴海林大哥的演讲，说实在的，那是相~当~的~无聊。讲的内容是开源什么的。有点哲学的味道，但是我这种粗人是很难喜爱的啦。倒是后来Xiaowan Hong的简短的秀很不错，展示了好几个他自己已经做出来的正在做的WP应用，还稍微有些启发性。

后来72松的互动环节还马马虎虎啦，就是根据描述猜牛博。不过，他报出来的牛博，我基本上都没听说过，话说是我自己太土。还有就是他们的奖品忒土了！！！！什么什么券……囧rz。

最后上个Photo Slide，哈哈……

以前，由于一个我也搞不清楚的原因，WP会把WP Kit CN中的热评文章Widget和高级友链Widget认为是两个单独的插件，导致这两个Widget在加载前，就被WP认为是已经加载了，最后结果就是没法在后台出现。

WKC Clear的作用就是把这两个非法注册到系统，但是实际上又不存在的两个插件给清除掉的工具。按照我原来的设想，这个插件启用后，后台就会出现6个Widget了，可是实际的结果是，启用这个东西后，热评文章和高级友链就肯定出不来了，但是再把WKC Clear禁用掉，6个就会都出现了。也就是说，这个东西的使用方法就是先启用，再禁用。

如果同学们在使用过程中，有什么不一样的情况，可以跟此贴来汇报~希望这个东西能帮大家解决问题。

最后，如果没有出现过Widget神秘失踪的同学，可以无视WKC Clear。下个版本将不会带有这个东西。

但是，缓存也有一定的弊端。如果您的CSS文件已经更改，但是浏览器不知道，而缓存下来的CSS文件也没有过期，浏览器仍旧会使用缓存中的CSS文件，也就是旧的样式。

当然，很多有经验的用户都知道，只要使用Ctrl+F5，强制刷新浏览器，就可以让浏览器下载新的样式表文件了，但是作为一个博客网站，你不可能让你的每个用户都去自己Ctrl+F5一下，很傻是不？

其实，解决这个问题是很简单的，以前，我就在网上看到过，是为了解决js文件的缓存问题的，js也有相同的问题。要说解决之道，到是非常的简单，因为如果请求css文件，或者js文件的链接变化了，也即url变化了，浏览器就会认为，这是完全不同的两个文件，就不会使用缓存中的文件。所以，只要改变url，就可以让浏览器强制更新缓存了，当然，每次换url也很麻烦，我们一般使用的办法是给url添加一个query string，比如，原来申请的是：

<link rel='stylesheet' href='http://localhost/wp25/wp-content/default/style.css' type='text/css' />

和

<script src='http://localhost/wp25/wp-content/default/custom.js' type='text/javascript'></script>

现在变成：

<link rel='stylesheet' href='http://localhost/wp25/wp-content/default/style.css?120012022' type='text/css' />

和

<script src='http://localhost/wp25/wp-content/default/custom.js?12345678' type='text/javascript'></script>

就是在后面跟了一串数字，我的页面用的一个json，因为每次都要重新下载，所以，我在请求的url链接后面，带了一个随机数，这样，每次浏览器都会认为，这是一个全新的文件，都会去下载。

当然，大多数情况下，是不需要每次都下载，也即在站点没有更改自己的css文件和js文件的时候，浏览器要使用缓存，而更改了后，所有浏览的用户就要自动下载。最好的办法，就是用文件修改的日期来做后面那串数字，既保证了用户那边的效果会实时更新，又保证了能够使用缓存这种机制。

前两天看到个小老外，写了篇文章介绍这个东西，WTC竟然也推荐了，原来这个方法竟然如此的不普及啊~~小老外的文章看这里，讲得和我说得是一回事：

Smart cache-busting for your WordPress stylesheet

达人Matt给他提了个建议，让他使用filter来实现这个，这样，每个主题都会因为这个而受益。结果这个小老外就去写了一个插件，叫做CSS Cache Buster（点击链接，查看插件页面，下载插件）。

我本来以为这个小老外这两天迟迟没有动手呢，我就先写了一个，结果发现小老外竟然Updated了，只是我没有看到，赶快把他的插件下回来看了下，发现小老外写的东西用的filter没我好，他不直接，他用了bloginfo_url这个filter，而我直接用了stylesheet_uri这个filter，比他少了一次判断，但是小老外也有优点，就是他考虑了别的插件已经添加过query string的情况，而我没考虑，可见我的经验尚浅，或者说我还是不够勤劳，总之，自我感觉有那么点败给小老外了……

感兴趣或者经常喜欢修改style.css的同学请安装他的插件吧，可以少按很多次Ctrl+F5呢，嘿嘿

下面放上我写的代码，权当是一个纪念吧：

一个博客的侧栏作为一个提供辅助信息的区域，其实，是一块非常重要的区域。好些博客，喜欢在这里放各种各样的东西，简单列举一下，有加强博客页面SEO，向读者暴露更多入口点的，如最新文章，点击最多文章，随机文章等等；还有增加博客社会化的，如订阅图标，最新评论，评论最多用户等等；此外还有很多有意思的小挂件，像歌曲，search bar，统计之类的东西，当然还有广告。

但是，不知道大家有没有意识到这个问题，很多主题的侧栏，基本上一成不变，上篇文章也说了，WordPress的页面分成好几类，首页，文章页，归档页，搜索页，404等等，那么这些页面，根据其功能来说，使用完全相同的侧栏，是不是真的很妥当？

我最早是在Andor的WordZine和阅微堂体验到了根据页面种类来定制侧栏的妙处，我想，这两个站点的主人一定在这个地方动过很多脑筋和做过一些有意的思考才这样做的。

在WordZine的前身theme paradise，我看到帖子页使用侧栏来输出评论（是本文的评论），其实这个在别处也看到过，就是cnBeta，侧栏顶上输出最热评论，但是这个功能第一次在博客看到，竟然那么惊艳，很新颖。那个时候，theme paradise的主页侧栏输出的是Aside，就是一些文章的摘要，那个模板显示最新第0-第3篇文章全文，在侧栏输出第4-第8篇文章的摘要，然后底部多了底栏，输出其他内容。

而阅微堂（当然现在也已经改版了），首页侧栏输出三个文章列表，而在侧栏输出了相关文章，具体我记得不清楚了，当时，我就觉得，哇，侧栏变掉了。

当然，同学们可能已经发现了，我现在这里的博客也使用了不同的侧栏。如果感兴趣，你可以发觉一下，我的侧栏到底有何不同。我就不讲了。当然，我也只是一个尝试，欢迎大家对我的做法发表你们自己的看法。

然后我来讲讲，怎么实现这个不同的sidebar。对于手写侧栏的人来说，这个事情恐怕要简单得多。

这个模板标签大家可能很熟，用这个，就会自动去调用一个叫sidebar.php的文件，将这个部分加入到你的页面。其实，这个函数可以接受一个参数，就是sidebar name，可以调用sidebar-name.php文件到页面中，如果这个文件存在的话。

比如我的模板里，有sidebar-404.php，sidebar-single.php，和sidebar.php。我的帖子也，使用的调用就是get_sidebar('single');我的404用的就是get_sidebar('404');，这样，就在不同页面得到了不同的侧栏。

而对于使用Widget的同学来说，这个事情恐怕就要复杂得多，很有可能，目前，你们有没有能力实现这个做法。这就需要我们这些做插件尤其是做Widget的和做模板的来付出努力了。

1. 模板要支持多sidebar，像我说的那样，每个页面有对应的sidebar文件，而且，每个页面不是同一个sidebar。

2. Widget要支持多instance，就是一个Widget要具备多次插入到边栏的能力。

哎呀，一不小心就洋洋洒洒地说了一堆，不知道大家对这个东西都有些什么看法啊？欢迎交流~~

这张图解释了WP从用户给出query到最后调用正确的模板文件来产生页面的一个过程。从图中我们可以看到，WP一种支持13种模板文件。那么这十三种模板文件中，到底哪些才是必须的呢？

相册：illustration

1. index.php

可以看到，只要对应的模板文件找不到，最后都会调用index.php，只有这个文件是逻辑上必须的，如果没有，模板根本不能加载。

2. single.php

此文件从逻辑上不是必须，但是一般的主题都会带有这个文件。究其原因，就是单篇帖子页面和主页，有着非常大的不同，这个页面上与首页最重要的不同，可能就是评论展示了。

3. page.php

这个文件也是一般主题常带有的，这个是页面文件的模板。那么页面又有哪些不同呢？页面作为一种常设的Post，其发布时间可能并不是那么重要的，因为这个页面一经发布，就长久存在，不过，我个人倒是认为，虽然发布时间不重要，但是更新时间确实在某些情况下还是有必要的。比如我自己用页面来展示插件的文档，那么这个文档的更新时间能够向用户传达文档的时效性，所以，我觉得，在页面展示更新时间，是否应该作为主题管理面板的一个选项给用户选择。

4. pagename.php

这个文件不是叫pagename.php，而是说，这个模板文件也是page.php的一个变种，是page的slug来命名的，基本上，很少有主题会带有这个文件，不过呢，我觉得，国产模板的作者可以考虑带上这个文件，比如，很多博客都喜欢guestbook这样的应用，但是一般的模板文件page.php，往往不会带评论部分，作为一个模板作者来说，产生一个guestbook.php这样的事情完全是小事一桩。

5. archive.php

这个文件其实就是展示归档的模板文件，一般来说，主题里都会带有这个文件的。不过呢，从图中我们也可以看出，归档其实可以分成四个种类的，日期归档，分类归档，tag归档，作者归档。从功能上来说，划分那么细并非是必须的，不过呢，我想对于团队博客来说，作者归档里面带上照片和作者介绍，应该是很好玩的应用吧。而对于分类归档和日期归档，可以考虑给予一些辅助检索的措施，当然，这些都可以详细展开讨论，作为一个用户，您有什么新奇的点子呢？

6. search.php

带有这个模板文件的主题也不多，其实这个里面还是很有文章可以做一下的，不过呢，我暂时也没有很么好点子。比如在搜索页面嵌入一个google搜索，或者嵌入一个专门的带有类似suggesting那样功能的搜索框，都应该是比较好玩的吧……

7. 404.php

当找不到文章的时候，或者永久链接失效的时候，都会进入404。404又是一个大有学问的模板文件，前段日子，google黑板报在搞404代码专题周，google都如此重视404，可见其重要了吧。以前A List Apart也写过一篇《完美404》，给出了很多有效的建议。我想，作为一个主题作者，您是不是也考虑，在您的模板中加入一个非常友好的404呢？

8. attachment.php

到现在为止，我还没有见过哪个主题带有这个文件的呢，也可能我从来没有注意过这个问题吧，我现在的想法就是，那种专门展示照片，艺术作品的photolog，可以做一个美丽的展示单幅图片的image.php，哈哈……Updated: 哈哈，关于这个，大家可以瞧瞧梦色的文章，如何制作Gallery

========分割线========

以上都是一些我个人的想法，和我对一些模板文件的认识，难免有偏颇之处，还望大家指正。另外，写出来这个，也是想和大家讨论讨论的，哪些模板文件是您非常需要的，哪些又是您非常不需要的？

P.S. 与主题完全无关的内容，我发现Picasa Web竟然悄悄的改版了，好像更人性化了，在单幅图片浏览页面添加了上传按钮，而且图片的链接格式也发生了较大的改变，现在竟然用table来做容器了……

说白了，效果很简单啦，就是像本站右边栏那样的，看起来有点像FeedSky的统计图标。当然，那个颜色是可以调整的，后面的字也是可以调整的，完全自定义！！这就是Ozh的强大。

我篡改了啥呢？

咦？……为啥你的“评论徽章”上面的字是中文的？（高手当然不会好奇任何东西，飘过飘过吧）

我就是简单本土化了一下。

好，下面放出下载链接：

点击这里

用法是超级简单的，Widget嘛，没什么花头的。里面选项，要注意，如果用了中文，字体选“Simfang”（没错，这个字体我加的，是仿宋，因为体积最小，只有3M，你可以放个好看的雅黑40M或者宋体10M到你的fonts文件夹，在插件目录里面，字体自己去找）。

如果不想使用Widget，想用手动调用（为啥总有小强那么爱找麻烦呢？），可以使用如下template tag：

<?php wp_ozh_lcc_badge();?>

不过呢，选项设定就烦一点了：

1. 进入Widgets管理页面，添加Liz Comment Counter Widget；

2. 设置选项，保存；

3. 移除Widget，保存；

通过这个动作，你设定好了选项，但是又没有添加Widget，烦吧，如果你的主题正好不支持Widget，那么，是否需要我教你怎么做？？汗……提示一下，先换上一个支持Widget的主题，比如default……………………好冷~

Updated：

发现Jinwen写过这个文章的，唉，慢了一步，还好我汉化了不算啥都没干，大家去看看他的文章吧，很详细。

Smartr.cn：秀秀你的评论数

用简单的话来说，就是调用apply_filters函数。

然后，我们来复杂点说：

如果你调用了apply_filters('my_own_message', $mess);，那么，你就创建了一个名字为my_own_message的filter了。

那么这个my_own_message的含义是什么呢？按照我个人的理解来说，就是将来有一群接受一个参数$mess的函数，可以被调用。而且，就恰恰会在你调用apply_filters的地方被调用。

再举个不恰当的例子，就好像你是一个小朋友，你从你大款同学那里借了一个变形金刚，爱不释手，但是终于玩够了，要还了，又觉得还是不爽，这时候，你喊了一嗓子，“要玩变形金刚的排队过来玩，玩完还给那款爷”，小朋友们兴高采烈，但是秩序井然地过来玩了，当然，你们这么一坨人玩过了，那个玩意儿能完好无损的可能性也很小了，不是少了条胳臂缺了条腿，就是脸上多了两撇小胡子……最后，那可怜的变形金刚面目全非的回到了大款小朋友的手上……

你喊那一嗓子，就好像是apply_filters了，然后那些小朋友就是名字为“要玩变形金刚”这个filter上的函数，那个变形金刚就是那个传递给函数的参数，缺胳臂少腿，多了小胡子，就是这些filter们作用在变形金刚这个参数上的效果，最重要的是，这个变形金刚最终还给了那个大款小朋友，也即filter们必须要把拿来的东西返回去。

哈哈……又胡扯了一番……

举个例子：

下面是某主题的footer.php

然后，这是某主题的functions.php节选

好，我创建了一个filter了。

最后，思考题：

1. filter到底有什么用？

2. 对一个插件作者来说，filter意味着什么？

3. 对于一个主题作者来说，filter又意味着什么？

建议牛人出来重写sofish改过的那个Share This。

Alex King大大写的Share this基本上没有照顾到中文用户。

后来，经过sofish改写，我们有了非常适合中文博客使用的Share this 中文。

但是，这个插件有三大缺憾：

1. 这么简单的功能，居然动用了prototype，此类库尺寸达128k。

2. 在hook使用方面，没有进行优化，如果一般用户不知道，安装了这个插件会在每一个页面都引用一个prototype进来，汗 ，实际上只需要在single页面引入，更人性化的做法是根据用户的需求来引入js文件和css文件。

3. 完全应该改个名字重新发布，这并不是说对原作者不尊重，而是现在这个插件的代码看起来和原来的已经差别较大了，而且此插件进入官方目录，使用的是GPL协议，我们可以另立门户，这样使用此插件的用户就不必要收到升级的困扰，上次我误点了升级，直接跳到Alex King的版本上了。

希望能有人接手这个工作！

最后还是要谢谢写出这个插件的Alex King和修改它的sofish。

上面是我在论坛发的帖子，没有人响应我，囧……

其实，说的就是一直以来我想做的事情。

实在不能忍了，于是自己动手了，囧！

那个插件的sofish版本还有一个问题的，当时stephen跟我提出过的，就是点击一个搜藏链接的时候，应该采用打开新页面更加符合中国人的习惯。这次我也一并给改了。

好，我就不多说了，把我改的版本放出来给大家分享下吧。

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

建议：模板里已经使用了jQuery的人推荐用这个版本。

另外：jQuery也不是必须的，因为基本上没有用到相关度的什么特性，所以，建议使用纯js重写，囧！

有学习js的，jQuery的同学愿意尝试下么？

Updated:2008年9月2日21:28:37

调用方法没有变化，大家去sofish的那个页面看看调用方法吧，我懒得写了

不好意思，老打扰大家~

这次加强了一下recent comments相关的Widget和Template Tag。

可以使用这种格式指定列表项。

%gravatar%<a class="commentor" href="%comment_author_url%" >%comment_author%</a>: <a class="comment_content" href="%permalink%" title="View the entire comment by %comment_author%" >%comment_excerpt%</a>

All the %xxxx% tags you can use are included in the above example.

所有可以使用的变量都在上面的例子里面了，我想他们的含义应该是不言自明的。

如需帮助，再给我留言。

经常有这么一种感觉，就是看到很好看的主题，自己一装上，就觉得很难看。于是乎有了一种错觉，主题永远是别人的好。

针对这个问题，我来谈谈我的一些经验和迷惑吧~

很多英文主题其实不适合中文博客使用。

互联网上绝大多数主题都是外国人设计的，这里面又绝大多数是使用字母文字的设计师设计的，又绝大多数不支持多语言。所以说，官方模板主题也好，著名设计站点也好，很多主题都是看着不错，自己一用就效果很糟糕。我觉得，一般来说，外国设计师设计的主题，都要针对中文特性而优化，除非你写作英文博客。而这种优化的难度其实是很高的，需要的都是对细节的调整，字体，字号，行高，段间距，容器边距，有的甚至页面布局都要调整。

好些主题看着好看不中用。

现在的Web设计领域有好多先进的理论，当然我了解得是很少的，但是我还是想扯扯。一个就是SEO问题，不知道为啥，WP在这个领域一直做得很差，已经有那么多人都提出过了，那个title的顺序，应该是先出现文章或者页面标题，再出现博客名称，为什么过了如此之久，WP还不修改模板标签呢？所以，不懂这个玩意的设计师，弄的主题肯定是需要手动优化的。另一个是可访问性问题。简单说就是源代码布局，一般来说是页面最重要的部分要先出现，次要部分后出现。有的很烂的模板会设计成sidebar先出现，文章列表后出现。我不说这个东西的SEO有啥关系，我就告诉你一种情况，sidebar上往往会放一些widget，或者你手写也好，这里面调用到的代码往往不是WP的程序员开发的，而是不同的插件开发爱好者，一旦他们的代码刚好出了一点问题，那么……PHP是逐行解释执行的，那么如果sidebar在前面，解释到这里刚好出错，你的正文部分都不会出现了。但是，反过来，文章先出现，而sidebar就算崩掉了，用户还是从你这里得到了有用的信息了。

有好些主题过分简单。

好多主题，打开一看，就那么几个文件，不超过20个吧，其实WP对页面有着非常精细的区分，比如post，page，archive，home，search，404，可能还漏了一两个，我个人观点是一个好的主题应该关注细节，每个对应的页面都要有细节上的区分，事实上能做到这点的很少，往往是一个single.php 一个page.php，一个archive.php，其他的东西都用一个index.php给代替了。定制性也很弱，基本上functions.php打开就是一片空白，更有甚者连sidebar widget都处理不好。更别提后台自定义了。像K2和国内xuyiyang设计的那几个主题那么多定制功能的主题真是少之又少。

我的一点想法

现在，WP主题的这种现状，让我感觉到，大家真是简简单单地把主题当成一个纯粹的皮了。就像论坛里面的很多人说的一样，“皮”。作主题的，是做“皮”的。这些人里面，绝大多数都是一些艺术细胞不错，但是基本不懂编程的人，而WP的这种架构又决定了这样的人设计不出好看又强大的主题。而另一些做“皮”的，是程序员出身，他们做的主题很强大，往往规规整整，条理清晰，说难听了就是呆板，这类主题就往往不好看，但是强大。这样的两种人，使得现在的WP博客们陷入了一种状态，就是不懂编程的朋友，永远挑不到称心如意的主题，因为他们不会修改，不会定制。

改变这样的现状，其实应该不难，就是我呼吁主题制作者能够互相联合起来，发觉能力互补的搭档，这样的团队合作应该能出品真正的高品质主题。

WP主题，同样应该分成表现，结构，逻辑几个层面来认真设计。WP只提供了管理后台和数据库，还有有限的模板标签和hook，要在这个基础上建立的主题，是真正的UI，决不是一个简单的“皮”，还有“肉”，如果数据算“骨”的话。

紧急：好多同学升级到新版以后出现Fatal Error，我还在紧急处理。

如果老版本没有问题的话，建议退回去。

下载地址：

http://downloads.wordpress.org/plugin/wp-kit-cn.8.8.9.zip

现在最新版本已经到了8.8.28，主要改动就是在尝试解决Fatal Error的问题，希望勇敢的小白鼠去测试。我之所以说尝试，是因为我自己没有出现Fatal Error，所以我不知道问题在哪里，我只能猜测。希望看得懂我在说什么的同学，能告诉我灾难出现的方法。十分感谢！

现在已经有一个同学走出了Fatal Error的阴影了，参见 http://www.1sight.cn/?p=167。他文中提到的修改版本，就是目前的8.8.28版。希望出现此问题的同学试试看，有问题再跟我反应，我会保持密切关注这个问题。谢谢~

8.8.27 尝试去解决如下问题，解决的打钩：

1. 评论榜widget添加两个选项before和after——√

2. 摘要算法自定义“按照字数”“按照段落数”“综合控制”——×

3. 调查一下是否与wp-statistics冲突——×

4. 活跃评论者中要过滤掉PB/TB——√

5. 升级后，新的widget无法显示的问题——×

6. 热评文章增加“是否显示评论数”的选项——√

7. 最近留言用户应该可以控制数量——√

8. 允许关闭摘要算法——√

9. 升级后不会自动启用——×

http://wordpress.org/extend/plugins/wp-kit-cn/