不谢的紫藤花

聊过 WordPress 、 ExpressionEngine 与 SaBlog-X 的优缺点后(见 闲谈 WordPress ExpressionEngine SaBlog-X )，接下来我说一下数据转换的问题。如果你喜欢 ExpressionEngine 或 SaBlog-X ，但却无法将 WordPress 的数据导入到新的系统中，那不是很郁闷吗。

ExpressionEngine 自带的导入脚本很有限，只有一个 Movable Type Import Utility 。所以 WordPress 到 ExpressionEngine 要经过一个中间步骤，那就是将数据导出为 Movable Type Import / Export Format ，然后再倒入 ExpressionEngine 。最近， WordPress 版本更新很频繁，导致以前的的几个导出脚本都失效了，我在 Instructions on how to run the export script 找到的脚本还能使用，适用于 WordPress 2.3.x-2.7 。为了方便，我已经打包在下面的附件里了。

导出数据以后，就简单了，按着 Movable Type Import Utility 提示做就可以了。只是无法将 WordPress 的 Permalink (或者叫做 post slug) 导入到 ExpressionEngine ，希望以后有达人能修改一下导入导出脚本，那就好了。

WordPress 到 SaBlog-X 1.6 的数据转换在 SaBlog-X交流论坛 就有相应的脚本，不过 SaBlog-X 需要在数据库中保存日志的段落符、换行符等，而WP没有，所以导入WP的数据后，Sablog-X 的段落都是挤在一起的，我对它做了一点修改，利用WordPress 的 wpautop() 函数，在数据导入之前，先将日志格式化。这样，转移数据后就不用手动一篇篇的更改日志了，日志多的时候那可是一项体力活。

SaBlog-X 2.0 到 WordPress 的数据转移可以参考 Utombox 的 SaBlog export WordPress eXtended RSS ，ExpressionEngine  到 WordPress 的迁移目前还没发现简单的方法。

附件：WordPress 到 ExpressionEngine 及 SaBlog-X 1.6 的数据转移脚本 。

我一直想找一个理想的 CMS ，现在比较看好的有 WordPress 、ExpressionEngine 与 SaBlog-X，但在这三个中做一个选择却有点困难。

我们先说说它们的优点吧：

1. WordPress ：
   插件众多，扩展性强，模板丰富，升级方便。WordPress 是开源软件，而且也是世界上使用人数最多的博客程序，遇到问题的时候不会发生找不到人交流的情况。这也是导致同类程序两极分化的一个原因，用的人越多，作者开发越积极，于是越来越好；反之则渐渐被冷落。WP定制性很好，配合插件甚至可以实现 tumblelog 、图片博客(photoblog)、链接目录(link directory)等另类用法。
2. ExpressionEngine ：
   凭借优秀的模板系统，ExpressionEngine 在网页设计师中的评价很高。模板的灵活性是一般程序无法相比的，插件数量一般。可定制的内容表单，有这个可以做各种各样的网站了。即将发布的 2.0 版本采用 CodeIgniter 框架，全新设计的后台界面，更优美、更人性化。(大家可以看一下我写的 ExpressionEngine 2.0即将发布,管理面板新界面值得期待 )。使用 ExpressionEngine 构架的网站，值得推荐有两个： Veerle’s blog 、 Bartelme Design 。
3. SaBlog-X ：
   国产的博客程序，卓越的访问速度和负载能力，可以在极为繁忙的服务器环境下快速稳定运行。强大的 Spam 信息防御机制和内置 WAP 浏览功能，给 Blogger 带来了很多方便，至少不用再为盯着你不放的 Spammer 烦恼了。开发中的 2.0 版本对 SEO (搜索引擎优化)及模板系统都做了大量改进。活跃用户：tension.name，他也是 Sablog-X PLUS 的开发者。

再说说它们的缺点吧：

1. WordPress ：
   性能低下，访问量较高时对数据库的压力很大，CPU 时间占用会飙升。即便开启内置的 Cache 或者使用 Cache 插件，效果还是那样糟糕。模板使用 php 标记嵌套，要求有一定的 php 基础。功能越来越多，但最基础的性能却没多大改进。
