WP 2.1 和 ELA 的兼容性问题
看来 Wordpress 2.1 真是个 trouble maker，和 Extended Live Archive 又发现兼容性问题，鉴于用 ELA 的人还挺多的，我拿来说说。估计他们官方又会跑出来说“是你们插件作者的错，不是我们的错”了，嘿嘿。
症状：如果你注意到的话，在 WP 2.1 中，ELA 会把新建立的页面当成文章显示出来。
那么为什么会出现这种情况呢？因为 WP 2.1 把数据库结构作了调整，以前区分文章和页面是用 post_status 这个 field 的值。如果是 post_status = ‘publish’ 那就是文章，如果 post_status = ’static’ 那说明这是页面。而到了 WP 2.1 上，页面的 post_status 也变成 ‘publish’ 了，区分文章还是页面用 post_type 判断，post_type = ‘post’ 为文章，post_type = ‘page’ 为页面。可 ELA 不知道这点啊，它还是按老方法来判断，当然会造成误判了。
修补：
- /plugins/af-extended-live-archive/af-extended-live-archive-include.php
- 寻找 post_status = ‘publish’
- 替换为 post_type = ‘post’ AND post_status = ‘publish’
注意找到 p.post_status = ‘publish’ 这种，替换后应为 p.post_type = ‘post’ AND p.post_status = ‘publish’，而不是 p.post_type = ‘post’ AND post_status = ‘publish’。
除了上面说的问题，我以前也曾指出过，如果想把任意页面设置成首页，你需要关闭 ELA，否则无效。
升级 WP 2.1 后会遇到总总问题，如果不是特别需要新的功能，不妨先缓缓，等各种问题都解决了后再升级不迟。
更新：附上我改好的 af-extended-live-archive-include.php 文件，需要的朋友可以下载，把扩展名改成 .php 后直接覆盖原文件。点此下载 (适用版本：R18)
How many is too many?
看到 Alex King 的这个问题，我突然有了一个想法。我们多数人都有一个共识，那就是 WP 的插件要尽量少装，以免影响页面的打开速度。但究竟这个理论对不对呢？好像没什么人来质疑它。我用 WP 的时间不算太长，始于大概半年多些。开始的时候我谨记前辈的经验，插件能不装就不装，生怕影响了来我 Blog 的朋友的游兴。不过使用 WP 日子久了，插件的数目已经不能算少了，什么时候慢慢多起来的，自己完全没有意识。这时回想起少装插件的理论，就很想测测看，以现在的插件数量打开首页，比没安插件的状态下打开首页的时间到底长多少，以此证明这个理论是否正确，在多大程度上正确。
实验方法我打算这样。
在目前正常的状态下，也就是说用当前的主题和当前的插件，刷新 5 次首页。为避免 浏览器的 cache 起作用，使测试结果产生偏差，我每次都按 Ctrl+F5 强制刷新页面。然后记录下每次刷新所用的时间，取平均值。
把主题切换到默认，把所有的插件都关掉，同样用 Ctrl+F5 刷新 5 次，记录下每次的时间，取平均值。
怎么计算打开首页的时间呢？我打算将这行代码放在 footer.php 里，
<?php timer_stop(1); ?>
因为 php 和 html 都是顺序执行，所以执行到这行时，能够最准确的计算出主页被调出所用的时间。这个时候，浏览器的状态条可能还未停，但那可能是某些帖子要去其它网页上获取图片，跟插件无关。
好了，结果出来了，来看看。
WP 2.1 和 UTW 的兼容性问题
这个问题对用 UTW 和 Wordpress 2.1 的同学们来说，比较严重。
也许有人已经发现了，当你升到 Wordpress 2.1 后，只要有人在你的帖子上留言，或是发 Trackback 或是 Pingback 的时候，帖子的 Tag 就会消失（是被删掉，事实上）。说原因前我先贴一下修补 (via)，然后有兴趣的同学再慢慢看原因。
打开 /wp-content/plugins/UltimateTagWarrior/ultimate-tag-warrior-actions.php
在大概第 862 行你会看到：
// Save changes to tags
add_action('publish_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
add_action('edit_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
add_action('save_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
add_action('wp_insert_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
把这些代码注解掉，换上：
// Save changes to tags
add_action('save_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
if($wp_db_version < 3308 ) { // if lesser than WP 2.0
add_action('publish_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
add_action('edit_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
add_action('wp_insert_post', array('UltimateTagWarriorActions','ultimate_save_tags'));
}
这就把问题解决了。
问题的原因 Mark 在他的 Blog 上做了解释。其实这个问题并不单是 Wordpress 2.1 的原因，其实在更早的版本这个问题就是潜在存在的，不过是在 2.1 版上被带了出来。也并不单是 UTW 受影响，还有一些比如 Jerome’s Keywords 等等往 Custom Field （自定义域？） 里写数据的插件都可能受到影响。Mark 的说明细节部分我就不重复了，有兴趣的人可以去看。简单来说我理解成：这不是我们的问题，这是插件作者的问题，你们对 WP 的机制理解的不够，你们犯下这样这样的错误，你们需要如此如此才行。:wink:
通俗来说，插件作者编写插件让插件自动监视编辑文章的表格，如果是空的，插件就认为文章已经被删除，于是也会把自己在这篇文章的 post_meta 数据删除，这就是为什么 UTW 的 tag 会不见，因为被它自己删除了。但在 2.1 中，edit_post 并不是一定要在写文章或编辑文章时才会调用的，也不是一定要是注册用户的动作才能引发调用的。比如说留言就能引发 edit_post 被调用，这个时候，插件监视到的是一个空的 edit_post，它认为这篇文章已经被删除了，它就非常“智能”地清空了自己留在 post_meta 里的数据。
我用到的往 Custom Field 里写数据的插件包括 UTW, Article 和 Postviews，检查了一下，好像除了 UTW 其余两个都没事。大家也可以检查一下自己的插件，如果发现 Custom Field 里面的数据被抹除，可以联系插件作者请修改一下。
更新：看来留言的时候不一定有事，但当你审核留言时，同意后，该留言对应的文章 Tag 会被删掉。虽然审核留言的时候不多，但还是打一下后面的补丁以防万一吧。
再更新：最新的 3.14159265 版的 UTW 宣称解决了上述问题。
Wordpress 2.1 发布
代号美洲豹的，哦不对，代号 Ella 的 Wordpress 2.1 刚刚发布了。
因为昨天装了 RC2 所以正式版对我来说变化也不大。发现了几处插件兼容问题：
- Extended Live Archives 会导致不能把 Page 设为首页。
- Postviews 1.10 以前的版本会使 Rich Editor 失效。
- Tiger Style Administration 会使写文章时的 HTML 代码 TAB 错位。
从此 Wordpress 2.0.x 将和 2.1 走上两条道路。
从现在起，Wordpress 的发布周期将会缩短，一年内可以会有几次大版本的升级。Wordpress 2.2 会在 4 月 13 号发布。
说说 Habari 和 Wordpress
这两天 Habari 已经被讨论的足够多了（好吧，我承认在中文 Blogsphere 里还不够多），大家关注的重点当然是为什么这么一个明星队伍 (Michael Heilemann, Chris J. Davis, Khaled Abou Alfa, Owen Winkler, Skippy) 要离开 Wordpress 去重头再去弄一个新的 Blog Engine。虽然这上面这几位都在自己的 Blog 里作出了说明，但似乎还是没法平息人们对 Matt 逼走他们的猜疑，我个人还是认为他们只是想去创造一个按自己想法走的 Blog Engine 的。我看了一些留言，认为绝大数人对 Habari 的理念非常支持，从现在能看到的 Habari 的样品来看，Habari 还是非常值得期待的一个产品。
但必须要清楚的一点是，虽然 Habari 的核心开发人员出自 Wordpress，但它们是定位不同的一两款产品。如果不知道这点，还是不忙把手中的 Wordpress 换成 Habari，先确定自己是不是真的需要 Habari。
那么Habari 和 Wordpress 有什么不同？来说说我的两点看法。
第一
Habari 宣称要建立一个 Meritocracy 的社区，也就是说这个社区没有一个可以决定一切的老大级的人，没有一个绝对不变的核心队伍。只要你对社区的的贡献大，你就可以进核心开发队伍，你就可以决定 Habari 的方向。在 Wordpress 社区里，Matt 是老大，他是唯一一个可以对 Wordpress 的方向拍板的人，社区成员可以对 Wordpress 提出改进意见，可以对发展方向建议，但至于采不采纳你的方案，Matt 说了算。这点跟 Habari 不一样，也是为什么这帮人为什么离开 Wordpress 队伍的原因之一。
这两者之间其实没有一个谁更好的问题，采用哪种模式完全是开发者的个人选择。但使用哪种开发模式生产出来的产品却是你自己的个人选择。
第二
Wordpress 经过多个版本，已经走向了成熟，用户群体也变的非常庞大，这也使得开发者变得谨慎，功能上不可能有飞跃的变化。Habari 的重点在炫上，从 Scott 的 Blog 上看，Habari 将会有多少新技术用多少，Habari 会是一个完全的面向对象的系统，支持 OpenID, Cocomment, Atom 发布协议，PHP 将只支持最新的 PHP 5，并且支持 MySQL，PostSQL，SQLite 数据库。
因为这两点，我觉得 Habari 显得更 Geek 一点，开发者首先就是一群 Geek，他们打算把自己的所有对 Blog Engine 的想法都加到 Habari 上，同时也欢迎其他人这么做。项目的组织结构是：只要你牛，你就有决定权。不过这样会增加 Habari 的不确定性，Habari 可能会失去方向。而 Wordpress 已经比较成熟了，功能完善，社区庞大，贡献者众多，应该是目前地球上最好的 Blog Engine 了。
我的个人观点
从目前得到的信息，我看好 Habari，但谁知道最后的发展是不是像创始人宣称的那样，事情发展有太多的变数，何况 Habari 现在还在 Alpha 阶段。除非 Wordpress 社区不再是现在的 Wordpress 社区，我想我还是会坚持使用 Wordpress 下去的。直到…………我想换 Habari 的时候。
