Becomin' Charles » develop

视频教程：使用Yii框架开发Blog

Charles — Sun, 20 Mar 2011 06:59:18 +0000

Yii框架的官方网站上，有一个教学用demo，就是使用Yii框架开发一个blog。有非常详尽的文字描述，步骤基本也比较清楚。一遍走下来，基本上就差不多都学懂了。

上周正好要在公司做分享，害怕当堂演示会说不好，浪费时间，就在家里自己将blog的开发过程录制成了视频，这是我第一次录制视频，觉得格外新鲜，遂决定在这里分享给大家。大家一起乐一乐，O(∩_∩)O哈哈~

第0集 Blog功能需求及应用骨架搭建

第1集使用Gii代码生成工具

第2集使用数据库存储的用户信息来验证用户身份

第3集 Blog文章的创建和发布

to be continued...

多谢大家捧场了，欢迎留言告诉我大家是否喜欢这种形式~

最近新录了一个视频，不过不是关于blog demo的，是关于db部分的分析的，也一并放在这里吧，算是借点这里的人气了：）2012-1-27

标签：develop, framework, PHP, video, yii

使用Gii时出现403错误

Charles — Wed, 10 Nov 2010 01:57:08 +0000

在Yii框架中，使用Gii代码生成工具之前，首先要编辑好配置文件才能访问。一般，都是默认在本地环境安装了Yii框架，所以书里的范例写的时候，很多都没有提，要配置IP限制。我正好在学习过程中，使用了Linux虚拟机来学习Yii开发，结果配置完了，发现访问Gii时候出现403错误。在网上查了一下，可以检查一下自己的配置是否限制了IP。

'gii'=>array(
'class'=>'system.gii.GiiModule',
'password'=>'123456',
//书上的例子没有下面这行，要在数组里添加访问Gii的宿主机IP
'ipFilters'=>array('localhost','192.168.26.1')
),
?>

标签：develop, framework, PHP, yii

使用FirePHP辅助AJAX应用开发

Charles — Mon, 25 Oct 2010 08:56:00 +0000

FirePHP 一款非常方便强大的PHP、AJAX调试工具，基于Firebug的框架开发，可以算是Firebug的插件。该插件帮助用户将PHP的调试信息展示在Firebug的控制台标签内，而不是直接打印到页面上，这样就避免了在调试页面时破坏了页面的DOM结构。

FirePHP的调试信息主要通过HTTP的Response Headers来发送，所以不会和HTTP的包体混在一起，极大程度地方便了AJAX应用的开发调试，是AJAX开发调试的利器。

全文下载链接
 百度文库在线阅读

标签：ajax, develop, development, PHP

[心得]：在thickbox退出时执行动作

Charles — Tue, 23 Feb 2010 05:01:46 +0000

thickbox是jQuery的插件，可以在页面上显示一个模拟出来的窗体，可以是对话框，AJAX内容，或者仅仅用来展示图片。其使用非常方便，只要在页面中引入了thickbox.js和thickbox.css，就可以通过设定A，INPUT，AREA元素的href或者alt属性，就可以使得其功能得以实现。具体的文档，可以参见这里。

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

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

<a id="open-dialog" href="#TB_inline?height=300&width=400&inlineID=dialog">Click Herea>

$('#open-dialog').blur(function(){
$('#TB_Window').unload(function(){
//do something here
});
});

标签：code, develop, jQuery, usage

[插件开发]：检测WP插件的运行环境

Charles — Tue, 16 Feb 2010 01:31:36 +0000

WP的插件在开发完成后，会在用户的服务器上运行，而用户的服务器环境基本上可以用千奇百怪来形容。开发过程中，在本地运行得好好的插件的，一旦安装到用户的服务器上，也有可能变得无法运行。

所以，作为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环境进行一遍检查比较稳妥，下面贴一个本人进行环境安全检查的例子：

