事情的起因是插件中的一个函数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的开发环境
无觅

所以，作为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插件和数据库交互
无觅

我在研究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)
无觅

今天终于看到了这么款插件，但是，我这篇文章其实是想说，这个插件，我对它很不满意，对不起它灌了一个Simple的名字，插入这个按钮好麻烦啊，还要用php函数去写。

我觉得，这款插件可以有个很体贴的改进，就是增加在对shortcode的支持。这样，我不但可以在页面中插入捐赠按钮，也可以在任何一篇文章中插入捐赠按钮，你们说呢？

插件页面在这里

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

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支持，所以不用担心覆盖会出问题，可以恢复到上一个版本。

好，希望对您有帮助~~

您可能也喜欢：

使用NetBeans IDE 6.5作为WordPress的开发环境

建立WordPress测试环境

WordPress 开发资源

插件开发全攻略（05）---WordPress 插件Actions

插件开发全攻略（07）---构造一个WordPress插件管理员面板

无觅

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插件开发模板

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

您可能也喜欢：
使用NetBeans IDE 6.5作为WordPress的开发环境	WordPress插件开发实例--（01）	WordPress插件开发实例--(02)	WordPress:插件开发API（Plugin API）	插件开发全攻略（08）---构建一个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界的一代大侠，用上人人羡慕的，“与众不同”的主题。

谢谢！

您可能也喜欢：
手动调用Simple Tags输出相关日志	WordPress插件开发实例--（01）	使用Google AJAX Libraries API替换WordPress自带的js库	WordPress:插件开发API（Plugin API）	WordPress插件开发实例--(02)
无觅

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。毕竟我还是想受人以渔的。

您可能也喜欢：

插件开发全攻略（06）---WordPress插件Filter

WordPress插件：选项查看器

插件开发全攻略（07）---构造一个WordPress插件管理员面板

插件开发全攻略（03）---怎样获得WordPress插件的创意

插件开发全攻略（04）---WordPress插件的结构

无觅

从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当然也是跨平台的，以后可以一直用下去了，嘿嘿~~

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

您可能也喜欢：
[WP开发环境]在NetBeans中配置FTP	WordPress插件开发实例--（01）	插件开发全攻略（08）---构建一个WordPress插件用户面板	WordPress插件开发实例--(02)	WordPress:插件开发API（Plugin API）
无觅

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/

我有一个私人博客，目前使用的WordPress的development version，该版本可以提供WordPress的一键升级。各位WPer应该是有福了，不过呢，这个一键升级，却给我带来一点小麻烦。

我选用了default主题，而这个主题是WP的一部分，所以，每当一键升级的时候，就会使得我自定义的样式被覆盖>.< ，太糟糕了。两次，粗心大意，我于是乎决定，开发个插件，摆平它！

其实很简单的啦。上次，我们使用了一个filter，还记得不，是the_content。这次，正好，我们就用到了一个action。这个action叫做wp_head，是在模板的header.php加载接近结束时候触发的，具体位置视模板不同而有所不同。但是，有一点是确定的，就是wp_head，会在</head>标签之前被触发。

这个action的作用，就是专门在模板中添加插件需要使用的css或者javascript文件的。正好，我利用这个action，将我自己的自定义css文件给插入到当前使用的模板中。

贴点代码吧

很简短吧，真正的代码只有四行噢~~

我打算陆续将该系列的文章校对一遍，并且打算将这个系列里面的例子改写成自己的例子，这样，我可以对文章有更准确的理解。

这里，我罗列一下这个系列文章的目录吧。英文名字就是原文，底下的中文名字就是译文。

1. How to Write a WordPress Plugin - Introduction
2. 介绍
3. Seven Reasons to Write a WordPress Plugin
4. 编写插件的七个理由
5. How to Get Ideas for WordPress Plugins
6. 怎样获得WordPress插件的创意
7. Structure of a WordPress Plugin
8. WordPress插件的结构
9. WordPress Plugin Actions
10. WordPress 插件Actions
11. WordPress Plugin Filters
12. WordPress插件Filter
13. Constructing a WordPress Plugin Admin Panel
14. 构造一个WordPress插件管理员面板
15. Constructing a WordPress Plugin User’s Panel
16. 构建一个WordPress插件用户面板
17. WordPress Plugins and Database Interaction
18. WordPress插件和数据库交互
19. Using JavaScript and CSS with your WordPress Plugin
20. 在你的WordPress插件中使用Javascript和CSS
21. Using AJAX with your WordPress Plugin
22. 在你的WP插件中使用AJAX
23. Releasing and Promoting Your WordPress Plugin
24. 发布并推广你的WordPress插件

原来的目录页面在：这里

还提供PDF版本的下载哦。

中文版PDF下载（2008年12月22日11:57:51）

这篇文章将在上一篇文章《在插件中添加js和css》的基础上继续。

建立一个新的PHP文件

Devlounge Plugin Series插件已经有了如下的目录结构了：

• devloung-plugin-series
  • devlounge-plugin-series.php(main plugin file)
  • js
    • devlounge-plugin-series.js.php
  • css
    • devlounge-plugin-series.css
  • php
    • dl-plugin-ajax.php(新php文件)

注意，我的javascript文件的扩展名是php。我会在这篇文章后面解释这个变化的来历。