2. ExpressionEngine ：
   ExpressionEngine 是一个商业程序，其中 ExpressionEngine Core 对个人免费，但是 ExpressionEngine Core 连最基本的tag功能都没有，有点可惜。URL唯一性 很差，经常是多个 URL 指向同一个页面，这对SEO来说相当糟糕。就这一点来说，WordPress 做得很到位。
3. SaBlog-X ：
   插件几乎没有，模板也很少，毕竟使用的人较少。模板中许多变量的参数都写死了，不利于设计个性化的模板。同样的 URL唯一性 很差。

总结一下，如果只想纯粹地写博客，推荐 Sablog-X 。如果喜欢捣弄网站，需要各种功能，那么 WordPress 是你的不二选择。喜欢网页设计，需要经常展示给客户的， ExpressionEngine 很适合你。
三个程序中，我觉得值得赞扬的有：WordPress 的编辑器及内置的tag系统，Sablog-X 的负载能力，ExpressionEngine 的模板系统。

我的建议是：

• WordPress 不要吝啬数据表，把附件跟 post 分开比较好。
• SaBlog-X 不要把日志中 html 标记写进数据库，这样可以减少数据库中的垃圾，格式化内容还是放在输出的时候比较好。
• ExpressionEngine 内建tag系统是相当有必要的，实现起来应该不困难。集成一个所见即所得编辑器可以带给用户更好的体验。

就到这吧，说的有点罗嗦了。

WordPress 2.6发布了，说实话我并不是很喜欢这个版本。虽然WordPress 2.6增加了一些新的功能，对安全性方面也有了一定的提升，例如对SSL支持等，但是它对数据库的整洁来说，还是一团糟。

新版中增加的一个重要功能是Post Revisions(文章的版本控制)，作者可以对比查看文章的不同版本，并恢复到以前的状态。但是，文章的不同版本，数据库中该放在哪里呢？答案是wp_posts。默认状态下，所有的实质内容都记录在这个数据表中，包括文章、图片视频音频等信息。而wp_posts的PRIMARY KEY为ID，于是一篇文章常常要占用3个不同的ID，它们记录了文章的3不同状态Current Revision、Autosave、Revision，也就是当前版本、自动保存的版本还有以前的版本，如果修改过多次，就会出现revision-2，revision-3…  于是乎，文章的Id不再连续了，特别是Permalink结构为archives/123形式的博客，上一篇为archives/100，当前这一篇可能就是archives/105了，看起来是相当的乱啊。

WordPress真的很吝啬，这么多版本过来了，数据表的数量仍然是10个，我想只要增加几个数据表，WP的数据就不会显得那么凌乱。本人并不提倡像ExpressionEngine这样，数据表多达68个，但20个以内并不过分吧。

个人建议增加的数据表有：

• wp_temp：存储临时文件，如wp_options中的rss内容、wp_postmeta中的edit_lock和edit_last
• wp_plugin：存储插件的配置信息，这样就不至于因为安装太多插件而把wp_options弄得一团糟
• wp_revision：用来记录文章的旧版本及自动保存的内容

这样，只要做一下简单的清理，数据库就显得有条有理了。

WordPress的其它问题还有：
1. 数据表wp_options中category_children、rewrite_rules的option_id总是不断改变
2. 如果你编辑过WordPress目录下的.htaccess，只要进入Settings - Permalinks，即使没有点击”Save Changes”，.htaccess也会追加以下内容：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress

这极易导致服务器500错误。建议安装后WordPress后，将.htaccess文件的属性改为只读。

WordPress的功能是越来越强大了，伴随而来的是文件体积的增长，现在的wordpress-2.6.zip都已经1.44MB了。有时候我在想，我只不过想要一个简单的blog程序而已，有必要用一个庞然大物吗。有点期待Sablog 2.0的到来，只是小A迟迟不发布，难道要等到传说中的奥运？

Update：经williamlong的提醒，原来Post Revisions是可以禁用的，只要在wp-config.php文件中增加一行define(’WP_POST_REVISIONS’, false);就可以了，williamlong说得对，应该在设置中增加启用/禁用选项，毕竟类似Wiki那种文章历史版本控制对一般的Blogger来说没多大意义。