function safe_check(){
   if(!function_exists('scandir') && (!function_exists('opendir') || !function_exists('readdir'))){
   ?>

Sorry, PHP function 'scandir' is forbidden in your server, so that the plugin will not work. Please disable the plugin.

   }
}
if(is_admin()){
   add_action('admin_notices', 'safe_check');
?>

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

标签：develop, plugins, WordPress

[插件开发]：后台管理页面脚本按需加载

Charles — Mon, 15 Feb 2010 09:05:21 +0000

插件的后台管理页面的主要功能是协助用户设定插件运行时参数，一般都需要用户进行交互，这就少不了需要客户端脚本的参与（主要是js脚本，当然还有配套的css样式表）。

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组件。引入这个脚本的方法如下：

function plugin_detail_info_init(){
//一些初始化工作
....
wp_enqueue_script('jquery-ui-selectable');
....
//将实现插件功能的函数挂载到正确的hook上面
....
add_filter('wp_content', 'display_detail_info');
....
}
add_action('plugins_loaded', 'plugin_detail_info_init');
?>

一般我个人开发一个插件的时候，都喜欢将所有的插件初始化工作放到一个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用户都经历过热衷于安装各种插件，到头疼安装了很多插件，到最后一切从简对插件望而却步的一个转变过程。其实，我个人觉得，在这个转变过程中，插件的开发者是负有一定责任的。

function plugin_detail_info_init(){
//一些初始化工作
....
if(is_admin()){
wp_enqueue_script('jquery-ui-selectable');
}
....
//将实现插件功能的函数挂载到正确的hook上面
....
add_filter('wp_content', 'display_detail_info');
....
}
add_action('plugins_loaded', 'plugin_detail_info_init');
?>

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

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

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

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

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

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

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

function plugin_detail_info_init(){
//一些初始化工作
....
if(is_admin() && strpos($_SERVER['QUERY_STRING'], 'detail_info_manager') !== false){
wp_enqueue_script('jquery-ui-selectable');
}
....
//将实现插件功能的函数挂载到正确的hook上面
....
add_filter('wp_content', 'display_detail_info');
....
}
add_action('plugins_loaded', 'plugin_detail_info_init');
?>

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

标签：develop, plugins, WordPress

怎样撰写Features List

Charles — Mon, 20 Apr 2009 15:02:05 +0000

当开发好一款插件的时候，要为插件撰写一个readme.txt文件，这是让用户了解你的插件的最好方式。很多插件都会在readme.txt的第一个section（description）里，附上一个简单明了的features list，以便用户可以快速扫描你插件包含的功能，决定是否选用。那么应该如何撰写features list呢？本文为您介绍。

我不是一个撰写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的，但是基本上雷同，大家可以自己分析。本文主要写给自己看，作为自己学习写作的一些笔记。

标签：develop, English writing, plugins, WordPress

脚本语言的趋势

Charles — Sun, 29 Mar 2009 10:04:54 +0000

今天在FriedFeed上看到qingbo的一张脚本语言的图，很有意思，自己也来试试看。结果：

从过去12个月的搜索量来看，PHP在中国，俨然是老大的老大。然后是python，flex，perl，最后是ruby。这与ruby如日中天的名声不大相符。当然，搜索量不能说明什么问题，也可能，PHP的文档组织得最差，所以，解决这方面的问题，总要依靠搜索，还有一个可能，用PHP的人都喜欢用google，其他程序员则可能也用百度（说不定可以排除这个可能，有不喜欢用google的程序员么？）。不过，这么大的差距来看，在中国PHP的群众基础非常好。还有，京沪穗不单是经济大省，而且还是IT大省。

有一点有趣的事情，两个尖峰低谷，一个是十一黄金周，一个是春节。说明一个问题，中国的广大脚本程序员，在过年和长假的时候，基本可以抛开手头的程序，享受一下天伦之乐……

再来看看地球另一端，总是在IT行业引领潮流的美国呢？在美国，PHP也还是第一，然后就是如日中天的ruby，看来，ruby是在美国更火一些，然后是我意料之中的flex，接下去才是python和perl。

这里我还有一张总趋势图，没有贴，PHP日渐滑坡，老大地位岌岌可危，ruby稳坐上升态势的二把交椅，Flex从不为人知，一路脚踏实地爬上来，目前正与一向稳定平衡的python纠缠。当然，抛开python，也是指日可待。最后，前几年的二把交椅perl，怎么也止不住下跌的势头，一步步踏向人们回忆的最深处。

结论，python是一门有着稳定需求，但是需求又不是那么大的脚本语言，python与fashion这个词不沾边。PHP，Flex，Ruby都是这场时尚大赛的角逐选手，鹿死谁手还未知晓。但是年轻的Flex和Ruby靠着自己新颖的理念，让人眼花缭乱的技术，赢得了越来越多的fans。Perl垂垂老矣。

纯粹胡扯一下下，别跟我当真啊。

标签：develop, google, interesting, interesting things, joke, opinion

WordPress主题：GoogleCode

Charles — Sat, 28 Mar 2009 07:59:28 +0000

名称：GoogleCode

特性：

拥有Hybrid主题所有的内在美
两栏
主页（Primary）、帖子页（Secondary）、归档页（Archive）、页面页（Page）有不同的侧边栏，括号里是边栏名字
标签式页面菜单
其他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，开发子主题。

标签：develop, hybrid, my works, themes, WordPress

Hybrid 常用Action

Charles — Wed, 25 Feb 2009 16:08:20 +0000

Home页面流程图

hybrid_head()
wp_haed()
body
hybrid_before_html()—action，默认没有被hook
div#body-container
hybrid_before_header()—action，默认没有被hook
div#header-container
div#header
hybrid_header()
end#header
end#header-container
hybrid_after_header()
div#container
hybrid_before_container()—action，默认没有被hook
div#content
hybrid_before_content()
/*wp loop begin*/
div.hybrid_post_class()
h2.post-title inline
p.byline inline
div.entry-content inline
p.entry-meta inline
end.hybrid_post_class()
/*end wp loop*/
hybrid_after_content()
end#content
hybrid_after_container()
end#container
div#footer-container
hybrid_before_footer()
div#footer
hybrid_footer()
wp_footer()
end#footer
hybrid_after_footer()—action，默认没有被hook
end#footer-container
end#body-container
/body

hook到hybrid_head()的函数列表

hybrid_meta_content_type()
hybrid_meta_robots()
hybrid_meta_author()
hybrid_meta_copyright()
hybrid_meta_revised()
hybrid_meta_abstract()
hybrid_meta_description()
hybrid_meta_keywords()
hybrid_meta_template()
wp_generator()
hybrid_favicon()
hybrid_head_feeds()
hybrid_head_pingback()
hybrid_head_breadcrumb()

hook到hybrid_header()的函数列表

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

hook到hybrid_after_header()的函数列表

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

hook到hybrid_before_content()的函数列表

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

hook到hybrid_after_content()的函数列表

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

hook到hybrid_after_container()的函数列表

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

hook到hybrid_before_footer()的函数列表

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

hook到hybrid_footer()的函数列表

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

由hybrid_page_nav()触发的action

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

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

hybrid_before_primary() —action，默认没有被hook
hybrid_after_primary() —action，默认没有被hook
hybrid_before_secondary() —action，默认没有被hook
hybrid_after_secondary() —action，默认没有被hook
hybrid_before_subsidiary() —action，默认没有被hook
hybrid_after_subsidiary() —action，默认没有被hook

标签：develop, framework, hybrid, reference, themes, WordPress

Hybrid 资源一览

Charles — Sun, 22 Feb 2009 05:12:19 +0000

页面模板一览

Template Name: Archives
Template Name: Authors
Template Name: Biography
Template Name: Blog
Template Name: Bookmarks
Template Name: Categories
Template Name: Log In
Template Name: Logged In
Template Name: No Widgets
Template Name: Profile
Template Name: Quick Post
Template Name: Register
Template Name: Sitemap
Template Name: Tags
Template Name: Widgets

Action一览表

comment_form
hybrid_before_html
hybrid_after_html
hybrid_head
hybrid_before_header
hybrid_header
hybrid_after_header
hybrid_before_page_nav
hybrid_after_page_nav
hybrid_before_cat_nav
hybrid_after_cat_nav
hybrid_before_container
hybrid_before_content
hybrid_after_content
hybrid_after_single
hybrid_after_page
hybrid_before_comments
hybrid_before_primary
hybrid_after_primary
hybrid_before_secondary
hybrid_after_secondary
hybrid_before_subsidiary
hybrid_after_subsidiary
hybrid_after_container
hybrid_before_footer
hybrid_footer
hybrid_after_footer
hybrid_child_settings

Filter一览表

show_password_fields <-- register.php(115)
hybrid_post_meta_boxes <-- meta-box.php(74)
hybrid_page_meta_boxes <-- meta-box.php(121)
hybrid_settings_args <-- theme-settings-admin.php(65)
hybrid_breadcrumb_args <-- breadcrumbs.php(31)
hybrid_breadcrumb <-- breadcrumbs.php(220)
hybrid_breadcrumb <-- breadcrumbs.php(222)
hybrid_avatar <-- comments.php(67)
hybrid_allowed_tags <-- filters.php(95)
hybrid_site_title <-- filters.php(115)
hybrid_site_description <-- filters.php(134)
hybrid_page_nav <-- filters.php(166)
hybrid_cat_nav <-- filters.php(189)
hybrid_category_menu_args <-- filters.php(236)
hybrid_category_menu <-- filters.php(275)
hybrid_search_form <-- filters.php(313)
hybrid_insert <-- filters.php(328)
hybrid_copyright <-- filters.php(350)
hybrid_credit <-- filters.php(380)
get_the_image_args <-- get-the-image.php(37)
get_the_video_args <-- get-the-video.php(37)
hybrid_enqueue_style <-- media.php(39)
hybrid_enqueue_script <-- media.php(92)
hybrid_favicon <-- template-functions.php(293)
hybrid_primary_args <-- widgets.php(64)
hybrid_primary_inserts <-- widgets.php(68)
hybrid_secondary_args <-- widgets.php(84)
hybrid_secondary_inserts <-- widgets.php(88)
hybrid_subsidiary_args <-- widgets.php(110)
hybrid_subsidiary_inserts <-- widgets.php(114)
hybrid_utility_args <-- widgets.php(138)
hybrid_utility_inserts <-- widgets.php(142)
hybrid_widget_class <-- widgets.php(209)
hybrid_primary_var <-- widgets.php(402)
hybrid_secondary_var <-- widgets.php(420)
hybrid_subsidiary_var <-- widgets.php(438)
wp_page_menu_args <-- legacy.functions.php(40)
wp_page_menu <-- legacy.functions.php(75)
widget_title <-- archives.php(26)
widget_title <-- authors.php(26)
link_category <-- bookmarks.php(145)
widget_title <-- categories.php(26)
widget_title <-- pages.php(26)
widget_title <-- search.php(26)
widget_title <-- tags.php(26)

标签：develop, framework, hybrid, reference, themes, WordPress

使用Hybrid框架的起点

Charles — Wed, 18 Feb 2009 15:16:07 +0000

在上一篇《Hybrid主题框架综述》中，我们已经介绍了Hybrid的基本原理。这篇文章，我们将主要介绍如何使用Hybrid来制作一款主题。本文主要面向的读者为主题制作爱好者，和狂热的DIY fans们。

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

/*
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没有往主题里挂过多的不必要的东西，一般情况不需要移除任何东西的。

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

在wp-content的themes文件夹下，创建一个文件夹，用作子主题的目录，如my-custom-hybrid。
在my-custom-hybrid目录里，创建两个文件，一个是style.css，一个是functions.php（可以不要这个文件）。
编辑style.css文件，在头部按照上文的格式，撰写注释信息，在Template后面，填上hybrid。
在style.css文件内部，使用CSS语法，创建你自己的样式。
在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资源一览表》，欢迎大家继续关注！

标签：develop, framework, hybrid, themes, WordPress

Hybrid 主题框架综述

Charles — Sun, 15 Feb 2009 05:44:55 +0000

Hybrid主题框架首次发布于2008年11月，该框架功能完备，定制性强，得到了很多开发者的青睐，以本文为首的系列文章，将向您介绍这款主题框架的方方面面。

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主题本身，就建立在其自身搭建的框架之上。为什么这么说呢？因为一个博客模板里，所有最为基本的东西，如标签内部的一些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的起点》，欢迎给位在下面跟帖讨论，并给我提供写作建议，谢谢！

标签：develop, framework, hybrid, themes, WordPress

浅析WordPress中的Hook机制

Charles — Wed, 11 Feb 2009 08:48:11 +0000

Hook，既可以是动词，表示钩住，也可以是名词，表示钩子。在一个计算机程序中，Hook没有准确的并且合理的中文翻译，很多技术书籍文章，干脆就称之为“钩子”。

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

标签：action, basic, develop, filter, WordPress

WordPress Theme: YUI Theme—烂尾版

Charles — Fri, 02 Jan 2009 14:54:39 +0000

1. 这个主题就是我现在用的这个主题。

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里的统计代码请替换掉

下载地址

祝大家好运~~

标签：develop, download, my works, themes, WordPress

为何以及如何整合Google搜索到WP博客

Charles — Wed, 29 Oct 2008 17:51:28 +0000

早在06年10月份【1】，Google就推出了自定义搜索引擎，到了07年11月份【2】，又推出了该项服务的多语言版本。现在，这项服务已经被使用到了成千上万的网站中去了。相信大家已经发现了，很多的WordPress博客也悄悄换上了Google搜索。就我个人熟悉的几个名博或朋友，如水煮鱼，阅微堂，stephen，侠姐等等早就已经是Google自定义搜索的用户了。那么，我，或者说作为读者的您，是不是有必要换上Google自定义搜索呢？又该如何操作呢？本文带给您Charles对此的理解。

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

标签：develop, DIY, google, usage, user experience, WordPress

无侵入与可用性层

Charles — Thu, 25 Sep 2008 08:28:21 +0000

使用jQuery一段时间的感想

早在使用WP之前的很久，我就听说了jQuery了，那个时候，只是惊叹于jQuery的视觉效果，然后记住了这个名字，但是一直也没有开始学习。直到我开始折腾WP这个程序，模板，插件，我才开始更广泛深入地接触jQuery。

在学习jQuery的过程中，我也看了一些牛人关于js的观点，并且从内心深处对此表示深刻认同。

无侵入

js代码应该单独的放在一个文件里面，而不应该混杂在html代码中。现在的页面设计也要遵循数据，表现，行为（动作？）分离的原则。html代码就是纯数据，按照数据本身的逻辑关系来组织，而页面外观，则是纯表现，使用css来指定，最后是行为（动作？或者事件响应？），使用js来实现。

三者的分离，有多种好处，更清晰的逻辑结构，更纯粹的数据，更好的可维护性，而且还对搜索引擎非常友好。外部引入的js和css不会对爬虫分析页面内容造成太大的影响。

所以，在编写js的时候，就要竭尽全力地去将js代码与页面完全剥离开来，至少要做到在内部，完全不出现js代码。

这种代码编写方式，就要求我们写js的时候改变一些陋习，并且更加地依赖于文档对象模型DOM。好，说道这里，问题就来了，使用DOM模型的话，遍历DOM树，就是关键了，如果不使用框架的话，就要自己写代码遍历，但是，由于那个恶心的问题，就是浏览器兼容性问题，各个浏览器实现的DOM模型和支持的js语法有着细微的差别，自己遍历DOM会痛苦无比。jQuery在这个方面，做得非常出色，基本上包揽了一切肮脏的工作。让人写起代码来格外愉快。

实在是很喜欢jQ在DOM遍历中的便捷。

可用性层

关于可用性层，是又一个现在很流行的概念。在十分关注用户体验的Web 2.0时代，页面可用性，已经成为了考量一个页面的质量的关键标准。

但是js由于其巨大的不稳定性，经常失效；还有就是早先对于js的滥用（如该死的弹出广告，漂浮广告，恶意浏览器插件），使得很多用户对js深具戒心，经常有些极端的用户干脆关闭js，斩草除根。

在这种环境下，js的应用只能在夹缝中艰难求存。于是乎，js成了一个附加的可用性层。“附加”代表可有可无。我现在设计页面，写js，也是在这么一种假设下写的，即“用户可能禁用了js”。追求的效果就是，如果用户没有开启js，那么你能看到全部内容，保证了页面可访问性，牺牲了可用性。而如果开启了js，那么用户将得到更加有趣的体验。

于是乎，我就产生了这么一种感觉，页面上附加的所有js应用，有一种“事务”的特征。我们的术语叫做“transaction”。主要就是其中原子性的特点。如果支持js，那么你觉得这个页面是一个功能丰富的ajax应用，非常炫目。如果不开启js，那么你觉得这是一个普通页面，你甚至没法觉察到这个页面背后其实有着大量的js代码。他们只是简单的被完全的，干干净净的，彻彻底底的拿掉了。

关于这一点，我使用jQ的体验，还是由于jQ那操纵DOM的优秀能力，使得这种理念或者这种理念指导下的开发成为了一件让人愉快的事情。

总结

上面两点是我在学习使用jQ的过程中的一些感想，写出来与大家分享一下。我接触Web开发的时间非常短，基本上没有什么经验可以谈的，上面的很多的观点，来自很多我认为牛的人，包括ppk（这个人让我对js的认识更深了一层），以及我订阅的一些牛人的博客里面展示的代码片段所传达的思想。

标签：ajax, develop, javascript, jQuery, opinion

WordPress插件开发实例--(02)

Charles — Thu, 21 Aug 2008 03:16:14 +0000

插件源于需求。——Charles

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

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

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

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

贴点代码吧

/*
Plugin Name: Insert Custom CSS
Plugin URI: http://sexywp.com/insert-custom-css.htm
Description: This plugin will insert a custom css file to your current theme.
Version: 8.8.21
Author: Charles Tang
Author URI: http://sexywp.com/
*/

/*
   Copyright 2008 Charles Tang (email : )

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/

function insert_custom_css(){
   $css_url = WP_CONTENT_URL . '/plugins/insert-custom-css/style.css';
   echo '' . $css_url . '" type="text/css" media="screen" />';
}
add_action('wp_head','insert_custom_css');

?>

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

标签：develop, plugins, WordPress

近况汇报

Charles — Mon, 28 Jul 2008 10:58:04 +0000

哎呀，貌似又有几天没有写博客了是吧，人懒了，实在没得东西写了，系列文章写着太累，慢慢来吧，天干物燥，大家稍稍凉快下，我就不拿技术的狂热温度来给大家升温了，我也凉快凉快。

先来看个好玩的文章吧，这个是google黑板报上的文章，大家想知道Google公司内部是怎么调位置的么？看看就知道了。我都笑得肚子疼了，这种换座位的方式，还真的非常的“Googley”。看来，想进Google公司的话，还有一个条件，就是让自己做事情更加的“Googley”，嘿嘿，我的模板算不算“Googley”呢？我不禁要想了……嘿嘿，充其量是个外表而已，内核可是根本的“WordPressly”啊，无奈……不说废话了，大家欣赏下吧

http://googlechinablog.com/2008/07/blog-post_28.html

一直以来想好好改进中文工具箱的，昨天，奋斗了一天，中文工具箱终于有了管理面板了，然后晚上睡觉的时候，我就又产生了好几个想法了，想往工具箱里加好多东西，我很害怕啊，最后这个东西会不会变成没人要用的怪物呢？嘿嘿，到时候，就我自己来用算了。罗列下改进的地方：

1. 改变了整体目录结构，除了主文件，其他文件都进入到子目录里面了，这样看起来简洁多了；

2. 进行了文件重命名活动，将以前的内容按照更有逻辑的方式进行安排了，这样更加有逻辑性了，这算是重构了吧，嘿嘿；

3. 增添了一个管理面板，这样，下一个版本里面，就不会在插件列表里面看到4个插件了，只会看到一个“中文工具箱”，进入管理面板，可以启用3个内置的widget，而且，上次在“中文工具箱”中增加的摘要算法，也在管理面板中可以定制了，包括截断字数，截断段落数；

4. 规范了模板标签，以后调用方式会大大简化，不必每次都去搞一个对象句柄，我已经进行了封装，这样以后无论内部怎么变化，模板标签都不会变化了。以后使用时候都是wkc_xxxx或者get_wkc_xxxx这种格式，怎么样，很面熟吧，是不是真的有点像template_tags了？

还有很多我想要实现的改变，但都是些大手术，我也不知道我什么时候能够开发完毕，下一个版本，我打算用Plugin Directory来发布了，不在我自己的博客上搞了，呵呵。

其实，昨天还有一个事情，我刚才没说的，就是我体验了一把Plugin Directory，真的很爽哦，哇哈哈，我把字数统计插件放到那里面去了，当然，只是为了体验一下这个东西，果然很好玩。以后都用那个了。

其实SVN还是很好用的，不过，好像我们学校非常诡异的没有开放那个端口，在学校期间，很可能不能使用SVN，那就糟糕咯，说不定只能两周会一次家来更新插件了。

好了，唠叨到这里吧，嘿嘿……

标签：develop, interesting things, plugins, WordPress

WordPress插件开发实例--（01）

Charles — Fri, 25 Jul 2008 04:47:10 +0000

很多朋友来我这里，可能真的会很失望了，因为——看不懂！囧。相信我，我如果写每个人能看懂的东西，那真的是很难看的，你们看我侧栏上的热门文章列表，还是以技术文章居多，就说明了一个问题，我写技术文章还对很少数的人能有所助益，我如果写大众化的文章，那就是完全的废物了。

所以，我宁愿读者少一点，也不愿做个没用的人。

现在，技术书籍的市场上，蔓延着一种浮躁的风气，经典的书不多，大都是些媚俗的技术书籍，《XXXX实例教程》就是一大类，说到这里，你就发现了，我在技术文章领域是媚俗的。这类书籍永远不会放在书架上长久保存，看过就扔，看过的人马上会意识到，这是没有价值的书。但是，这类书，还是可以让入门级选手有个感性认识的。考虑到博客文章本身的特点，比如时效性，片面性，博客还是比较适合发表这类文章的。

经典文章由大师来写，这种看过就算的文章，就由我来写吧。

此系列文章，又是一个漫漫长征路，因为，我的计划又是很宏伟壮阔的，这也符合我的性格——虎头蛇尾。关注这个系列的文章，你将会看到许多插件的运行原理，一部分插件的编写过程，构思过程，实际编码过程，调试过程，发布过程等等。我的理想是很伟大的——看过此系列，插件开发不再神秘，人人皆可动手。

Add Bottem Info

在文章中加入版权信息，可以保护自己的版权。当然，这个东西不光是加入版权信息，还可以加入各类讯息，只要你往里写就行。添加这一类的信息，有多种办法，最傻的，每篇文章写一个，很汗。然后是稍微好点的，写在模板里面，single.php，但是呢，换模板就不行了，又要重来，而且不懂HTML，PHP是比较困难的。最后，就是用插件，不但可以一劳永逸，而且，还可以给别人分享，以上呢，就是插件的成因了。

WordPress是一个事件触发的系统，我们写插件基本上依赖的也是WordPress内部的事件来触发我们自定义的动作。

WordPress事件，能够触发两种动作，一种，就叫动作（Action），就是说某件事情发生了，能诱发一个动作，写插件的时候，你就可以在这个动作发生的时候，做一些自定义的事情。

另一种呢，叫做过滤器（Filter），就是说某件事情发生的时候，诱发一个动作的同时，把相关的数据都传送过来，允许你对数据进行过滤，变更等。

看过源代码的都知道，这两者的实现机制其实是一模一样的，具体运行的代码都是同一段代码，所以说，WordPress插件一般选用两种中的一种来进行开发，但是并非非得用其中一种，就不能用另一种实现。其选择原则，一半就是方便，符合逻辑，好理解，易管理。

然后来看看这个插件的本质是什么，就是在显示文章信息的时候，后面附加一段文字。自然而然的，我们想到了过滤器，将文章读入，然后附加一段文字，再把修改后的东西输出。（当然，你硬是要用Action来做这个事情也没什么不可以，这个就当成读者自己思考的题目吧，用Action怎么做这个事情呢？）

好了，既然知道了是要用一个能过滤文章内容的Filter，那么我们就去把它找出来吧。到哪里找呢？

http://codex.wordpress.org/Plugin_API/Filter_Reference

没错，正是官方文档。这不是最好的找寻之处，最好的在源代码里。但是这是最方便的。足够用来开发插件了。

我们知道了要用的这个过滤器叫做the_content。

然后，我们就要动手开发了。（有些东西不想重复说了，就是一些ABC，可以看看插件开发API，那是我翻译的文档。）

首先，准备好要插入的文字，可以先用个普通网页把东西调试好，然后，写成字符串的模样。

$bottem_string = '

';
$bottem_string .= '

作者：' . get_the_author_url() . '">' . get_the_author() . '

';
$bottem_string .= '

原文链接：' . get_permalink(get_the_ID()) . '">' . get_the_title() . '

';
$bottem_string .= '

';
?>

就像上面的样子。

然后，我们来写一个函数，把这些东西放进去。

function add_info($content = ''){
//在这里放上上面的那些串，然后进行连接操作
}
?>

函数内部的东西，我就不赘述了，要做的就是将上面的串，连接到content后面。

最后，就是将这个过滤器，跟the_content这个Filter挂钩（Hook）。

add_filter('the_content','add_info',1,1000);
?>

到此，一个插件，就算完成了，你看到这里，完全可以自己动手试试看的。

当然，一个插件的完成，还需要考虑一些因素的，以后再找机会说吧，感兴趣，你可以从代码里看。

插件下载

http://sexywp.com/downdown/add-bottom-info.rar

标签：develop, plugins, WordPress

插件开发全攻略（目录）

Charles — Sun, 06 Jul 2008 03:33:58 +0000

隔了这么久，终于将这个系列文章都翻译完了，这么一遍走下来，实在觉得自己很浅薄，技术和语言水平都十分有限。恐怕也没有全部传达原作者的意图。

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

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

原来的目录页面在：这里

还提供PDF版本的下载哦。

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

标签：develop, plugins, translate, WordPress

插件开发全攻略（12）---发布并推广你的WordPress插件

Charles — Thu, 03 Jul 2008 04:10:26 +0000

在你完成了你了不起的WordPress插件后，在你发布和推广你的插件之前，还有一些事情需要考虑。

发布前

努力遵循标准

虽然遵循WordPress编码规范不是必须的，但是有些东西确实可以让你的生活变得简单。其中最有价值的一个建议是永远不要使用简写的PHP。原因呢？并非每个人都会将简写开启。

所以，不要这样写：

/*your php code*/ ?>

而要这样写：

/*your php code*/ ?>

确保你已经完全测试了你的插件

找一些爱好者来测试你的插件。技术上来说，专门的测试人员是好的，但是你还是希望有一些普通的并不懂得编程语言的用户来测试。

找到所有的bug是不可能的，但是至少努力推出一个稳定的版本。

确保你有一个Readme文件

在你把插件向大众公开之前，确认一下你是否有一个Readme文件。这个文件应该包含最基本的安装流程介绍。对于一个要求严格的readme文件版本，请检查WordPress推荐Readme格式。甚至有一个绝妙的Readme文件验证器。

设立一个专门的WordPress插件页面

Ajay D'Souza曾经写过如何发布WordPress主题的建议。他的建议也可以在某种程度上用在插件之上。

确保你设立了一个专门的插件页面。在这个页面上，用户可以找到关于这个插件的任何东西。这个插件的页面至少要包含以下的东西：

对你的插件的一个简单描述
下载链接
特性列表
安装指南
版本历史
已知的bugs和冲突
截图或者demo
联系或者支持信息（或者允许评论

上述信息将帮助你提升你的插件，尤其是描述和特性部分。

有一个好的目录结构

我会力劝你总是把自己的插件放在一个目录里面，除了主要插件文件外的任何文件都应该放在子目录里面。确保你zip，gzip或者rar你的插件，使得人们可以非常简单的安装你的插件。

你的插件需要修改模板或者文件修改吗？

如果你的插件需要修改模板的设置或者文件，做好被bug报告和等待的帮助猛攻的准备。我认为，一个好的插件绝对不需要修改主题或者某个文件的。除非这个插件往WordPress内核中添加了模板标签。

如果你的插件确实需要模板修改或者文件修改，在你的下载页面包含一些详细的例子，并且尽可能在你的发布中包含一些demo。

推广你的插件

在你拥有了你专门的下载页面后，是时候发布你插件的信息使得人们来下载你的插件了。你花在你的插件描述和特性的撰写上的时间是非产关键的，因为这决定了人们会否采用你的插件。其他人链接到你的插件也非常重要。

在Weblog Tools Collection推广

一个推广你的插件的很好的地方是在Weblog Tools Collection。在他们的插件发布栏目，你可以将你的详细描述投递，推荐你的插件。

在WordPress插件数据库推广

WordPress插件数据库是另一个添加你的插件的好去处。添加你的插件的过程不是那么一帆风顺的，但是有详细的指导。

在WordPress官方插件库推广

WordPress自己提供了主机来存放你的插件。不过，在你被允许添加你的插件之前，你必须满足几个条件。记住，任何宣传都是好的宣传。

使用社会网络推广

将你的插件添加到delicious，digg，和Stumble Upon。让你的朋友来帮忙。如果你的插件足够好，推荐就会广为流传。

在你自己的博客上推广

如果你的插件是人们会注意到的，在你自己的博客上使用吧。人们会开始问，你使用的到底是什么插件。口口相传是非常有效的，尤其是在博客社区内。

结论

你可以拥有世界上最好的插件，但是如果没有正确的发布和推广，只有很少的人会下载它。一旦你开始你的推广过程，倾听特性需求和bug报告是非常重要的，尤其是你的插件非常年轻的时候。如果你的插件不起作用，或者太多的人使用的时候遇到问题，人们下载的时候就会非常担忧。所以，在早期修复那些bug和添加重要的特性是非常重要的。绝大多数这样的问题可以在测试的过程中解决，但是有些bug只有在官方发布后才能看到。

写在《插件开发全攻略》系列的结尾

感谢您阅读插件开发系列文章的最后一篇。希望这个系列能够让您受益，并且帮助你为撰写自己的插件建立基础。非常感谢您的阅读。

标签：develop, plugins, translate, WordPress

插件开发全攻略(11)---在你的WP插件中使用AJAX

Charles — Tue, 01 Jul 2008 05:41:23 +0000

越来越多的插件开始使用AJAX技术。我个人并没有在大多数的插件中看到过AJAX，但是使用AJAX来完成某个任务对你的插件来说可能是必要的。这篇文章将像你展示怎样在你的插件中使用AJAX。

这篇文章将在上一篇文章《在插件中添加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。我已经在这个文件中放了如下的代码：

if (!function_exists('add_action'))
{
require_once("../../../../wp-config.php");
}
if (isset($dl_pluginSeries)) {
$dl_pluginSeries->showComments();
}
?>

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

定义showComments函数

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

function showComments() {
global $wpdb;
$devloungecomments = $wpdb->get_row("SELECT count(comment_approved) comments_count FROM $wpdb->comments where comment_approved = '1' group by comment_approved", ARRAY_A);
echo "You have " . $devloungecomments['comments_count'] . " comments on your blog";
}
?>

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

让JavaScript知道你的博客在哪里

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

if (function_exists('wp_enqueue_script')) {
wp_enqueue_script('devlounge_plugin_series', get_bloginfo('wpurl') . '/wp-content/plugins/devlounge-plugin-series/js/devlounge-plugin-series.js', array('prototype'), '0.1');
}
?>

换成：

if (function_exists('wp_enqueue_script')) {
wp_enqueue_script('devlounge_plugin_seriess', get_bloginfo('wpurl') . '/wp-content/plugins/devlounge-plugin-series/js/devlounge-plugin-series.js.php', array('prototype'), '0.3');
}
?>

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

编写JavaScript

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

php
if (!function_exists('add_action'))
{
require_once("../../../../wp-config.php");
}
?>
Event.observe(window, 'load', devloungePluginSeriesInit, false);
function devloungePluginSeriesInit() {
$('devlounge-link').onclick = devloungePluginSeriesClick;
}
function devloungePluginSeriesClick(evt) {
var url = "/wp-content/plugins/devlounge-plugin-series/php/dl-plugin-ajax.php";
var success = function(t){devloungePluginSeriesClickComplete(t);}
var myAjax = new Ajax.Request(url, {method:'post', onSuccess:success});
return false;
}
function devloungePluginSeriesClickComplete(t) {
alert(t.responseText);
}

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

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

结果

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

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

标签：develop, plugins, translate, WordPress

插件开发全攻略（10）---在你的WordPress插件中使用Javascript和CSS

Charles — Wed, 25 Jun 2008 13:24:04 +0000

现今的许多插件对javascript和层叠样式表依赖更多了。将你插件中的javascript和css放置到分离的文件中是非常重要的，那样做会使插件维护起来更加容易。此系列中的这个部分将介绍怎样在你的插件中加载javascript和CSS文件。

添加你的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_register_script('my_script_handle','http://yourdomain.com/wp-content/plugins/your-plugin-directory/js/script.js', array('prototype'),'1.0');

wp_enqueue_script函数

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

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

wp_enqueue_script('my_script_handle','http://yourdomain.com/wp-content/plugins/your-plugin-directory/js/script.js', array('prototype'),'1.0');

一个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：

function addHeaderCode() {
if (function_exists('wp_enqueue_script')) {
wp_enqueue_script('devlounge_plugin_series', get_bloginfo('wpurl') . '/wp-content/plugins/devlounge-plugin-series/js/devlounge-plugin-series.js', array('prototype'), '0.1');
}
$devOptions = $this->getAdminOptions();
if ($devOptions['show_header'] == "false") { return; }
?>
}

上述代码的工作如下：

首先，检查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
你已经添加了下面的代码 在文章的末尾：取得博客留言的数量

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

#devlounge-link{
background-color:#006;
color:#fff;
}

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