我已经建立了一个新的文件，并且把它放到了php文件夹中，并且命名为dl-plugin-ajax.php。我已经在这个文件中放了如下的代码：

这个段代码非常简单，并且仅为做AJAX调用而写。它确保了配置结构存在，从而我们可以调用类对象dl_pluginSeries，引用其他WordPress函数和变量。然而，showComments函数还没有创建，我们下一个议程就是来做这件事。

定义showComments函数

showComments函数将放在我们的DevloungPluginSeries类中：

可能已经认出来了，这段代码在数据库交互这篇文章中出现过。此函数输出你博客上留言的数量。

让JavaScript知道你的博客在哪里

使用AJAX时，一个烦人的事情就是外部JavaScript文件不知道你博客安装路径是什么。我是通过在js后面添加php扩展名来处理这个问题的，因为这样，我就可以调用WordPress函数了。在addHeaderCode函数中，我把代码从：

换成：

我唯一改变的是一个版本号码，还有就是给JavaScript文件添加了一个php扩展名。

编写JavaScript

这段脚本的目的是找到博客的URL，调用PHP文件，然后返回结果给用户。

上述代码做了下面这些事情（记住，我们在使用Prototype）：

• 确定配置结构是存在的，这样我们才能访问WordPress函数
• 在文档已经装载后，devloungePluginSeriesInit函数被调用了
• 给你添加到文章末尾的链接上绑定了一个事件。如果你忘了，现在可以加进去。简单地找到文章，然后添加这段代码：<a href="#" id="devlounge-link">Get the Number of Blog Comments</a>
• 找到PHP文件的绝对路径
• 调用PHP文件
• 将反馈输出给用户

结果

下一步，我们假设你已经把那个链接添加好了。我们点击链接“Get the Number of Blog Comments”，脚本使用AJAX调用了DevlongePluginSeries类中的函数，并且以对话框的形式返回了结果。

就如你看到的那样，我的本地安装版本，并没有多少评论。

添加你的javascript

你的插件可能需要装载prototype类库，或者一个自定义的脚本。这一节将向你展示几个WordPress函数，它们可以帮助你装载脚本，并且避免脚本冲突。

wp_register_script函数

wp_register_script函数允许你注册要调用的脚本，并且允许你设定先决条件。比如说，如果你的脚本需要prototype事先加载，那么你可以通过这个函数来指定。

这里是wp_register_script函数的参数：wp_register_script($handle,$src,$deps=array(),$ver=false);

• handle是一个独一无二的名字，后面会用此名字引用你的脚本。这个参数是必须的。
• src是你的javascript文件的绝对路径。这个参数是必须的。
• deps是一个依赖数组。比如说，如果你的脚本需要使用prototype，你要把它罗列在这里。这个参数是可选的。
• ver是一个字符串，标明了脚本的版本。这个变量是可选的。

举个例子，如果你有一个脚本要装载：http://yourdomain.com/wp-content/plugins/your-plugin-directory/js/script.js

让我们做一些假设：

• 你希望handle的名字为“my_script_handle”。
• 你的脚本依赖于prototype类库
• 你的版本是1.0

你将在你的插件代码初始化调用那个函数，或者在wp_head action之后调用：

wp_enqueue_script函数

wp_enqueue_script函数除了src参数是可选的以外，其他与wp_register_script是一样的。如果提供一个src，入队函数会自动地注册脚本，因此使用wp_register_script函数并不是必须的。然而，wp_register_script函数允许你手动注册你的脚本，这样，你可以仅使用一次wp_enqueue_script函数就将你所有的脚本装载。

如果我们像上一个例子中那样调用脚本，那么看起来像下面的样子：

一个javascript的例子

对于Devlounge Plugin Series插件，我们将添加一个javascript文件，后面的文章中会用它。使用这个文件的目的，就是为了说明怎样使用wp_enqueue_script函数。

• 文件将会放下下列地址：http://yourdomain.com/wp-content/plugins/devlounge-plugin-series/js/devlounge-plugin-series.js
• 这个文件依赖于prototype
• 版本是1.0

你可能会回忆起，这个系列文章早期的一篇文章中，我们添加了一个action叫wp_head。那个action添加后，会调用一个函数，叫做addHeaderCode。让我们来修改这个函数，添加我们新的javascript：

上述代码的工作如下：

• 首先，检查wp_enqueue_script函数的存在性
• 然后调用该函数
• 我们使用 get_bloginfo('wpurl') 来得到WordPress安装根目录，然后手写路径中剩下的部分

加载层叠样式表

我已经往我的样式目录里面添加了一个新的样式表。这里是我们的一些前提：

• 这个文件存储在下列位置：http://yourdomain.com/wp-content/plugins/devlounge-plugin-series/css/devlounge-plugin-series.css
• 我在这个CSS文件中指定了一个ID叫做#devlounge-link
• 你已经添加了下面的代码 在文章的末尾：<a href="#" id="devlounge-link">取得博客留言的数量</a>

在样式表文件中，我已经添加了下面的ID：

在插件中添加样式表，就和在addHeaderCode函数中添加一行代码一样简单：

在第2行，我只是简单地打印出了新的样式表。

