首先就是那个可视化编辑器无法载入的情况。我碰到的问题，是所谓的“找不到元件（object）”。解释出来的意思就是，相关.js都没载入；因此这个TinyMCE编辑器，根本就是影踪全无。按照以往经验，我先把所有插件停用，然后用排除法一个一个试验。

说到停用所有插件，有一个简便的办法，就是把原来的/wp-content/plugins目录改名为/wp-content/plugins~，然后新建一个空plugins目录。这样子，一下子所有插件都停掉了。如果要重新激活一个插件，只需要把那个文件从plugins~目录移动到plugins目录就行了。当然，你有可能需要在后台的插件列表里面重新激活一下。

回过头来继续说这个TinyMCE编辑器的事。我花了点功夫把所有插件给试验了一遍，结果发现根本不是因为插件不兼容而引起的问题。真正的问题，出在tiny_mce_gzip.php这个文件上。它的作用，是把tiny_mce的javascript脚本通过gzip协议传输，降低传输时间，加快载入速度。我碰到无法载入的原因在于，php.ini中有错误的设定。因为我在自己的Dreamhost上面安装、编译了自己的PHP（v4.4.2, phpinfo() ），所以之前无意中鬼使神差地修改了php.ini里面有关output_handler 的部分。结果呢，php默认就是通过gzip输出内容，虽然我把Wordpress后台里面“阅读”菜单中的gzip选项关闭了，但是TinyMCE仍然坚持着使用gzip输出，于是，自然载入失败了。值得一提的是，在调试过程中，我还试着下载了最新版的TinyMCE 2.0.9 混进了Wordpress，期望能解决问题。结果发现，还是不行。网上有人指出说，让Wordpress避免载入这个tiny_mce_gzip.php，而是直接载入TinyMCE提供的一个静态.js文件可以解决问题。我也试验了，似乎只是部分解决了问题。因为Wordpress中的TinyMCE是经过特别调整的专用版本（也有人戏称是阉割版本），所以有的按钮会发生无法使用的问题。好在，最终我找到了主要问题所在，算是不用伤筋动骨就恢复正常了。

还有一个有趣的部分是，网上有文章提到说如何打开Wordpress内置的TinyMCE中隐藏的按钮。具体可以去Google搜索，修改很简单，修改以后可以打开一个叫做Show/Hide Advanced Toolbar 的按钮，点击一下就可以显示/隐藏额外的一行编辑器按钮，包括字体、大小、样式之类。要知道，完整版本的TinyMCE可是有着整整三行的按钮呢，呵呵。有兴趣不妨试试看。

第二个问题，是有关AJAX和Comment的。现在的网站，特别是博客，都注重AJAX化（AJAXify）整个系统。和用户体验特别有关的就是评论（或者翻译成留言、回复）部分。之前我一直使用Inline AJAX Comment 这款插件。但最近发现，总是有些不明原因的错误出现，更主要的问题是，这不利于提升站点的粘性，因为大家在首页就看到了所有评论，看完就走了。相比较之下，到单篇文章页面阅读评论，虽然增加了一次点击，但是提供了更多的吸引访客的机会（比如在单篇文章的页面加入最新发表和相关文章两个列表等等）。同时，点击进入以后，撰写留言的表单也出现了，对增加访客留言率或许会有帮助。权衡再三，我还是去掉了这个插件。

取而代之的，并非那个很有名的台湾编程美女“懒懒喵”的作品AJAX Comments Reply ，而是AJAX Comment 。原因很简单，前者属于Wordpress Hack，修改了源代码，过程比较麻烦是小事，不利于系统的升级和完整性才是真正让我有所顾虑的。AJAX Comment我觉得比较优秀，并且支持一款叫做AuthImage的插件，能够提供从Captcha图片验证、无刷新评论提交、错误信息反馈、新留言即时显示的统一解决方案。具体来讲，安装过程也不顺利。使用中总是出现javascript错误（看来这是AJAX特性的一个致命缺陷，因为javascript的错误调试实在不便），我找来找去找不到原因。后来终于发现，我使用的这款Theme叫做Tiny（另有个修改版本叫作TinyMod），也作了一些修改，但是一直没发现，作者把评论表单的提交按钮的名字命名成了submitComment，这不是一个规范的名称。对于AJAX Comment插件来说，提交按钮的名字必须是submit才能正常运作。做了修改以后，就一切正常了。

此外，我特别要提一下AuthImage 这款插件的插件。它提供的设置选项丰富，调试起来相当有趣。具体显示可以看本页面最下方的Demo。它的优点在于，可以动态刷新验证图片；缺点在于，默认设置下的验证图片是在很丑，甚至很难辨认（真人很难辨认… orz）。我选择的是背景图片模式，去掉了大部分花里胡哨的背景图片，只留下来了两张，而且用Photoshop去掉了颜色变成灰度，并且调整了亮度对比度。虽然，相对来说防机器识别能力下降了，但可读性好多了。想来我这样的小站犯不着有人用机器识别 来对付我吧？我还调整了字体变形的算法。因为单靠设置还不能达到要求，所以对于源代码略为有些小的改动。

第三个修补，是使用广泛的Admin Drop Down Menu 插件。一切都好，就是不晓得为什么，不论我使用谁出品的中文包（就是zh-CN.mo文件），后台的撰写和管理的中文翻译就是不出现。一直是Write和Manage。这不是什么影响使用的问题，但是不彻底的菜单中文化总让人觉得看着别扭。忍了很久以后终于发现了原因。在插件的adminmenus.php 文件中的aws_correct_core_menus() 函数里，作者加了一些关于后台界面措辞的修订。

 // make some corrections
 $menu[5][0] = “Write”;
 $menu[5][1] = “edit_posts”;
 $menu[5][2] = “post-new.php”;
 $menu[10][0] = “Manage”;
 $menu[10][1] = “edit_posts”;
 $menu[10][2] = “edit.php”; 

 因此，中文语言文件找不到可以匹配的英文单词进行翻译，后台菜单就显示出来Write和Manage了。修改很简单，只要把这两行给注释掉就可以了。看一下你的后台，是不是有“撰写”和“管理”的字样出现了？

最后说一个插件问题，是有关Google Sitemap 插件的。我很喜欢这个自动生成.xml格式站点地图文件的插件，效果可参见本页面最下方的xml sitemap 图片。只是有个问题，它有时候会无法显示图片。因为这个图片是通过插件动态生成的（作者把Gif图片用二进制格式包括在插件的.php文件里了），所以只需要直接把这个图片的地址拿来单独放在浏览器里面一看，就看到出错信息了。

原来，在发送图片的Header之前，已经有插件提前给浏览器送出了Header，就是这个叫作Display WP FeedReader 的插件（WordPress美女懒懒喵的又一个插件作品~）。归根结底，问题出在我为了中文化这个插件，把插件里面的几个英文翻译成了中文；为了避免乱码，整个文件使用了UTF8的格式来存储。而UTF8格式的插件.php文件在被系统加载的时候，似乎就已经送出了Header了。解决办法也简单，把中文改回英文，然后把文件存为普通的非UTF8的格式就好了。或许这个不是最好的解决办法。不过先凑活着用吧，等我有了更好的解决办法再说。

呼，说了这么多。目前我的Wordpress运作健康。可我总有不停尝试安装新插件的坏习惯。不过，在不停的Debug修补过程中，对于Wordpress的理解也加深了。或许有空的时候会写一个自己的插件吧？呵呵，倒是有一些想法了。