function addHeaderCode() {
echo '' . "\n";
if (function_exists('wp_enqueue_script')) {
wp_enqueue_script('devlounge_plugin_series', get_bloginfo('wpurl') . '/wp-content/plugins/devlounge-plugin-series/js/devlounge-plugin-series.js', array('prototype'), '0.1');
}
$devOptions = $this->getAdminOptions();
if ($devOptions['show_header'] == "false") { return; }
?>
}

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

标签：develop, plugins, translate, WordPress

插件开发全攻略（09）---WordPress插件和数据库交互

Charles — Mon, 23 Jun 2008 07:58:48 +0000

当你编写一个插件的时候，你将不可避免地要将一些变量存储到数据库，或者将它们从数据库中取出。幸运的是，WordPress通过options和一个数据库对象，使得存取数据变得很简单。本文将会谈及如何在一个WordPress数据库中存储或者取回数据。

在数据库中存储数据

将数据存储到WordPress数据库，主要有两种方法：

创建你自己的表。
使用Options

由于绝大多数插件不需要它们自己的表，所以，我将只讨论使用options的方法。然而，WordPress Codex上面详细讨论了怎样设定你自己的表的方法。

WordPress Options

使用WordPress Options，在数据库存储和取回数据就跟函数调用一样简单。WordPress为options提供了四个函数：