这篇文章将会涉及到这个问题，让你可以添加你自己的用户面板。

命名你的选项

第3行显示，我添加了一个成员函数，叫做adminUsersName。我给这个变量取了一个长而且独特的名字DevloungePluginSeriesAdminUsersOptions。

设定你的缺省用户选项

你将需要一个地方来初始化你的选项，尤其是当一个用户第一次激活了你的插件的时候。然而，这些选项在管理面板之外也应该起作用，不论用户是登录了还是没有登录。

这里是一个我引入到DevloungePluginSeries类中的函数：

这个函数完成以下任务：

• 检查用户是否已经登陆（3-7行）。这个检查仅需要查看变量user_email是否设定即可。
• 尝试找到以前存储在数据库中的选项（第8行）。
• 如果没有找到option，设定默认值（第9-15行）。
• 返回option供你使用

初始化管理用户option

可以在任何时候调用getUserOptions来取得用户管理options。然而，那么插件第一次安装的时候呢？应该有某种函数被调用，以取得用户选项。我添加了下面这个函数到init函数:

第3行调用了新函数getUserOptions。由于已经有了一个action调用了init函数，不需要额外的步骤了。

怎样使管理面板和用户面板一起工作

你会回想起上一篇关于设定一个管理面板的文章中，WordPress管理员可以设定文章末尾的内容，代码是否是否在头部显示，评论中的作者名字是否大写。而用户面板允许那些不是管理员的用户有能力设定他们是否希望这些options。

我们将允许用户决定，如果他们：

• 想要内容在文章的末尾显示（仅当管理员启用了这个option）
• 想要评论作者的名字大写（仅当管理员启用了这个option）

设定用户面板函数

我们要做的第一件事情就是编写一个函数来显示用户面板。函数名字为printAdminUsersPage。下一段代码将会读入我们早先设定的options并且检查一下是否有任何文章选项已经被提交。这一节中所有的代码都默认包含于printAdminUsersPage函数。

上述代码：

• 取回用户options（第7行）
• 存储发送的数据到数据库（第9-18行）
• 为用户读入用逗号分隔的变量

下一段代码将会显示用户面板必须的HTML表单。所有的代码做的事情就是显示表单元素，并且读入已经取得的选项。

设定用户面板Action

当设定管理面板的时候，我们定义了一个函数叫做DevloungePluginSeries_ap，以帮助初始化管理面板。我们现在将要再次求助于此函数来添加我们的用户面板。

在第12行，你能看到一行代码：

• 往profile.php页面中添加了一个子菜单
• 让一个用户级别高于或者等于0的用户访问用户面板
• 调用我们的printAdminUsersPage函数

关于访问级别的（此例中为0）更详细的描述，可以参考用户级别。

存储变量的地方

当你想要给你的插件创建一个管理面板的时候，你首先会碰到的问题之一就是到底在哪里存储变量值。非常幸运，WordPress通过options使得这件事变得非常容易。我将会在后续的系列文章中解释options和数据库存储。现在来说，所有你需要做的事情就是点点你的头，然后跟着我的指导，把你自己的管理变量存储到WordPress数据库中。

通常我考虑到options的时候做的第一件事情就是，给我的管理options取一个独特的名字。我把这个名字以成员变量的形式存储在我的类中。在这个Devlounge Plugin Series插件的例子中，我把这个变量声明添加到DevloungePluginSeries类中。

命名你的管理Options

第2行显示了我存储我的成员变量的地方。我将我的变量命名为adminOptionsName并且给予它一个很长而且独特的值DevloungePluginSeriesAdminOptions。

给你的管理Options设定缺省值

你需要一个地方来初始化你的管理选项，尤其是当一个用户第一次激活你的插件的时候。然而，你还必须保证这些options在升级中是安全的，以防万一你决定将来添加更多的options。我使用的技巧是，提供一个专门的函数来调用你的管理options。你的插件的需求可能不一样，但是绝大多数的管理面板不会难以置信地复杂，所以一个函数对你的管理options来说，已经足够了。

下面这个函数是我插入到类DevloungePluginSeries中的：

这个函数做的事情是：

• 给你的管理options赋默认值（3-6行）
• 尝试从数据库中找出以前存储过的值（第7行）
• 如果options曾经存储过，那么存储的值会覆盖默认值（8-11行）
• options被存储到WordPress数据库中（第12行）
• options被返回供你使用（第13行）

初始化管理Options

getAdminOptions函数可以在任何时候调用来获得管理options。然而，当插件第一次安装的时候呢？应该有某个函数被调用也能获得管理options。我在DevloungePluginSeries类中添加了这个函数：

短小简单。但是必须有一个action来调用这个函数。

这个action有些复杂，但是很容易理清楚。下面是这个action做的事情：

• 当一个插件被激活的时候你告诉它运行
• 你给它主要的插件PHP文件，就是devlounge-plugin-series/devlounge-plugin-series.php。这当然是假设你把插件放到了wp-content/plugins/目录中。
• 你传递了一个引用给实例变量dl_pluginSeries并且调用了init函数。

所以，任何时候插件被激活，init函数都会被调用。

管理面板怎样工作

在我深入到创建实际的管理面板的代码的时候，描述一下管理面板的行为是有好处的。这里有一些你设定你管理面板的步骤：

