刚刚测试了一下，7-zip（v4和v9）通过文件管理器鼠标拖拽触发的解压，会无视用户设定的临时文件夹选项（在7-zip里叫工作文件夹），使用系统默认TEMP文件夹。尝试解压20G的文件时出现系统盘空间耗尽的问题，特此记录。临时解决办法：用右键菜单解压就行了。 – 详见官方bug tracker
Tag: Bug
WP-POLLS我恨你，但错不在你
隐藏文字显示不能的问题与WP-POLLS 2.5插件有关，因为新版WP-POLLS改用了jQuery库，我便把主题内置的jQuery库取下了。然后才发现它引用的是WordPress内置的那个jQuery库。嗯哼，问题来了，WordPress使用的jQuery”库”根本不是原厂出版的，不仅混入了Sizzle JS库，还额外写了一句，jQuery.noConflict()。这万恶的一条线（用于避免JS库冲突很有用，但谁会把它写在库里？！），就把页面内任何$()变量重置了（只能使用jQuery()访问），于是隐藏文字的功能也挂了。谢谢WP-POLLS，谢谢WP的开发团队。
WordPress 2.6
自从SVN化之后，WordPress升级就没什么实感，WP2.6也是svn sw就完成了。例行说下新功能，支持Google Gear的功能比较适合像我这种跨洋开站的用户，不过就算用了Gear速度还是比不在大陆时慢很多，果然有些东西是科技救不了的；然后是类似wiki系统的revision功能，据说这样就绝对不会丢失任何吐槽，但实际上是不是浪费/复杂化数据库还得用用看；真正有意思的可能是SSL支持，自此WordPress也终于支持安全登陆了，反动站长小命可保？
余下的都是些鸡肋功能，说实话我觉得应该由插件提供才对；估计是Automattic不想让新用户老去找插件吧……从2.5剩余的bug数量依旧惊人，2.6又出，大概没这么快能填平。我还是希望那上传系统能简化下，现在要插入一个图片要过这么多道坎，简直是效率杀手；少点类似Word Count的垃圾功能（而且不支持中文），减少无意义的点击，才是WP今后的王道。
WordPress 2.5新后台的24小时使用日记
“我推荐WordPress”。店长的信仰，被WordPress 2.5狠狠唾弃了。
说实话店长已经非常接近给本篇文章加入Total Disaster标签的忍耐极限了——WP2.5我越用越搞不清楚开发团队以什么任务为重。WordPress团队专门漏过2.4版，协同Happycog全力开发后台，新版本却制造了更多不可理喻的设计问题，实在令人费解；同时许多来自2.3时代的问题却没有得到解决，难道将bug遗留给新版本是WordPress的新口号？我一直是WordPress的忠实用户，但2.5让我重新考虑自己的爱是否得到尊重，你不信？这里记录着店长自己24小时内的酸甜苦辣。
0:20am – 完成本地测试，没有发现插件异常，决定装修客栈
0:25am – 更新文件完毕
0:26am – 进入后台，被要求更新数据库，照做。
(完成) On the way to MediaTemple, Goodbye iPowerweb
更新II：如果你能看到本页面，恭喜，转移已经完成。
更新I：域名转向接纳，进入第二阶段。客栈两年的影片打包在此（使用了国内jsharer空间，顺便宣传）下载有两种办法，使用下载密码bitinndl（问题重重……），或者直接注册帐号来下载，压缩包的密码是bitinn；国外的同学们，直接到影片页面上下载更快吧……
空间已经到位，域名重定向开始。
至于我到底喜欢那个服务商多些——
-
Bluehost：成熟，傻瓜化，读取缓慢，部分虚拟服务器被封；
-
Powweb：便宜，自定义，读取较快，所有虚拟服务器被封；
-
iPower(iPowerweb)：廉价，高响应，渣服务，居然没被封；
-
MediaTemple：贵价，服务佳，不够稳定，虚拟服务器暂安。
所以的确没有特别好的选择，服务商都有自己的“隐藏限制”，不测试是不知道的，所以选个没被封的就好了。
由于客栈本身（WordPress系统）是本次转移的重点，从iPower的MySQL4.0到MediaTemple的4.1花了点时间处理latin1表内使用utf8字符导致的乱码，网上的教程很多，稍微总结下。
1. 使用WordPress专用插件WordPress Database Backup备份数据，尤其是在2.2之前就开始用WP的同学：WordPress数据库默认为latin1，WordPress的数据却是utf8，所以通过phpmyadmin输出的备份一般都会是latin1，自然乱码；相反Backup插件以数据编码为准，所以会输出utf8（否则先要自己去转数据库的编码，即便成功了，也可能导致你当前安装显示乱码）。2.2之后使用默认安装不会有类似问题。
2. 确保备份没有乱码后，要进行MediaTemple上对应的设置。使用后台系统新建数据库，则数据库的默认编码为latin1，校对会使用latin1_swedish_ci，这样导入utf8备份也会乱码。MySQL4.1服务器（Server），数据库（Database），数据表（table），数据链接（connection）都有独立的character set，所以即便phpmyadmin里显示服务器使用utf8编码和utf8_general_ci校对，数据库的编码也可能不同。
3. 要解决第2点带来的问题，在新数据库上用 ALTER DATABASE name CHARACTER SET utf8; 后再导入数据就可以避免乱码了（设置服务器默认校对为utf8_general_ci，也可以在上面的查询语句;号前加入 COLLATE utf8_general_ci 来强制）。
4. 我见到不少网站引用了桑林志的一篇老文章，要提醒下加入SET NAMES步骤在WordPress 2.2之后是多余了，开发团队已经解决了相应问题。
5. utf8是推荐编码（MT上这是默认，WordPress 2.2+的默认也是它），不要使用gb2312或gbk，尽管它们减省数据大小，但会对导致各种各样的字符问题。
大概就这样，还有什么更新会在这里添加，祝我好运orz。
tbc.
WordPress 2.3: Tag It or Not ? 标签海前的犹豫不决
时值中秋佳节之时，WordPress官方也终于发布了它们的最新礼物：WordPress 2.3正式版。其中新增的内置标签分类系统是本次更新的亮点。
然而对早已拥有数种标签插件的WordPress来说，这次升级却让老用户（包括店长）犹豫起来——鉴于WordPress 2.3对数据库结构和分类系统都做了较大的调整，类似Jerome’s Keywords，Simple Tagging和Ultimate Tag Warrior等等比较流行的插件都将被逐步淘汰……该选用默认工具呢？还是保留加强套餐？
经过昨天对客栈数据库的反复折磨（破坏性实验），店长最终决定将系统升级至WordPress 2.3，这里向各位提交我们的试用报告。无论你是新手还是熟客，希望本文会对你的WordPress生活带来帮助。
WordPress 2.1，易用性提升，Bug的数量也提升？
WordPress 2.1在两天前总算大体通过质检，赶上原定的发布日成功出厂了。
这次不大想翻译trac里的升级内容了，简单点说核心开发方向就是为了让WordPress更平易近人；而且2.1和2.0.x内核上的比较想必各位都有所听闻了，无需我多说什么。
仅从用户易用性的角度来说，WordPress 2.1为做到让普罗大众能轻易捡起，并在最短学习时间内掌握90%的界面操作，对wp-admin部分的布局修正可谓是慎之又慎。其中和2.0.x系列的最大区别在于对留言的单独处理。
对比两图的排版，各位发觉WordPress开发团队的苦心了么？留言(Comments)的重点照顾说明他们在从模块化逐渐转向人性化。在数据库分类方便的模块到了用户手里不一定方便：对于大部分Blogger来说，查看留言并回复才是每天最常做的事情。
[更新]好事多磨，Zooomr帐号回复正常，然而革命才刚刚开始。
Zooomr自从宣布更新到2.0之后就人祸不断，除2.0发布前夕的DDoS攻击算是树大招风以外，其余的各种问题都可算得上是设计者自身疏忽导致的错误。
首先是帐号融合的问题，现在说感觉像马后炮，但我认为这是可预见的系统错误：本来一个网站没有自身的帐号系统就容易出现丢失密码却难以取回的现象，而Zooomr偏偏还有这么2种额外支持的帐号（Meetro/Google Account），更是增加了帐号管理的难度。升级后我的帐号就出现无法正常登陆的状况，无论是通过OpenID还是Google Account再Merge，均出现帐号重建，当然我的pro帐号也是消失无踪；再者由于是通过OpenID登陆，在Zooomr又没法正常注销，连Clear Cache都失效，真把我郁闷了好一阵子，最后才推断是系统的Bug，决定耐心等待解药……昨天回去查看，总算登陆正常，我的pro帐号也回归祖国的怀抱。
↓继续↓