add_option
get_option
update_option
delete_option

add_option

add_option 函数接受四个参数，option的名字是必须的。四个参数是： add_option($name,$value,$description,$autoload);

使用这个函数来添加将来要从数据库中取出的数据是很有好处的。

参数 $name 必须是独一无二的，否则你就会覆盖别人的option，或者别人会覆盖你的option。

我通常不用这个函数，因为 update_function 完全可以做相同的事情。

get_option

get_option 函数允许你取回事先存储在数据库里的option。它只接受一个参数，就是option的名字。函数的格式是： get_option($option_name);

update_option

update_option 函数工作方式和 add_option 是一样的，除此之外，如果option已经存在，该函数会更新option的值。当往数据库中存储数据的时候，我个人喜欢使用这个双重功能的函数，尤甚于 add_option 。

delete_option

delete_option 函数从数据库中删除options。函数的格式是： delete_option($option_name);

一个代码范例

你可能会回忆起这个系列以前的文章中，我把options以array的形式存入数据库。这里是一个例子，并且还有一些说明分析：

//Returns an array of admin options
function getAdminOptions() {
$devloungeAdminOptions = array('show_header' => 'true',
'add_content' => 'true',
'comment_author' => 'true',
'content' => '');
$devOptions = get_option($this->adminOptionsName);
if (!empty($devOptions)) {
foreach ($devOptions as $key => $option)
$devloungeAdminOptions[$key] = $option;
}
update_option($this->adminOptionsName, $devloungeAdminOptions);
return $devloungeAdminOptions;
}
?>