• 检查任何表单数据是否已经被提交。
• 如果表单数据存在，输出提醒。
• 显示管理面板Options。

在管理面板中，一个非常困扰你的问题可能是_e的使用。_e函数允许WordPress搜索你文本的本地化版本。这将帮助WordPress在将来翻译你的插件。这个函数的工作类似一个普通的echo，但是你传给它的是你的文本和一个标识变量（典型的是你的插件名称）。一个例子：

_e('Update Settings','DevloungePluginSeries');

这句代码和：

echo "Update Settings";

是相同的。

设置你的管理面板函数

我们想要做的第一件事情就是设定一个函数，来真正地打印出一个管理面板。函数名字叫做printAdminPage。下一段代码将要读入我们早先设定的options并且检查是否所有的发布options已经被提交。这一段的所有代码假设写在printAdminPage函数中。

上面所有代码做的是装载options并且测试是否表单的每个部分都已经被正确提交。if语句并不是必须的，但是有的时候对于调试来说很有用。第一被测试的表单变量是update_devloungePluginSeriesSettings。这个变量被赋值给我们的“提交”按钮。如果它没有被设定，那么说明这个表单没有被提交。

就像说好的一样，在第16行，我使用了apply_filters函数来格式化内容，以便存入数据库。

下一段代码将会显示一个HTML表单，那是管理面板所必须的。它有一些复杂，所以我会这里概括一下。所有的代码做的事情，就是显示表单元素和读入options。

需要在上述代码中观察的是options的引用，和HTML和PHP是怎样集成的。

设置管理面板Action

现在，printAdminPage函数已经添加了，我们需要通过一个action调用它。首先函数必须被设定在正好在action的上面，在类的范围之外。

上面的代码做了下面这些事：

• 创建了一个叫做DevloungePluginSeries_ap的函数。
• 测试变量dl_pluginSeries是否存在（4-7行）。这个变量是我们的类的引用。
• 一个叫做“Devlounge Plugin Series”的管理页面被初始化了，并且，我们的printAdminPage函数被引用了。（8-10行）。

add_options_page函数的调用方法为：

add_options_page(page_title,menu_title,access_level/capability,file,[function]);

访问级别（在这个例子中是9）在WordPress Codex的Users Levels page页面有详细的描述。

必须设置一个action来调用DevloungePluginSeries_ap函数：

WordPress Filter允许你修改几乎任何类型的显示文字，而且其功能十分强劲。通过Filter你可以修改文章，feed，怎么样在评论中的作者，还有很多，很多。

为了说明WordPress Filter的用处，我们会继续在已经存在的Devlounge Plugin Series代码上工作。

添加一个内容Filter

有一个你可以使用的很Cool的Filter是'the_content'。这个filter在文章内容被显示在浏览器之前执行。我们将要添加一行文字到文章内容的末尾。

根据WordPress插件API，添加一个filter的格式为：add_filter('hook_name','your_filter',[priority],[accepted_args]);

我们只需要往DevloungePluginSeries类中添加一个函数。让我叫它addContent。

在上面的代码中，发生了以下的事件：

• 上述函数会接受一个参数叫做content
• 如果调用时不传递参数，那么content会设定为默认值（空串）
• 参数content被附加了一行我们自定义的文本
• 然后重新返回了content

在向类添加了上述函数后，下一步要做的就是将它插入到'the_content'中，使得这个函数被调用。

在这段代码的第6行你可以看到，添加了一个叫做'the_content'的filter，通过这个filter，我们的函数'addContent'会被调用。

如果插件启用，当一篇文章被显示的时候，文本“Devlounge Was Here”将会被显示到文章的末尾。

添加一个作者Filter

我在这里要展示另一个使用Filter的例子，我要展示一下怎么操纵显示一个评论的作者。我这里只是简单地让所有的作者名字都用大写显示。

我们只需要往DevloungePluginSeries类中添加一个函数。我们叫它authorUpperCase。

在上述代码中，做了这些事情：

上述函数会接受一个参数，叫做author

如果没有参数，会被设定成默认值

author字符串会以大写的形式返回

在函数被添加到类后，下一步是将它插入到'get_comment_author'中使它被调用。

像你在第7行看到的，我们添加了一个'get_comment-author' filter，然后，我们的函数'authorUpperCase'会被调用。

如果插件已经启用，并且一篇日志的评论是可见的，那么评论的作者名字会以大写显示。

应用Filter

使用Filter可以做的更强大的是，你可以动态地调用他们。没有必要每次运行都添加一次filter。你可以在任何时候在你的代码里面调用filter。

apply_filters的格式是：apply_filter('filter name','you text');

你会在这个系列的后续文章中看到apply_filters的例子。

一些我使用极其频繁的Action有：

• admin_menu：允许你给你的插件设置一个管理面板。
• wp_head：允许你将代码插入到博客的<head>标签内。

Action在行动

当定义一个WordPress插件的结构的时，我为某些Action留下了一块地方。在这个例子中，我们将使得一段代码可以在WordPress博客中的<head>标签内运行。

首先，我们需要在DevloungePluginSeries类中添加一个函数：

上面一段代码的作用是输出HTML注释。相当简单，但是你实际上可以输出任何东西。为了调用这个函数，我们要添加一个Action。