众所周知，WordPress的URL自定义功能(WordPress称之为Customize Permalink Structure)十分强大，但是，它对URL格式的处理却不怎么理想。假设WordPress安装在blog目录下，我举几个典型的例子说明一下。

当Permalinks格式设置为/%postname%/时，
各链接格式分别如下：
文章链接：/blog/post-name/
分类链接：/blog/category/category-name/
存档链接：/blog/yyyy/mm/,如/blog/2007/10/
不可否认,这样的链接格式相当不错，简练工整，对搜索引擎也十分友好。

当Permalinks为/entry/%postname%/格式时，
各链接格式如下：
文章链接：/blog/entry/post-name/
分类链接：/blog/entry/category/category-name/
存档链接：/blog/entry/yyyy/mm/,如/blog/entry/2007/10/
显然，分类链接和存档链接中的”entry”并不是我们希望出现的。

再换一种Permalinks，/%post_id%.html。许多人认为加上”.html”，网页看起来更像静态页面，有利于搜索引擎的收录。本人也比较喜欢这种格式。
请看各链接格式：
文章链接：/blog/post_id.html，如/blog/123.html
分类链接：/blog/category/category-name
存档链接：/blog/date/yyyy/mm,如/blog/date/2007/10
大家注意到了吗，分类链接的最后少了一根斜杠”/”，这对SEO来说并不是很好。/blog/category/category-name，浏览器请求的是category目录下的category-name文件，而/blog/category/category-name/浏览器请求的是 category-name目录下的索引文件，两者之间的区别是非常大的。存档(Archives)链接也存在着同样的问题。
还有，存档链接中”date”关键字的加入，虽然可以用来区分”post_id”与”yyyy”，以防止请求混乱，但我个人觉得去除”date”链接形式更统一，更工整，只是不清楚这样做是否存在一定的技术难度。

对WordPress Permalinks的建议总结如下：
将分类链接固定为/blog/category/category-name/的形式，绝不能因Permalinks设置(如加入”entry”,”archives”等)的改变而变化，并且链接最后的斜杠”/”不能缺少，存档链接的斜杠同样不能少。

希望WordPress的开发人员也发现了这个问题，让WP越来越完善。

WordPress 2.3-beta3发布了，趁着空闲把blog升级了一下。后台的页脚比2.2.*紧凑了许多，看起来舒服多了。但是tags相关的管理功能依然没看见，不知道下周一发布的Release版中会不会加上。

试着打开WordPress内置的cache机制，虽然SQL查询有所减少，但页面的执行时间非但没有缩短，反而有所增加，或许当Blog访问量很大的时候表现会比较明显。至于我还没必要使用。
开启WordPress内置cache的方法：在wp-config.php中添加
define(’ENABLE_CACHE’, ‘true’);

Feedburner被阻尼时，刚碰到学校校区的迁移，忘了更换Feed链接。顺便在这里公布一下，请记住我的新 Feed 地址：

http://snsnow.com/blog/index.xml，永不改变。

PS:或许有人会说，为什么Feed地址不用WP默认的/feed/,何必再Rewrite呢？那我只能说是个人爱好了。

doubanclaim533d7724c8a1e2d8

今晚把Wordpress从2.1升到了2.1.1,这次升级大约修复了30个bug,更新文件如下:
wp-includes/post-template.php
wp-includes/cache.php
wp-includes/formatting.php
wp-includes/category.php
wp-includes/post.php
wp-includes/version.php
wp-includes/js/scriptaculous/wp-scriptaculous.js
wp-includes/js/tinymce/tiny_mce_config.php
wp-includes/js/tinymce/wp-mce-help.php
wp-includes/js/tinymce/tiny_mce_gzip.php
wp-includes/capabilities.php
wp-includes/cron.php
wp-includes/functions.php
wp-includes/bookmark-template.php
xmlrpc.php
wp-admin/admin-ajax.php
wp-admin/admin-functions.php
wp-admin/custom-header.php
wp-admin/options-general.php
wp-admin/edit.php
wp-admin/index-extra.php
wp-admin/options-reading.php

升级很简单,上传覆盖以上文件,进入后台时会提示升级数据库,按提示操作即可.
整体感觉不出有什么变化,但既然是bug修复,那还是建议尽快升级.