在第 3-6 行，我创建了一个最终要作为option存入WordPress数据库（ 12 行）的数组。我这么做是因为我不需要存储多个选项（每个选项都要查询一次数据库）。这个技术对代码臃肿，数据库查询和名字冲突都有所助益。

WordPress 数据库类

另一个在WordPress数据库存储和取回数据的强大的方法是使用WordPress数据库类对象。在一个函数中，这个类对象的引用方式如下：

function sample_function() {
global $wpdb;
}
?>

在这个变量被引用了以后，你可以访问《wpdb类中许多有用的函数》。

举例来说，假如我们想要取回WordPress博客的评论的总数。这是一个函数，通过使用WPDB类来实现这个目的：

function sample_function() {
global $wpdb;
$comments = $wpdb->get_row("SELECT count(comment_approved) comments_count FROM $wpdb->comments where comment_approved = '1' group by comment_approved", ARRAY_A);
echo $comments['comments_count'];
}
?>

上述函数完成了如下工作：

第2行，我们添加了一个 $wpdb 的引用。
第3行，我们调用了一个wpdb类内部的函数 get_row
第3行，我们从评论表（ $wpdb->comments ）中取回数据。这里我们指定返回的数据为一个联合数组（ARRAY_A）。
第4行，我们打印出结果。因为我希望数据的放回形式是联合数组，我只要调用我在SQL语句中赋值的变量就可以了，也就是 comments_count