从WordPress插件API中我们可以知道，add_action的结构如下：add_action('hook_name','your_function_name',[priority],[accepted_args]);

由于我们是在一个类的内部调用一个函数，我们传递给Action一个数组，里面包含我们的类对象的引用（dl_pluginSeries）和我们想要调用的函数名（addHeaderCode）。我们已经给我们的插件设定了一个优先级为1，数字越小，执行时间越靠前。

运行代码

如果Devlounge Plugin Series插件被启用了，使用【查看->源文件】应该可以在你的博客的源码中看到注释“Devlounge was here”。

移除Action

如果你的插件动态地添加Action，你也可以使用remove_action来动态地移除action。用法如下：

remove_action('action_hook','action_function')。

WordPress插件怎样工作

在将一个插件放入到wp-content/plugins/目录后，插件应该自动的处于可以安装的状态。

当一个插件被“启用”，等同于告知WordPress将你的代码装载到“每”个页面（包括管理页面）。这也就是为什么当你启用了很多的插件的时候，你的WordPress可能非常慢的原因，这是由它所引入的代码的量决定的。

从你的插件被启用，WordPress自动将你的代码装载后开始，你可以利用WordPress插件API。你还可以使用WordPress模板标签或者创建你自己的函数。

如果你计划开发一个改变文章内容或者评论的插件，我建议你读一下WordPress loop。WordPress loop是一个显示你的文章的循环。有些模板标签在这个循环外面无法工作，所以，你准确地知道你代码在哪里执行是非常必要的。你可通过使用Actions和Filters来控制这一点，这将会在将来的文章中解释。

文件夹结构

所有的WordPress插件都会被安装到wp-content/plugins目录中。有些插件作者的插件只包含一个文件，但是我推荐你总是创建一个文件夹来保存你的插件。

典型地，我会把我的插件放在如下的目录结构中：

• 插件文件夹名称（你插件的名字，没有空格或者特殊字符）
  • 插件PHP文件
  • js文件夹（存放javascript文件）
  • css文件夹（存放样式表文件）
  • php文件夹（存放其他的PHP文件）

举例来说，这是一个我创建的样例结构：

• devlounge-plugin-series
  • devlounge-plugin-series.php
  • js
  • css
  • php

在devlounge-plugin-series文件夹中，我将只包含主要的PHP文件，把其他的文件都放到他们各自属于的文件夹中。这个结构将帮助其他插件作者在查看你的代码的时候，能够分辨哪个是主要的插件文件，哪些是支持插件正常工作的附属文件。

WordPress还建议将图片放到一个文件夹中，并且包含一个readme文件在你的插件中。

主要插件文件

当你开始编写一个插件的时候，前面七行用来描述你的插件。

第3行是让你命名你的插件的。第4行是向用户指出插件所在的网址的。第5行让你指定当前的版本。第6行让你设定插件的作者。第7行是对插件的描述。

下面展示的是一个已经填写完毕的范例：

下面展示的是插件在WordPress插件面板上出现的截图。

设定一个类结构

开发一个插件，并不需要你对PHP类了若指掌，但是如果你真的很熟悉，那会很有帮助。为了避免与其他的WordPress插件发生名字冲突，一个类结构是必须的。如果别人在插件当中使用了和你一样的函数名，那么就会发生一个错误，WordPress可能会无法响应直到你删除那个插件。

为了避免名字冲突，所有的插件都使用一个PHP类结构是急需的。这里有一些“骨架”代码，可以帮助你创建一个类结构。

上述代码的含义是，首先检查是否有一个名叫DevloungePluginSeries的类存在。如果这个类不存在，那么创建这个类。

初始化你的类

下面的代码将会初始化你的类。

上面的代码检查是否类DevloungePluginSeries已经存在了。如果已经存在，那么一个变量$dl_pluginSeries将会被创建，并且会使用一个DevloungePluginSeries类的对象给它赋值。

设置Actions和Filters

下面的代码段是用来放置WordPress Actions和Filters的地方（我会在后续的文章中详细讲）。

上述代码首先确认$dl_pluginSeries是否已经被设定。如果设定了（仅当类存在的时候），那么就会设定合适的actions和filters。

下面罗列了为什么一个WordPress用户应该考虑编写一个WordPress插件的七个理由。

1. 你喜欢一个插件的创意，但是不喜欢这个插件的实现方式

   无论是在Weblog Tools Collection还是在官方的WordPress插件目录或者WordPress插件数据库寻找插件，你将不可避免的找到一个插件，能够满足你的需求，但是只能在某种程度上满足你的需求。

   你很喜欢这个插件的创意，但是却并不是那么喜欢插件作者使用的实现方法。为什么不创建你自己的分立的版本来实现你最初的那个创意呢？

2. 你想修改已经存在的插件的代码

   有时候，一个插件的输出需要修改一下，或者你想要的某个功能正好没有。虽然你可以尝试说服插件作者来添加你要的特性，但是插件作者通常都非常忙或者他们不喜欢你的建议。一个插件作者要为一个免费插件提供支持，维护需要付出很多努力。有时候，一个插件很可能已经没有任何人去维护它了。

   在插件作者不能满足你的需求的这种情况下，就全靠你自己采取主动来修改存在的插件代码了。如果你的工作做得足够好并且做了足够多的修改，你可以再次发布这个插件，只要原来这个插件发布于与GPL相兼容的许可就行。

   通常当我安装或者测试一个新的插件的时候，我要做的第一件事情，就是查看一下代码，看看有什么我可以修改的，有什么我不可以修改的，我有可能往里面添加什么或者拿掉什么。

