Version 2.1.0

* remove jquery dependency
* re-orgnize the js code
 

Version 2.0.2

Add an verification code when user posting a comment to keep robots away. You can use an image verification code or a math equation instead.

Robots may post lots of spam comments into your database. You can add a verification code image or a math equation to avoid this.

Features:

• You can choose a verification code image or a math equation as you wish
• You don’t need to edit any source code of WP, you just need to active the plugin 

1.  configuration panel
   
   
    
2.  a verification code image

   

3.  a verification math equation

   
   
    

4.  the error message when invalid code was entered

   

 Change Log:

1.0.0   Finish the basic functions

2.0.0

* Change the skin of code and input box
* Position of the box can be choosen
* Number of characters can be set
* Fix the bug in Chrome that code does not appear
* Case sensitivity is configurable now for string mode
* Length of string is configurable now for string mode
* Position os verification code box could be coufigurable now

2.0.1, 2.0.2

* bug fixed

2.1.0
* remove jquery dependency
* re-orgnize the js code
 

Download/Install:

http://wordpress.org/extend/plugins/verification-code-for-comments/

Explanation to the configuration:

其实我本无意在这里批评什么或者指责什么，事实上，我自己的插件也没有用上心，只是满足了自己的需求就发了出来。

wp-codebox是一个不错的插件，我不知道wp-syntax与之哪个在前哪个在后，只是我看了两者的源代码，发现惊人地相似。

wp-codebox最近更新了，我很想知道它到底更新了什么，到插件主页一看，什么介绍也没有，看了源代码才知道，原来整个源代码的组织形式都有所改进。

实际上，我两个插件都有安装，但只激活了wp-codebox，原因是对于wp-syntax，我没有找到设置选项，也就是说，要设置你就得改源代码，这也太不方便了。于是，我坚定而固执地选择了wp-codebox

之所以说固执，是因为有这样一件事情。我目前所用的这款主题，最新版本里加了一条，支持wp-syntax，于是我很奇怪，去问主题的作者，作者的回复是，wp-codebox不支持w3c标准。后来我一验证，果然如此。但我仍然没有禁用它，只是将不符合标准的地方改掉了：

将

<script language="javascript">...</script>

改成了

<script type="text/javascript">...</script>

可是最近一次更新，我实在无法忍受作者测试并未通过（至少我现在采用的wp版本，2.8.5也未通过）。

我无论怎么修改codebox.css，样式都没有变化，后来发现codebox.css并没有加载。作者在源代码中是这样写的：

add_action('wp_print_scripts', 'Codebox_ScriptsAction');
function Codebox_ScriptsAction ()
{
    $cb_path = get_bloginfo('wpurl') . "/wp-content/plugins/wp-codebox"; //URL to the plugin directory
    if (! is_admin()) {
        wp_enqueue_script('jquery');
        wp_enqueue_script('codebox', $cb_path . '/js/codebox.js', array('jquery'), '0.1');
        wp_enqueue_style('codebox', $cb_path . '/css/codebox.css',array(), '0.1',screen);
    }
}

但实际上wp_print_scripts这个hook并不会加载style，而作者却将style也写在了里面。我修改成如下代码后，可以正常运行：

add_action('wp_print_scripts', 'Codebox_ScriptsAction');
function Codebox_ScriptsAction ()
{
    $cb_path = get_bloginfo('wpurl') . "/wp-content/plugins/wp-codebox"; //URL to the plugin directory
    if (! is_admin()) {
        wp_enqueue_script('jquery');
        wp_enqueue_script('codebox', $cb_path . '/js/codebox.js', array('jquery'), '0.1');
        //wp_enqueue_style('codebox', $cb_path . '/css/codebox.css',array(), '0.1',screen);
    }
}
// pwwang
add_action('wp_print_styles','Codebox_StylesAction');
function Codebox_StylesAction(){
    $cb_path = get_bloginfo('wpurl') . "/wp-content/plugins/wp-codebox"; //URL to the plugin directory
    if (! is_admin()) {
        //wp_enqueue_script('jquery');
        //wp_enqueue_script('codebox', $cb_path . '/js/codebox.js', array('jquery'), '0.1');
        wp_enqueue_style('codebox', $cb_path . '/css/codebox.css',array(), '0.1',screen);
    }    
}

