一直使用Firefox，偶尔用IE上一下这个Blog，却发现Sidebar显示在了首页所有文章的下面，究其原因，原来是在最近的几篇文章中，有几个pre或code元素的宽度超出了左边这部分的宽度，从而占用了右边的Sidebar的空间，而IE又没有很好的解决Overflow的问题（参见Migrate apps from Internet Explorer to Mozilla中的CSS overflow differences部分），于是在css中添加如下代码：
#sidebar {position: absolute; left: 120px;}
将Sidebar改为绝对值定位，问题解决，同时将pre和code加上了
overflow: auto;
这样贴代码的时候如果宽度太宽，会自动出现水平滚动条的，当然，由于IE没有很好的支持这项属性，因此在IE下是看不到这个效果的。
WordPress的Permalinks还是比较好用的，只需要在Options->Permalinks里设置一个/post/%post_id%，基本就可以了，但它的Permalinks样式偶不喜欢，偶喜欢的样式是：
单篇文章
存档
分类
分页
作者 其实也没啥用
feeds
Permalink的样式固定以后，即使以后再更换其它的Blog系统，也按照这个样式来设定，加上把数据也导过去，基本上能够保证用户使用以前的链接也能正常访问新系统的内容。
WordPress生成Permalink的程序主要在wp-includes\classes.php里，有一个WP_Rewrite类。
如果要修改存档的Permalink，只要找到function get_date_permastruct()部分，在靠后的位置有一句
$this->date_structure = $front . $date_endian;
在它前面加上一句
$front = '/archive/';
就可以了，其余的也类似：
$this->front = '/author/'; $this->author_structure = $this->front . $this->author_base . '/%author%';
$this->category_structure .= '%category%'; //下面这一句是增加的 $this->category_structure = '/category/%category%';
然后再修改.htaccess文件，修改相应的规则就可以了，由于只是简单的替换了一下前面的固定单词，所以很好修改的。如果没有.htaccess文件，在Options里设置一下Permalinks就会自动生成了。
由于两种Blog使用的字符集不一样，所以移植的重心是unicode字符到utf8字符的转换，剩下才是数据表之间的对应。
首先用phpMyAdmin把plog的数据导出来，要知道导出来以后的sql文件中，中文都是这种乱码形式的：
INSERT INTO `plog_mylinks` (`id`, `category_id`, `url`, `name`, `description`, `blog_id`, `rss_feed`, `date`, `properties`) VALUES (1, 1, ‘http://blog.plogworld.org.tw/’, ‘pLog 中文開發日誌’, ”, 1, ‘http://blog.plogworld.org.tw/rss/rss20/1′, ’2005-05-17 21:59:37′, ‘a:0:{}’);
配合网上找到的unicode2gb函数，可以把这些乱码转换为utf8字符，不过在转换前，有两个东西需要注意，第一个： \是\，plog不认的，需要先手工替换过来，否则转换有错误提示：
Notice: Undefined offset: 92 in E:\web\20051106\unicode.php on line 68。
而WordPress对\不感冒，所以直接在sql文件中替换就可以了。 第二个：“”—这几个字符总是会引起附近出现乱码（第三个好像还不是中文的破折号），手工替换成自己命名的符号，比如< –left quote–>，在中文转换完毕之后再替换回来就可以了。
网上有unicode2gb函数，不过不是太好找，并且需要的gb2312.txt也不好找，所以我打包放在了这里，需要的同志可以去下载。
现在最麻烦的事情来了，由于sql文件中有简体中文，也有繁体中文，所以unicode2gb函数需要略微调整一下，把：
$code=0x8080|$_global_codetable2[$code];
$gb.=chr((($code & 0xFF00)>>8) & 0xFF);
$gb.=chr($code & 0xFF);
改为
if (isset($_global_codetable2[$code]))
{
$code=0x8080|$_global_codetable2[$code];
$gb.=chr((($code & 0xFF00)>>8) & 0xFF);
$gb.=chr($code & 0xFF);
}
else
{
$gb .= '&#' . strval($code) . ';';
}
使用码表文件gb2312处理完毕之后，本来想着用繁体中文的码表处理一遍就可以了的，但转换出来的中文有乱码，所以经过半天的琢磨，终于发现了解决方法－－先换用码表gb12345.txt转换一遍，还剩下一些没有转换的字符，然后再用big5.txt这个码表转换，在最后使用这个big5.txt码表文件的时候，还需要增加把繁体中文字符串转换为简体中文字符串的处理，所以上面的编码又要改动为：
if (isset($_global_codetable2[$code]))
{
$code=0x8080|$_global_codetable2[$code];
$strbig5 = '';
$strbig5.=chr((($code & 0xFF00)>>8) & 0xFF);
$strbig5.=chr($code & 0xFF);
$gb .= mb_convert_encoding($strbig5, 'GBK', 'BIG5') ;
}
else
{
$gb .= '&#' . strval($code) . ';';
}
这样，这个sql文件终于成了全中文，基本无乱码，下面在本机建一个utf8_general_ci的mysql数据库，把sql导入进去。
然后的事情就简单了，通过本地mysql查询和对sql文件进行正则表达式替换，先后生成往wp_categories、wp_posts、wp_post2cat表中添加数据的sql，还有修改wp_posts表中post_date、post_date_gmt、post_category等字段的sql，在本地测试后，一一导入WordPress，就大功告成了！
在生成sql语句的时候还要注意，除了VALUES里面能够使用单引号’来标识字符串之外，其余标识数据库表名和字段名的引号一定要是键盘左上角的`，使用单引号mysql会提示错误。
主要指的是图片啦，两者都可以很好的保存我想在网上发布的图片，pLog可能更个人化一些，但速度不理想、功能不够丰富、对空间也有要求；而Flickr让我有点不放心（哪天改收费了、哪天Down了、哪天我的图片没了都有可能吧？），但却更方便，速度也快，也不用担心空间问题。这两个活宝，用哪个好呢？一直在琢磨，但说老实话，pLog Album的功能太少了，也不是特意针对图片来优化的，还兼顾了其它格式的文件，不如Flickr专业，并且Flickr被Yahoo收购了，不放心的程度有所降低，所以在目前尽可能的使用Flickr吧。
原来也在使用cpg来管理图片，但它傻傻的把所有图片都放在一个目录里，真无法忍受（pLog也一样，这样应该不太适合上千张图片的处理），尤其是升级到1.3.3以后，居然无法上传图片了，提示什么“程序被呼叫而没有需要的参数. ”，真是太让我伤心了，我都存了几百幅图片了，不知道以后的版本能否更好些。
比没有安装的时候快多了，远不止Zend官方所说的40%，难道pLog针对Zend op做了优化？还是说Zend Op的优化算法适合pLog的OO结构？