3. 你想要扩展一个插件

   有时候一个插件本身很好，但是你想要在它的基础上建立并且发布你自己的版本。比如说，你可能认为一个插件在使用了AJAX后会工作得更好，或者添加更多的钩子以使它能够与其他插件兼容。你可能想要给它添加一个管理面板使得你不需要深入到代码里去修改输出。

   就想前面提出的一样，如果一个插件是兼容GPL许可的，你可以自由地发布你自己的版本。

4. 你想要可移植的主题代码

   对于像我们这样选择自己从零开始创建主题的玩家，你可能会发现你自己在很多地方重用着一段代码。编写你自己的插件，组合所有的代码小片段使得你可以像使用模板标签一样来使用那些代码，不是更好吗？

   模板标签的美丽就在于你可以一次又一次地在你的主题或者任何一个你将来要创建的主题中使用它们。并且，你只需要在一个地方修改这些代码，而不是很多处地方。

5. 你是一个主题设计者

   如果你是一个WordPress模板设计者，我可能会劝说你，符合逻辑的下一步是成为一个插件作者。编写插件将使得你对于WordPress的行为有更进一步的了解，接着，你就可以扩展那些你已经发布的模板的功能了。

6. 你想要赚钱

   一个好的插件作者通常可以因为他的工作而获得回报。一些插件作者也可以获得捐赠或者为提供额外的支持或者咨询而收取费用。

7. 你想获得链接

   当我发布Reader Appreciation Project的时候，我的其中一个目的就是快速建立传入链接。我知道的最好的方法就是写一些WordPress插件并且提高它们的功能。我的其中一个插件（WP Ajax Edit Comments）竟然非常地流行，目前已经为我带来了超过100个传入链接了。

即便是WordPress这样一个优秀的独立应用程序，仍旧有许多方面有缺憾。用户所要求的越来越多的WordPress所应该具有的特性，都很可能被开发成插件。此外，还有很多没有实现的创意，而且，每一天还有更多的创意被提出。

在已经发布了三款插件之后（不包括我自己写给自己用的那些），我意识到了一些WordPress的局限性，我希望能够分享一些我已经学到的（我仍旧在学）关于创建WordPress插件的一些经验。最终，我将会开始写一个系列，专门讨论编写你自己的WordPress插件的过程中遇到的各种各样的问题。这个系列将会从非常基础的话题开始，并且假设你的插件知识是零基础。

这个系列是为谁准备的？

这个系列是为了任何一个好奇或者想要学习怎样编写他们自己的WordPress插件的用户撰写的。这个系列的读者应该有中级程度的PHP知识，知道一点点JavaScript，并且有相当的CSS知识。

这个插件系列将会使主题模板设计者受益，还有那些想要修补插件代码的人，还有那些想从零开始编写自己的插件的人。

完成工作必备利器

使用任何文本编辑器都可以写插件。这里是一些我个人使用的创建插件的工具。

• Dreamweaver
• Firefox
• Firebug（Firefox的插件）
• Web Developer（Firefox的插件）
• XAMPP和一个本地安装的WordPress

这个系列假设你使用的是WordPress 2.1.x或者更新的版本。

代码范例

我所使用的所有的代码在每篇文章的结论一节都提供下载。我会随着内容推进，逐步完善我的代码，所以每一份下载都会不同。我将会创建一个实际上什么都做不了的插件，但是足够向你展示一个插件工作的基础了。

由于这个系列里的每篇文章都是在上一篇的基础之上，所以推荐按照顺序来阅读这个系列里面的文章。

我极力建议你使用本地WordPress来安装调试测试插件，而不是在一个你用来发表你的文章的正规的WordPress上。

话题

我计划从非常基础的内容开始，然后快速推进到更加核心的WordPress插件函数的内容。这个系列不会关注插件开发中太过细节的东西，但是希望能够给你一个很好的开始开发你自己的插件的基础。如果你有任何问题或者建议，请留言，或者使用Devlounge Contact Form插件给我发送Email（译者：也可以给我留言）。我请你不要依赖Devlounge或者支持，而是使用WordPress支持论坛。

技术

我在我的代码范例中使用的某些技术可能不是最好的代码表达方式。你可能会对我没有使用许多的便捷写法而有所微词。我在这里提前抱歉。每个人有不同的编码风格。

只要是插件技术，结构，行为，或者其他讨厌的东西，如果有更好的方式被我忽略了，那么我非常乐意倾听。

介绍

本文当主要介绍WordPress插件开发者可以使用的API Hook，以及如何使用它们。

本文假设您已经阅读了《Writing a Plugin》（这篇文章概览了如何写一个插件）。本文主要介绍API Hook，也称作Filter和Action，WordPress使用这些函数来使您的插件起作用。

注意：本文的内容适用于WordPress1.2+。

Hook，Action和Filter