就像上次wp-codebox和quick-comments插件不兼容的问题一样，我没有任何抱怨地进行了修正，因为我也深有体会，写一款有用的插件并不是一件容易的事，这里也一样，我也没有抱怨，只是，虽然问题解决了，但我也决定放弃wp-codebox转而投向wp-syntax的怀抱。

0. 前言

    你想到了一个很有创意的点子？你写了一个很酷的插件？

    Oh，no！wordpress官网上的发布步骤太长了，还是E文。

    难道你的插件只能躺在插件包里，还是只放在你的网站里让寥寥无几的人下载？

    相信这篇文章能让你的插件不再山寨。

1. 准备工作

1. 你得有一个插件吧：）
   你的插件最好是别人没有写过的。这个你可以在官网上搜索一下，后面还会提到这一点。
2. 在 http://wordpress.org/extend/plugins 申请一个帐号。
   你很快会收到一封邮件，里面会有密码。我找了一下，没有找到在哪里修改密码。。。
3. 安装svn
   其实，前面的几步都没有什么好说的，整个插件的发布，关键还是在于svn的使用。至于安装，我在这里就不细说了，大家可以搜索一下，有很多讲安装的文章。给出subversion的下载页面：http://www.collab.net/downloads/subversion

2. 提交申请

    你需要向wordpress.org提交你的插件发布申请。

    这里就要强调最好你的创意是别人没有的，或者是没有类似的插件，这样插件发布申请会比较容易通过申请。

    提交申请大概一天（周末时间可能会长一些），就会收到邮件，告诉你申请通过了云云。

3. 插件截图及写好你的readme.txt

    你需要对插件截几张图，关于设置或者使用的。

    关于readme.txt，官网有专门的验证工具 readme validator 和标准 WordPress/bbPress plugin readme file standard ，我在这里只是说一下各部分会显示在什么地方。

    === plugin name ===

    这部分内容会出现在你插件页面右侧的信息栏中，当然，author信息会出现在下面的Description中。

    == item ==

    类似的内容会出现在下面的各个Item中。

    Screenshots中，对应的图片名字为screenshot-1.png …， 并在readme.txt中对图片进行说明。

4. 上传插件   

    以上的工作做好之后，你就可以开始上传你的插件了。这里就涉及svn的使用了。

1.  关于subversion
   所有的文件都会存储在服务器的仓库中。所有的人都可以从这个仓库中将插件下载到本地。但是只有插件作者可以登入，那就意味着你可以在本地修改文件，添加文件，删除文件并且将这些改动上传到服务器。这样既可以更新仓库中的文件，也会修改显示在wordpress.org的插件目录中的信息。
    
2. 在本地创建一个插件目录(把你的插件文件都放进去)：

   $ mkdir my-local-dir

3. 检查你的仓库

   $ svn co http://svn.wp-plugins.org/your-plugin-name my-local-dir
   > A    my-local-dir/trunk
   > A    my-local-dir/branches
   > A    my-local-dir/tags
   > Checked out revision 11325.

4. 把文件copy到trunk目录下(代码和官网不一样，但目的一样)

   $ cd my-local-dir/
   my-local-dir/$ cp * trunk/