wpdb 类是一个有着许多功能的非常大的类。我建议查看一下 WPDB类页面，看看wpdb类到底可以干些什么。

标签：develop, plugins, translate, WordPress

插件开发全攻略（08）---构建一个WordPress插件用户面板

Charles — Sun, 22 Jun 2008 10:16:20 +0000

将会有这么一种情况，你将有一个主要的管理面板，但是希望能够让独立的用户设定他们自己的偏好。在Devlounge Plugin Series这个例子中，我们添加了一个是否把文字添加到文章末尾的选项。然而，假如一个登录用户不希望看到这段文字呢？为什么不给他们一个选择，而且不影响到所有其他的用户呢？

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

命名你的选项

class DevloungePluginSeries {
var $adminOptionsName = "DevloungePluginSeriesAdminOptions";
var $adminUsersName = "DevloungePluginSeriesAdminUsersOptions";
?>

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

设定你的缺省用户选项

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

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

//Returns an array of user options
function getUserOptions() {
global $user_email;
if (empty($user_email)) {
get_currentuserinfo();
}
if (empty($user_email)) { return ''; }
$devOptions = get_option($this->adminUsersName);
if (!isset($devOptions)) {
$devOptions = array();
}
if (empty($devOptions[$user_email])) {
$devOptions[$user_email] = 'true,true';
update_option($this->adminUsersName, $devOptions);
}
return $devOptions;
}
?>

这个函数完成以下任务：

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

初始化管理用户option

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

function init() {
$this->getAdminOptions();
$this->getUserOptions();
}
?>

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

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

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

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

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

设定用户面板函数

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

//Prints out the admin page
function printAdminUsersPage() {
global $user_email;
if (empty($user_email)) {
get_currentuserinfo();
}
$devOptions = $this->getUserOptions();
//Save the updated options to the database
if (isset($_POST['update_devloungePluginSeriesSettings']) && isset($_POST['devloungeAddContent']) && isset($_POST['devloungeAuthor'])) {
if (isset($user_email)) {
$devOptions[$user_email] = $_POST['devloungeAddContent'] . "," . $_POST['devloungeAuthor'];
?>
Settings successfully updated.
update_option($this->adminUsersName, $devOptions);
}
}
//Get the author options
$devOptions = $devOptions[$user_email];
$devOptions = explode(",", $devOptions);
if (sizeof($devOptions)>= 2) {
$content = $devOptions[0];
$author = $devOptions[1];
}
?>

上述代码：

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

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

echo $_SERVER["REQUEST_URI"]; ?>">
Devlounge Plugin Series User Options
Allow Content Added to the End of a Post?
Selecting "No" will disable the content from being added into the end of a post.
if ($content == "true") { _e('checked="checked"', "DevloungePluginSeries"); }?> /> Yes if ($content == "false") { _e('checked="checked"', "DevloungePluginSeries"); }?>/> No
Allow Comment Authors to be Uppercase?
Selecting "No" will leave the comment authors alone.
if ($author == "true") { _e('checked="checked"', "DevloungePluginSeries"); }?> /> Yes if ($author == "false") { _e('checked="checked"', "DevloungePluginSeries"); }?>/> No
_e('Update Settings', 'DevloungePluginSeries') ?>" />

}//End function printAdminUsersPage()

设定用户面板Action

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

//Initialize the admin and users panel
if (!function_exists("DevloungePluginSeries_ap")) {
function DevloungePluginSeries_ap() {
global $dl_pluginSeries;
if (!isset($dl_pluginSeries)) {
return;
}
if (function_exists('add_options_page')) {
add_options_page('Devlounge Plugin Series', 'Devlounge Plugin Series', 9, basename(__FILE__), array(&$dl_pluginSeries, 'printAdminPage'));
}
if (function_exists('add_submenu_page')) {
add_submenu_page('profile.php', "Devlounge Plugin Series User Options","Devlounge Plugin Series User Options", 0, basename(__FILE__), array(&$dl_pluginSeries, 'printAdminUsersPage'));
}
}
}
?>

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

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

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

标签：develop, plugins, translate, WordPress

您可能也喜欢：
Yii框架的Log系统的分析	Yii框架中验证器的allowEmpty属性	使用Gii时出现403错误	MVC最佳实践	Yii框架base包代码分析
无觅

您可能也喜欢：
视频教程：使用Yii框架开发Blog	Yii框架的Log系统的分析	Yii框架中验证器的allowEmpty属性	MVC最佳实践	Hybrid 资源一览
无觅

您可能也喜欢：
WordPress 开发资源	使用NetBeans IDE 6.5作为WordPress的开发环境	使用Google AJAX Libraries API替换WordPress自带的js库	插件开发全攻略(11)---在你的WP插件中使用AJAX	无侵入与可用性层
无觅

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

您可能也喜欢：
使用NetBeans IDE 6.5作为WordPress的开发环境	WordPress插件开发实例--（01）	WordPress插件开发实例--(02)	插件开发全攻略（06）---WordPress插件Filter	插件开发全攻略（03）---怎样获得WordPress插件的创意
无觅

您可能也喜欢：
百度和谷歌的低俗度测评	天啊！Google Code中文版……	参观雪龙号	WordPress 开发资源	关于键盘你可能不知道的事~
无觅

您可能也喜欢：
WordPress主题：GoogleCode	WPTheme: twentieth 测试	免费WordPress主题	WordPress插件：选项查看器	WordPress主题的迷思
无觅

您可能也喜欢：
使用Google AJAX Libraries API替换WordPress自带的js库	为什么要给博客添加Contact Form联系表单？	美味书签和Google Bookmarks	使用NetBeans IDE 6.5作为WordPress的开发环境	在WordPress中使用统计工具
无觅