Hook是WordPress提供的一种机制，帮助您将您的插件加入到WordPress中；也即，在您的插件中，通过调用一些系统函数，使得您的插件可以运作起来。一共有两种Hook：

1. Action：Action是WordPress内核在运行到某个特定的点的，或者某个特定的事件发生的时候执行的。您可以通过使用Action API让您的插件中的一个或者多个函数在这些特定的点执行。
2. Filter：Filter是WordPress在将一段文本加入到数据库，或者发送给浏览器之前处理不同种类的文本用的。您的插件可以通过使用Filter API，让一个或者多个函数在这些时刻运行，以处理特定类型的文本。

有的时候，您可以使用Action和Filter达到相同的目的。比如说，您希望你的插件可以更改一段日志的文本，您可能会往publish_post中添加一个Action函数（这段文字在被加入到数据库之前被修改了），或者往 the_content中添加一个Filter函数（这段文字在被发送给浏览器显示之前，被更改了）。

Action

Action由WordPress中发生的一些特定的事件所触发，比如发布一篇日志，更改主题，或者在管理面板显示一个页面。您的插件可以通过执行一个PHP函数来响应事件，实现以下几个目的：

• 修改数据库数据
• 发送Email信息
• 修改将要在浏览器上呈现的内容（管理员看到的或者访客看到的）

要达到上述的目的，需要遵循的步骤为（下文有详细的描述）：

1. 在您的插件文件中，创建一个在某个事件发生时，需要运行的PHP函数。
2. 通过调用add_action函数，将您的函数插入到WordPress中。
3. 将您的插件文件放到插件目录下，然后激活它。

创建一个Action 函数

在您的插件中创建一个Action的第一个步骤是创建一个能响应Action的函数，并且将它写入到您的插件文件里（您的插件文件最后会被放到content/plugins目录）。举个例子，如果您想要您的朋友在您发表了新文章的时候收到一封邮件，您可以创建下述函数：