5. 让svn知道你想把文件加到仓库中

   my-local-dir/$ svn add trunk/*
   > A    trunk/my-plugin.php
   > A    trunk/readme.txt

6. 开始上传你的插件吧

   my-local-dir/$ svn ci -m 'Adding first version of my plugin'

   回车之后会要求你输入用户名密码，这个就是你在官网申请的用户名密码。完了之后下面就开始显示和传输文件，最后会显示版本号。

    很快，你就可以在官网插件目录中找到你的插件啦 ：）

5. 修改插件

1. 检查本地版本是不是最新的，否则你就需要从仓库中下载最新的版本

   my-local-dir/$ svn up
   > At revision 11326.

   看这个版本号是否和你最后一次提交的版本号一致。
    

2. 对你的插件进行修改，工具无所谓你可以用vi,nano,gedit,甚至记事本

   vi trunk/my-plugin.php

3. 检查本地文件的状态

   my-local-dir/$ svn stat
   > M    trunk/my-plugin.php

   M 说明你已经对这个文件进行了修改（Modified）

4. 你可以使用svn diff来查看修改过的地方
5. 提交你的修改到服务器

   my-local-dir/$ svn ci -m "fancy new feature: now you can foo *and* bar at the same time"
   > Sending    trunk/my-plugin.php
   > Transmitting file data .
   > Committed revision 11327.

6. 标记一个新的版本

    用版本号来标记：   

my-local-dir/$ svn cp trunk tags/2.0
> A tags/2.0

    提交更新：

my-local-dir/$ svn ci -m "tagging version 2.0"
> Adding         tags/2.0
> Adding         tags/2.0/my-plugin.php
> Adding         tags/2.0/readme.txt
> Committed revision 11328.

之前写了一篇 非插件防垃圾评论， 用的是简单的数学等式。但是需要对主题中comments.php以及wp-comment-post.php进行修改，不太方便。于是便动手写了一个插件，不仅可以采用数学等式验证，更可以使用图片验证码。

Add an verification code when user posting a comment to keep robots away. You can use an image verification code or a math equation instead.

Robots may post lots of spam comments into your database. You can add a verification code image or a math equation to avoid this.

Features:

• You can choose a verification code image or a math equation as you wish
• You don’t need to edit any source code of WP, you just need to active the plugin

1. 

   configuration panel

2. 

   a verification code image

3. 

   a verification math equation

4. 

   the error message when invalid code was entered

 Change Log:

1.0.0   Finish the basic functions

Download/Install:

http://wordpress.org/extend/plugins/verification-code-for-comments/

Contributors: dean pwwang
Donate link: http://pwwang.com/
Tags: post, fckeditor, editor, WYSIWYG, code
Requires at least: 2.2
Tested up to: 2.7.4
Stable tag: trunk

Description

This plugin replaces the default WordPress editor with Dean’s FCKeditor with pwwang’s code plugin

FCKeditor is an open source WYSIWYG text editor ,brings to the web much of the power of desktop editors like MS Word.it’s lightweight and is compatible with most internet browsers which include: IE 5.5+ (Windows), Firefox 1.0+, Mozilla 1.3+ and Netscape 7+. Dean Lee has modified it and made it fit for wordpress.

Features:

• media buttons
• Build-in File manager and upload manager
• Build-in WordPress "read more" Button
• Integrated with WordPress media buttons
• Manage and insert smileys into your post
• Customize editor’s skin
• —above: Dean’s had, below: pwwang added—
  ** Build-in "Insert Codes" Button
  ** Block wordpress codes(pre lang="…")
  ** Support mainstream code highlight plugin(wp-codebox,wp-syntax)
• 内建“插入代码”按钮
• 将你插入的代码保护起来，代码标记（pre lang=""）
• 支持主流代码高亮插件（wp-codebox,wp-syntax）

Installation

1. Upload this plugin to the /wp-content/plugins/ directory.
2. Deactive or uninstall(RECOMMANDED) Dean’s editor.
3. Activate the plugin through the ‘Plugins’ menu in WordPress.

Frequently Asked Questions

1. Browsers supported? IE & Firefox

Screenshots

1. fckeditor 
   
2. build-in "Insert Codes" Button
   
3. "Insert Codes" Dialog
   
4. "Edit Codes" popMenu
   

Changelog

=1.0= with code plugin

Official Page URI: http://wordpress.org/extend/plugins/deans-fckeditor-with-pwwangs-code-plugin-for-wordpress/

WordPress，个人觉得就是为喜欢折腾的人而生的。我就是其中之一，并乐此不疲。

好的插件总想跃跃欲试，好的效果，总是想改了再改。

无论是wp程序的更新，还是主题的更新与更换，我总是要小心翼翼地做好备份。因为程序已经被我改得遍体鳞伤，记得上次更新主题，改到之前的效果，不知道耗死了多少脑细胞！

对于插件，我就更无语，能让人省心的插件还真不多。当然，这也不能怪作者，他们也不可能所有的情况都考虑到，所有的环境都测试到。往往我改过的插件，我都不敢再更新，我的做法就是把他们的版本改得很高。让wordpress不再自做多情地提示升级插件。

无论有多么强大的功能，wp只是一个博客程序，最基本的功能还是发文记事。一个好的编辑器是必不可少的。然而wp自带的编辑器为免显得寒酸了点。这时强大的FCKEditor就有了用武之地。

Dean将其改为wp所用，并加入了wpmore插件，可以很方便的插入readmore。上一个版本是2.5。最近出来3.1。当时我看到FCKEditor有更新的时候，真的欣喜万分，真的很期待很多问题能够解决掉。不过让我失望的是，问题没有解决，还出现了新的问题。原来的编辑器和新的编辑器在Firefox下都表现良好。而IE则出现了各种各样奇怪的问题。

原版本的问题是，如果你的文章中含有某些HTML元素（具体是哪些，这个我没有测试），就无法切换到源代码视图。我看了一下出错的信息：this.Elements[...].outerHTML为空或不是对象。找到出错了那一行，加了一个判断语句： 

if(this.Elements[i]){ //pwwang
    this.Elements[i] = '<div> ' + this.Elements[i].outerHTML + '</div>' ;
    this.Elements[i].isHtml = true ;
}

 这样就不影响切换到源代码视图了。

而新版本的问题则更为离谱，先是好用的wpmore插件没了，然后是载入不了文章（这个有可能是网络的问题），最大的问题在于，切换到源代码视图（无法切换的问题已经得到修正）后，竟然无法切换到所见即所得模式视图，这个真是有点不可容忍，于是赶紧卸载了，装回原来的2.5版本。这个时候如果报错的话，检查一下是否需要重新生成smily图片缓存（在wp的设置中）

至少现在2.5在发一般的文章时问题还是不大的。于是将2.5的版本版了一下（在插件主文件的前几行注释中），以免wp总是提示升级。

说了这么多，还没有到代码的问题上来。

上面说过，dean’s fckeditor for wordpress 2.5在发一般文章时是很好用的，可是如果你想贴代码，那可谓是苦不堪言。并且一旦你的文章写好了，你就不敢再修改了，因为你不知道fckeditor会把你的文章变成什么样子。FCKEditor会把你的代码中与HTML相关的代码进行自动转换！！但是，这不能怪fckeditor自作多情，因为fckeditor的很多操作都要用到dom，如果你插入的代码打乱了dom树，那fckeditor的很多功能就不能用了，甚至很有可能崩溃。

那我们就眼睁睁和看着我们的代码被蹂躏得面目全非吗？？

No, never!!

早前我就有过尝试，我开始以为是我们用的代码插件对我们的代码抛了媚眼。后来才发现我错了，其实它们（wp-codebox,wp-syntax）从来就没有勾引过我们的代码，也没有从中拿过回扣，他们只是在显示的时候让不同的字符串穿上不同的衣服而已。

那到底是谁动了我们的代码？

毫无疑问，只有编辑器。仔细看就知道，你在源代码视图下输入好的代码，切换到所见即所得视图，再切换源代码视图的时候，代码就已经面目全非了。而写进数据库的，就是源代码视图下的那些字符！我们在源代码视图下敲入的字符就是我们想存进数据库的东西，你乱动个什么？！可是原因我已经在前面解释了，它也很无奈，为了生存啊！之前我写的那篇《告别wordpress贴代码的烦恼》，只治到了标，而没有治到本，之前有想过不让编辑器动我们的代码，可是看看fckeditor的源码，只能望而却步，于是退而求其次，既然你编辑器动了我的代码，那我在显示的时候再动回去就行了。这样在发表和显示文章的时候都没有问题，可以问题还是出在编辑文章上，因为开始编辑文章的时候，语法高亮插件根本就插不上脚！编辑器这时候终于威风一把。

其实想想，有时候我们是需要编辑器对我们的代码动动手脚的。你想想，如果你在源代码视图中，某个tag的名字敲错了怎么办？或者某个tag忘了关闭怎么办 ？如果编辑器不能你纠正的话，等到发表后，在网页中显示的时候，那就很有可能打乱你整个网站的结构了！这一点也不耸人听闻！

那很明显，我们只是想它不动我们的代码而已。而现在主流的语法高亮插件都是通过pre来实现的，就像上面提到的wp-codebox和wp-syntax，语言则采用lang来指定。那就好办了，我们只需要在编辑的时候将这个pre块保护住就行了。

怎么保护？

思路很简单，我们可以先正则表达式将这样的代码块找出来，然后将这些代码块在所见即所得视图下用FakeImage来保护住（FCKEditor的一种机制）。那么我们现在可以来整理一个整个思路了。

我们可以在fckeditor中添加一个工具栏插件：

然后弹出一个对话框，让用户输入语言类型，其他属性以及代码：

代码输入好之后，确定，在所见即所得视图下就会出现一个Fakeimage：

点击右键就可以编辑代码了。这样就算你切换到源代码视图，再切换到所见即所得视图，代码还是被保护住的。（这时候Firefox会将换行转换成br，只需要点击那个Translate BR按钮就可以恢复格式。这一点，IE倒不会转换。）特别值得提一下的是，如果你插入的是HTML代码，请使用Translate <>按钮，这样可以保护你的HTML代码不被浏览器当作源代码处理（这个要先按照《告别wordpress贴代码的烦恼》进行修改）。另外，这样还可以防止你的代码中含有</pre>而将代码截断（正则匹配采用的非贪婪模式）

以后，无论文章里是否包含代码，都可以在源代码和所见即所得视图中随意切换。

后记：

贴代码的问题相信已经困扰了wordpresser们很久了。现在总算有了一个初步的方案。

想说的，还是浏览器的问题。

由于IE没有很好的js调试工具，所以一直是在firefox下调试开发完成的。另外FCKEditor的插件机制实在不敢恭维，至少仅仅在插件目录中写代码是难已完成的。这一点，wp就要好多了。当然，客户端语言和服务端是没法相比的。直到所有的功能在firefox下运行正常之后，我才去ie下测试。

开始的问题的右键点击FakeImage根本就没有Edit Codes菜单出现。还以为是浏览器的缓存问题（IE总是喜欢自作多情的缓存，浏览器真应该有个选项，是否禁用缓存。速度上虽然是快了，但是却给开发者带来不少的麻烦，话说回来，反正MS就没有为开发人员切身考虑过，Firefox下的Web Developer插件就能很好地禁用缓存），后来发现并不是，而是IE根本就无法判断右键菜单的listener是FakeImage，原来IE下要获得一个元素的class属性，用getAttribute(‘class’)是得不到的，只能用getAttribute(‘className’)。真的有点莫名。

在Firefox下功能正常后，我以为会松下一口气，可是没想到，右键菜单的问题解决后，IE又出了问题。它把我所有代码中的换行和制表符全部都变成了空格，这怎么行？代码的美感就来自于此。原来，我在往源代码视图插入代码的时候，获取了原来代码块的代码，然后通过innerHTML赋给了新建的DOM元素pre，问题就出在这个innerHTML上，Firefox中是没有问题的，可是在IE中，问题就是这么千奇百怪。于是迅速上百度Google一下，说的都是innerHTML自动闭合标签和把标签名转变为大写的问题，这样的问题压根没有。这下我可真有点泄气了，好好的一个功能就要实现了，难道要夭折？

这里也许有个会说，插入的时候直接用HTML字符串插入，这样就不会转换了吧。是的，我也这么想，可以FCKEditor不这么想，它只能采用DOM结点的方式进行插入。于是想到了是否可以将HTML字符串转换成DOM Node，再上百度Google，找到一个，但是我一看有innerHTML，就觉得没戏了。

乍然想起jQuery不是可以直接将字符串转化为jQuery对象吗？

我先用jQuery测试了一下，

$('#a').append(HTML2Element('<pre>FCKCode.prototype.Execute=function()\n{\n\tvar oPre = FCK.EditorDocument.createElement( \'pre\' );\n\tvar oFakeImage = FCKDocumentProcessor_CreateFakeImage( \'FCK_Code\', oPre) ;\n\toFakeImage    = FCK.InsertElement( oFakeImage ) ;\n}</pre>'));
 
function HTML2Element(str){
    var $div = $('div').append(str);
    return $div.children(0);
}

发现测试成功，浏览器将换行和制表符都原封不动地输出！IE&Firefox表现都正常。

可是，我总是至于要把jQuery也拉进来吧，本来FCKEditor就不小了。jQuery的插入的实现也是要通过dom的吧，那jQuery肯定在某一步将字符串转换为了Node。翻开jQuery的源码，发现DomManip函数就是干了这样一件事。可是我看到下面仍然用了innerHTML。由于就很奇怪了，难道jQuery用了什么魔法让IE的innerHTML听话了？

于是将jQuery的DomManip（可以转换多个HTML字符串）函数简化，测试了一下，也成功。对比了一下，发现DomManip的innerHTML插入的时候字符串是用tag包裹好的元素，而我插入的就是一个字符串。问题出在这。那么一个简单地将单元素的HTML字符串转化为Node的函数就出炉了：

function str2Node(str){
    var $div = document.createElement('div');
    $div.innerHTML = str;
    return $div.childNodes[0];
}

顺带贴一下将Node转化为HTML字符串的函数，其实就是IE下outerHTML，可惜Firefox不支持：

function node2HTML(node){
    var t = node.tagName;
    var ret = '<'+t;
    var attrs = node.attributes;
    for( var i=0; i<attrs.length; i++ ){
        attr = attrs[i];
        if( attr.specified ){
            ret += ' ' + attr.name + '="' + attr.value + '"';
        }
    }
    ret += '>' + node.innerHTML + '</' + t + '>';
    return ret;
}

这样，就可以不经innerHTML的转换将字符串转化为Node从而插入FCKEditor的源代码视图。按照这个思路，问题终于圆满解决！

一切都是折腾惹的祸！

事情是这样的：

一直以来我都想用上quick comments，因为每一次访客留言的时候，如果输入有误，系统就会直接调用wp-die，给出一个硬生生的报错页面，并且没有返回按钮，用浏览器返回之后，事先敲入的字符就会全部88。

在这款皮肤的版本还是3.X的时候，我试了一下，不行，效果是页面直接跳到了要载入的ajax结果页面，很是郁闷。后面这款皮肤出了4.X的新版本（先在这里感谢作者），作者在更新历史上明确地写上了支持quick comments，后来我对比看了一下，皮肤作者把留言form中的元素用jQuery作选择器的方式作了一下改变，简单地说，就是把 #commentlist 改成了 .commentlist（我不太确定是不是还有其他的原因作这个修改），其实这个在quick comments中是可以设置的。说得有点远了。。。

我激活了quick comments，可以和之前的效果一样，我不禁开始怀疑作者在更新日志里那么明确地写上支持quick comments到底是什么意思？明明说好了支持，怎么还是不行。。。我只好望ajax兴叹了。

不甘心，于是用firebug进行调试（在提交留言的时候显示有js错误）。提示是

I(this).block 没有定义

真是奇了怪了，quick comments的作者在加载script的时候加载了jquery.blockUI啊，我以为是这个js文件没有加载上，于是我在这个js文件中加了一句话。什么，你问哪句话？就是这句：

alert(12345);

结果在重载页面的时候就听到“叮咚”一声，弹出来12345！其实我之前已经在Web developer里看到了jquery.blockUI.min.js已经加载了。只是不死心而已。

但是我继续不死心，在这个文件的最下面又加了一句话：

alert(jQuery['blockUI']);

结果是叮咚一声，出来一个undefined！天哪，我真是要抓狂了，上面定义了(function($){ $.blockUI = function(){…} })(jQuery);  接着在下面alert居然是undefined.

我真的有点手足无措了。

。。。。。。

我找到了一个用quick comments的博客，把它的源代码打开看了一下，发现blockUI和scrollTo的调用在比较靠前的地方，于是我尝试着改add_action的priority（作者采用这个来加载js，priority可以用来设置执行的优先级），仍然未果，实际上调用顺序并没有改变。

一怒之下（其实早就怒了），我把这个页面另存为，把所有的js文件都下载下来，在本地运行。并在头部加了一段js：

jQuery(function(){ alert('jQuery['blockUI']') });

依然是undefined，于是我在上面这段代码之上又加了一段代码：

(function($){ $.blockUI = function(){...} })(jQuery); 

就是把blockUI自己定义一下，这下就出现了自己定义的内容，于是我明白了，在调用jquery.blockUI的地方到上面这段代码之间有一些js代码这blockUI给“洗”掉了。

然后，我把jquery.blockUI往不同的地方移，最后终于发现，洗掉它的是wp-codebox调用的jquery.js（这之前jquery.js已经被调用了）！到这才发现是wp-codebox惹的祸。。。万恶的wp-codebox。三下五除二，把wp-codebox中调用jquery.js的地方注释掉，以为问题解决了。

当回到首页的时候，发现wp-codebox又无法正常了，因为缺少了jquery.js！首页不需要quick comments，所以也没有调用jquery.js。

于是把wp-codebox中注释掉的地方改了一下，如果jQuery存在，则不调用jquery.js，反之则调用之。

$hHead .= "     <script type=\"text\/javascript\">\n";<br />
$hHead .= "             if(typeof jQuery === \"undefined\"){\n";<br />
$hHead .= "                     document.write('<script language=\"javascript\" type=\"text/javascript\" src=\"".get_bloginfo('wpurl')."/wp-includes/js/jquery/jquery.js\"><\/script>');\n";  //这里是修改后动态调用，modified by pwwang<br />
$hHead .= "             }\n";<br />
$hHead .= "     </script>\n";<br />
//$hHead .= "   <script language=\"javascript\" type=\"text/javascript\" src=\"".get_bloginfo('wpurl')."/wp-includes/js/jquery/jquery.js\"></script>\n";  //这里是直接调用

至此，wp-codebox与quick comments终于和睦共存。。。

在此也要提醒那些写插件的朋友们，如果要用到jquery，在调用jquery.js文件之前，请先做一下检测！

在主题文件夹里找到comments.php文件,在你想要显示输入框的地方加入代码:

     <div class="row">
    <input type="text" name="cal" id="cal" class="textfield" value="" size="24" tabindex="4" />
    <label for="cal" class="small"><?php
        $b = rand(1,9);
        $c = rand(1,4);
        if($c==1){$a = rand(0,40); $s = '+';}
        elseif($c==2){$a = rand(0,30)+$b; $s = '-';}
        elseif($c==3){$a = rand(0,5); $s = '*';}
        else {$a = $b*$c; $s = '/';}
        echo _e("$a $s $b = ?", 'elegantbox'); ?> <?php if ($req) _e('(required)', 'elegantbox'); ?>
    </label>
    <input name="a" type="hidden" value="<?php echo $a;?>" />
        <input name="b" type="hidden" value="<?php echo $b;?>" />
    <input name="c" type="hidden" value="<?php echo $c;?>" />
      </div>

在文件wp-comments-post.php中加入如下代码进行验证:

if ( !$user->ID ) {
    $a = trim($_POST['a']);
    $b = trim($_POST['b']);
    $c = trim($_POST['c']);
    $sub = trim($_POST['cal']);
    if($c==1) $res = (bool)($sub == $a + $b);
    elseif($c==2) $res = (bool)($sub == $a - $b);
    elseif($c==3) $res = (bool)($sub == $a * $b); 
    elseif($c==4) $res = (bool)($sub == $a / $b);
    else $res = false;
 
    if(!$res || empty($sub)){
        wp_die( __('Error: please enter the right calculating result.') );
    }
}

另外,顺便记录一下这次wordpress升级改动的地方

1. 文章存档和链接的分栏显示 修改参考:wp侧栏内容分列显示技巧

2. 修改wp-codebox, (如果wp-codebox更新了的话) 修改参考:告别wordpress贴代码的烦恼

3. 修改评论验证, 即本文所述的内容

有时候侧栏（sidebar）里的有些内容只做一列显示，显得有点浪费空间了，特别是像我这种两栏的主题。像文章按月存档，链接等等。于是我就想办法让他们分两列（甚至更多列）来显示，以节约空间。

其实前面有一篇文章 使AutoBlogroll分两列显示链接  已经提到过一些，这里再总结一下。

主要的方法还是通过css来控制，尽量少的改动程序代码。下面就以存档挂件和链接挂件来说明。这两个挂件都是主题自带的，我没有使用其他的插件。

先说存档的部分。存档部分要分两列显示还有个问题，就是月份名字太长了，如September，采用它的缩写形式（Sept.）是最好的。好在WP也提供了它们的缩写。（当然语言为中文的用户就不存在这个问题了）

先说说怎么把月份名改成缩写形式，找到wp-includes/general-template.php，第767行：

$text = sprintf(__('%1$s %2$d'), $wp_locale->get_month($arcresult->month), $arcresult->year);

这个就是显示存档的月份和年份的，把它修改成：

$text = sprintf(__('%1$s %2$d'), $wp_locale->get_month_abbrev($wp_locale->get_month($arcresult->month)), $arcresult->year);

具体原因，大家可以查看$wp->locale这个类。好了，这样存档的月份就显示为缩写形式了。

接着说分列显示，使用的是css的一个小技巧。还是上面那个文件，第671行：

$link_html = "\t<ul><li>$before<a title="$title_text" href="$url">$text</a>$after</li></ul>\n";

修改成：

$link_html = "\t<ul><li style="float: left; width: 124px; list-style-type: none;">$before<a title="$title_text" href="$url">$text</a>$after</li></ul>\n";

就是在里面加上一个css属性，其中的width是你侧栏宽度的一半，当然如果你想分三列显示就是三分之一，依此类推。

本来这样貌似已经大功告成了，但是如果你内容中的li是单数，则会出现这样的问题,下一挂件的标题会接到最后一个li的后面，这是由于float:left所造成的：

这个问题也好解决，我们采用一个br clear=”all”就行了，这样的换行就可以达到效果。找到你主题根目录下的functions.php这个文件（有可能不是这个文件，视主题而定），总之就是定义$after_widget的文件，找到这么一行：

'after_widget' => '</li> ',

改成：

'after_widget' => '</li><br clear="all" />',

这样就大功告成了。

而链接的修改只需要上面后面的两个步骤，最后一个步骤是共用的，上面已经修改了，因此只要添加那个css属性就行了。找到wp-include/bookmark-template.php，第55行：

'before' => '<ul><li>', 'after' => '</li></ul>', 'between' => "\n",

改成：

'before' => '<ul><li style="float: left; width: 124px; list-style-type: none;">', 'after' => '</li></ul>', 'between' => "\n",

一般大家都用的是可视化的编辑器，如FCKEditor，甚至wp自带的编辑器都是可视化的。

大家习惯了（至少我是）在可视化的模式化写东西，我想没有谁去一个个敲HTML源码吧。。。

但是在贴代码的时候会有一些问题，如 "a"=>2 ; 你在可视化的模式中敲下这行代码，再转入源代码看就变成了 &quot;a&quot;=&gt;2; ，当然， 如果你不用语法高亮插件，这个时候在前台显示是没有问题的，一样能显示 "a"=>2 ;  ，但是我想贴代码如果不高亮，那就犹如一张黑白照片，古板而没有生机。

但是如果你采用一些语法高亮插件（我用的是WP-codebox），你就会发现你的烦恼来了，如果你的代码是在可视化模式下输入的，那么在前面就显示&quot;a&quot;=&gt;2; （WP-codebox是，其他我未用），然而这并不是我们想要的效果，以往我的做法就是在源代码的视图下贴代码，自己编辑源代码，并且文章一旦写好，就再也不敢修改，因为一修改在源代码视图里写好的东西又被转换了，苦不堪言。也想过换插件，可是又怕以前贴的代码乱了，一直没换，再者，开始用语法高亮插件的时候也看过一些插件的比较的文章，觉得还是这款效率好一些。

下面来说如何解决这个问题。

其实思路也很简单，编辑器把HTML编码了，我们再解码就行了。也曾想过让编辑器不转换HTML代码，但是发现很麻烦，因为并不是所有的HTML都不需要转换，对于wp-codebox，pre以外的代码是需要的，于是放弃了这个想法，然后只能让wp-codebox委屈一下，在处理之前先把被编辑器转换过的代码再转换过来，因为wp-codebox只处理pre的代码，所以不会干扰其他的代码。

打开wp-codebox的文件main.php，其中在这么一行：

$geshi = new GeSHi($code, $language);

在这一行改成：

$geshi = new GeSHi(wp_codebox_unhtmlentites($code), $language);

然后再在这一页的其他地方添加一个函数：

function wp_codebox_unhtmlentites($string) { //把被编辑器转换的HTML代码转换回来
    static $aTransSpecchar = array(
        '"' => '"',
        ' ' => ' ',
        '&lt;' => '<',
        '&gt;' => '>',
        '&amp;' => '&',
    );
    return strtr($string, $aTransSpecchar);
}

 这个时候，你在可视化模式下输入的代码是什么样，就是什么样了，再也不用担心编辑器把HTML的特殊字符转换了，并且写好的文章可以随便的修改了。

如果其他高亮插件有同样的问题，可以参照上面的修改办法进行修改就可以解决问题了。