function email_friends($post_ID) {
$friends = ‘bob@example.org,susie@example.org’;
mail($friends, "sally’s blog updated",
‘I just put something on my blog: http://blog.example.com’);
return $post_ID;
}


对于大多数的Action来说，您的函数要接受一个单一参数（通常是日志或这评论的ID，这要视情况而定）。有些Action接受多于一个的参数，您可以查看WordPress的Action文档，或者直接查看WordPress源代码来取得第一手资料。除了一个参数外，您还可以访问WordPress的全局变量，并且调用其他WordPress函数或者您插件中的其他函数（或者其他插件中的函数）。

注意：您要始终留意，是否WordPress本身或者其他的插件已经使用了您想用的那个函数的名字。关于这点，您可以查看避免函数名冲突这篇文章来获取更详细的信息。

Hook到WordPress

当您定义好您的函数后，下一步就是将您的函数Hook或者注册到WordPress中。在您的插件文件中的全局空间中调用函数 add_action()就可以了：

add_action(’hook_name’, ‘your_filter’, [priority], [accepted_args]);

该函数中：

• hook_name是WordPress提供的供hook用的函数名，也即您的函数将关联到的事件的名称。
• your_function_name 是您希望在hook_name指定的事件发生时执行的函数的名称。这可以是一个在WordPress中定义好的标准的函数，也可以是一个您自己定义的函数（比如上面提到的email_friends）
• priority是一个可选的整型参数，可以指定可以指定关联到某个特定的函数的执行顺序。默认值是10。数字较小的执行较早，如果优先级相同，则按照他们hook进来的顺序先后来执行。
• accepted_args是一个可选的整型参数，它定义了您的函数可以接受多少个参数，默认是1。这个参数很有用，因为有些事件发生的时候，可能会向您的函数传递多于一个的参数。这个参数是从WordPress 1.5.1后的版本才开始有的。

继续前文的例子，我们可以将下面一行代码加入到插件的文件中：

add_filter(’comment_text’,'filter_profanity’);

相似的，您也可以将一个函数从Action中移除。你可以参考移除Action来获得详细的信息。

安装和激活

让您的插件奏效的最后一个步骤就是安装和激活和插件了。您写好的函数和对add_action的调用，必须放到同一个文件中，插件文件必须被装到wp-content/plugins目录中。一旦插件安装好，您需要访问管理面板来激活您的插件。

目前已有的Action Hook

参见Plugin API/Action Reference来查看WordPress中的当前的Action列表。

Filter

Filter是在WordPress执行过程中，传递数据时，在对数据采取某种行动（将数据写入到数据库或者发送给访客的浏览器）之前执行的。（当WordPress生成页面时）Filter就位于数据库和浏览器之间，（当WordPress向数据库添加日志和评论时）Filter就位于浏览器和数据库之间。WordPress中的绝大多数的输入和输出过程都要通过至少一个Filter。WordPress自己有一些默认的Filter，您可以在插件中使用自己的Filter。

将您自己的Filter添加到WordPress中，遵循以下几个步骤：

• 创建一个PHP函数来过滤数据。
• 通过调用add_filter将这个Filter添加到WordPress中。
• 将您的PHP函数写入到一个插件文件中，激活它。

创建一个Filter函数

一个Filter函数把未经修改的数据作为输入，返回修改过的数据（或者有的时候返回的空值，表明这些数据应该被删除）。如果您的Filter没有修改数据，那么原始的数据必须被返回回去，以便于后续的插件可以继续它们的修改工作。

所以，在您的插件中创建一个Filter的第一步，就是创建一个PHP函数来执行过滤动作，并且，将这个函数写入到您的插件文件中去。再举个例子，如果您需要确定您的日志或者评论中没有出现违禁词汇，您可以定义一个全局变量，里面包含了全部的违禁词汇的列表，然后创建下面的PHP函数：


function filter_profanity($content) {
global $profanities;
foreach($profanities as $profanity) {
$content=str_ireplace($profanity,’{censored}’,$content);
}
return $content;
}


注意：同样要小心您的函数的命名，不要和其他的WordPress函数和其他插件的函数冲突。

将您的Filter Hook到WordPress

在您的函数定义完毕后，下一步就是将您的函数"hook"或者说注册到WordPress中。在您的插件文件中，调用add_filter函数：


add_filter(’hook_name’, ‘your_filter’, [priority], [accepted_args]);


其中：

• hook_name 是WordPress提供的供hook的函数的名称，定义了您可以加入您自己的Filter的插入点。
• your_filter是您的filter函数的名称。这个函数可以是一个WordPress标准PHP函数，也即在WordPress内核中定义的函数，也可以使一个您自己定义的函数。
• priority是一个可选的整型参数，标明了注册到某个特定的filter中的函数的执行顺序。默认是10。较小的数字执行时较靠前。如果priority值相同，那么按照注册的先后顺序来执行。
• accepted_args是一个可选参数，用来标明您的函数能够接受的参数的个数，默认是1，某些hook可以像您的函数传递超过一个的参数。

继续上面的例子，您可以使用下面的代码，让WordPress过滤您评论中的违禁词汇：


add_filter(’comment_text’,'filter_profanity’);


您也可以使用remove_filter()函数来将一个Filter移除。

安装和激活

最后一个步骤就是使您的filter运作起来。你需要做的就是将您的插件文件放到wordpress/plugins目录，然后到后台管理界面激活。

目前WordPress中可以注册的Filter

参见Plugin API/Filter Reference。

例子

下面是一个例子，是Ozh曾经在邮件列表中描述过的，该插件修改（或者说覆盖）了默认的bloginfo()函数。这需要修改内核函数的行为。


add_filter(’bloginfo’, ‘mybloginfo’, 1, 2);
add_filter(’bloginfo_url’, ‘mybloginfo’, 1, 2);

function mybloginfo($result=”, $show=”) {
switch ($show) {
case ‘wpurl’:
$result = SITE_URL;
break;
case ‘template_directory’:
$result = TEMPL_DIR;
break;
default:
}
return $result;
}


移除Action和Filter

在某些情况下，您可能会发现，您的插件需要禁用WordPress中的内建Action或者Filter之一，或者某个其它插件添加的函数。您可以通过调用remove_filter(’filter_hook’,'filter_function’)或者 remove_action(’action_hook’,'action_function’)来达到目的。

比如，remove_action(’publish_post’,'generic_ping’);可以在您发表日志的时候，阻止您的博客向外发送ping。

注意，如果一个hook不是使用默认的优先级（priority）注册到系统中，那么您必须在remove_action()中指定那个hook使用的优先级。一般来说还要注意，除非您很清楚那个函数在干什么并且为什么要那么做，请不要移除任何函数。

缺省加载的Filter和Action

最可靠的获知WordPress缺省加载了哪些Filter和Action的方法就是在其源代码中搜索add_filter和add_action函数的调用。

WordPress 2.1

在WordPress2.1中，绝大多数的Filter和Action的加载是在wp-include/default-filters.php文件中进行的。其他的在下列的文件中加载：

• wp-admin/admin-ajax.php
• wp-admin/admin-functions.php
• wp-admin/custom-header.php
• wp-admin/edit.php
• wp-admin/index.php
• wp-admin/options-permalink.php
• wp-admin/upload-functions.php
• wp-admin/upload.php
• wp-includes/bookmark.php
• wp-includes/general-template.php
• wp-includes/kses.php
• wp-includes/plugin.php
• wp-includes/rewrite.php
• wp-includes/template-loader.php
• wp-includes/theme.php

WordPress 2.5

(以后我会完善这个部分)

您可以覆盖的函数

除了使用hook（action和filter），另一个插件修改Wordpress行为方式是覆盖WordPress的函数。实际上，有一小组函数，是WordPess希望被插件覆盖的。在所有的插件都已经启动后，如果他们还没有被覆盖的话，WordPress才启动这些函数。

这些函数在wp-include/pluggable.php文件中定义。这里有一个列表（WP2.1）。

• set_current_user
• wp_set_current_user
• wp_get_current_user
• get_currentuserinfo
• get_userdata
• update_user_cache
• get_userdatabylogin
• wp_mail
• wp_login
• is_user_logged_in
• auth_redirect
• check_admin_referer
• wp_redirect
• wp_get_cookie_login
• wp_setcookie
• wp_clearcookie
• wp_notify_postauthor
• wp_notify_moderator
• wp_new_user_notification
• wp_verify_nonce
• wp_create_nonce
• wp_salt
• wp_hash