revision 是你每保存一次 post 的时候，都把修改前的内容存成一个 revision，这样你就不用担心以前的版本找不到了。问题是，写 blog 又不是写代码，用得着这把牛刀么？就是写代码，也有不想保存的版本，基本上扔到 scm 里面就不会再看了呀。

禁用 revision 的方法，对目前的 WordPress 3.0 有效，在 wp-config.php 中添加：

define('WP_POST_REVISIONS', false);
define('AUTOSAVE_INTERVAL', 60000);

同时也禁止了自动保存，多手工保存吧，或者本地写好了再 post 。

auto-draft 是这样出现的，当你 new 一个 post 的时候，以前是第一次保存的时候生成 id，现在则是打开 new 页面的时候就生成了，体现在数据库中 wp_posts.post_status 为 auto-draft。这种没有内容先保存的方法一般是用来避免多人同时保存时的写入数据冲突，可一般的 blog 会频繁产生这种情况么？更糟糕的是，auto-draft 类型的post 无法在 Posts 管理中进行编辑，也就是说如果你打开了 new post 页面，输入了一些内容，然后没有保存或者发布就离开了这个页面，那么数据库中就多了一条 auto-draft “僵尸记录”，你再也找不到它了。

auto-draft 目前好像没有方法关闭，但可以从数据库中把他们更改为 draft，以后当草稿修改成新文章就是了：

mysql> SELECT DISTINCT post_status, count(1) FROM wp_posts GROUP BY post_status;
mysql> UPDATE wp_posts SET post_status='draft' WHERE post_status='auto-draft';

最后，贡献一个 php 脚本，自动把 revision 和 auto-draft 都修改成草稿 draft，并且找出数据库中不连续的 post id，把他们也都存成草稿，这样可以保持 url 中 id 的连续性，似乎更加美观和整洁。未经严格测试，请参考使用：

Related posts

• 更改 WordPress 自动生成摘要的方式 (19)
• 搞定WordPress的Permalinks (6)
• 如何为网站添加sitemap文件 (3)
• 升级WP旧模板，让它支持Widgets (4)
• 升级WordPress从1.5到2.0 (5)

• 打开 module
• 生成 IV
• 得到 key/密钥/密码
• 初始化（引擎？）
• 进行加密操作
• 关闭（引擎？）
• 重新初始化（引擎？）
• 进行解密操作
• 关闭（引擎？）
• 关闭 module

加密、解密放在了一个代码片段中，大概是想说，加、解密就那一句代码不同而已。

按照这个理解，为了使用方便，我把加、解密分解成了2个函数，内容都和例子差不多，不会有错。但一运行，不管用哪种加密算法，都会出现奇怪的解密后与原文不一致的错误。还不是完全不一致，后面大半段内容都是正确的，比如原文是包含 a-z 26个字母的字符串，运行结果如下：

$ ./mcrypt.php 
Encrypt:
M~<5¶¤Jw^TÝ×. ÃV¯
Decrypt:
Âò¹ÁIijklmnopqrstuvwxyz

好一通找原因，最后在支持算法列表页面中找到这么一句：The IV must be unique and must be the same when decrypting/encrypting.加、解密时所使用的 IV 必须相同。

昏，例子代码中 IV 是使用随机数生成的，分成2个函数之后，加、解密操作生成的 IV 肯定不一样，这就是解密失败的原因。mcrypt_create_iv() 函数文档页面的 user notes 中有位 Chris 还对 IV 纠正了一些错误观点。

综上，正确解密需要将 IV 与密文一同存储、传递。而我的需求比较简单，就没有必要这么作，反正 IV 也不需要保密，所以直接用 key 的 sha1 值的片断，比如前8位（与 git 版本号简写类似）作为 IV，对安全性影响不大，应该是可以接受的。

问题解决，收工，有和我一样吃过亏的同学么？

Related posts

• 真正的“AI”，是不是可以这样？ (3)
• 用php_screw加密PHP代码 (0)
• 更安全的原因所在 (1)
• 忙碌的5月 (10)
• 向太空移植生命 (4)

几个新手刚刚开始接触 Git，为了维护核心仓库的“纯洁”，避免太多无关信息被误提交进仓库（再次批评一些图形化工具默认的“Select All”），采用了核心仓库只读，邮件提交 patch，审核后再提交的工作流程。

期间有时会遇到合并冲突，正常的原因一般是未及时下载新版本产生了冲突，特殊一点的原因是手工修改 patch 内容导致的。有时候看注释写得不够准确，忍不住就改了，有时候是 Geany 保存时自动去除了 patch 原文中的行尾空格，有时候是文件回车格式、BOM 等变动了，总之合并 patch 的时候，如果生成 patch 的“原稿”找不到，一般就产生了冲突，比如：

$ git am 0001-BUG-Sybase.patch
Applying: CHG: 读取Sybase如果时间为空,设置默认时间的修改
error: patch failed: source.php:38
error: source.php: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

刚开始一看有些懵，因为没有任何冲突在哪里的提示，后来找到一种方法，am 操作出问题后先手工 apply：

$ git apply --reject 0001-BUG-Sybase.patch
Checking patch source.php...
error: while searching for:
        // 注释
        // 以下为几行代码片断
error: patch failed: source.php:38
Applying patch source.php with 1 rejects...
Rejected hunk #1.

这样，就把没有冲突的文件先合并了，剩下有冲突的作了标记。先看输出，error: while searching for: 说明是这段代码有冲突，error: patch failed: source.php:38 指明了产生冲突的代码片断的开始行号，相应的，patch 中应该有这么一段：

diff --git a/source.php b/source.php
index 8770441..4e77b8a 100644
--- a/source.php
+++ b/source.php
@@ -38,27 +38,23 @@ class Site extends Module
        // 注释
        // 以下为几行代码片断

同时，还会产生一个 source.php.rej 文件，里面也是上面这段因为冲突无法合并的代码片断。

现在，在这段代码中查找冲突原因，并对文件进行修改，source.php.rej 参考完了可以删掉。改好之后，用 git add 把 source.php 添加到缓冲区，同时也要把其他没有冲突合并成功了的文件也加进来，因为在作 apply 操作的时候他们也发生了变化：

$ git add source.php
$ git add 其他 apply 进来的文件们

最后：

$ git am --resolved
Applying: CHG: 读取Sybase如果时间为空,设置默认时间的修改

大功告成。

中间如果处理乱了，用 git reset 恢复即可，所以合并 patch 在一个“干净”的分支上处理更好。

Related posts

• [Git]初学者注意事项 (0)
• 利用SVN更新网站 (7)
• [ubuntu]安装vmware时找不到c header files的小问题 (4)
• [Git]真正回滚已上传的更新 (0)
• [Git]提交后自动发email (2)

和源码无关的东西，尽量不要进仓库

不得不说一些图形化软件，在提交内容的时候大多提供一个“全选”或者“Select All”功能，这是最不好的了，一些懒惰的同志看都不看就连瓢带碗都提交了。

• 测试时上传的文件，测试时的临时文件，统统不要
• 对应上一条，强烈建议把所有文件的上传保存目录另行设置，放到源代码目录以外
• 编辑器产生的备份文件、临时文件，编译时的中间文件，统统不要
• 对应上一条，有个例外就是为了实现通过 Git 更新系统，.NET 的 bin 文件要进仓库，导致那个仓库现在都 100+m 了
• 图片等资源文件，进仓库也可以，但应当使用有意义的文件名，便于后期管理
• 对应上一条，现在设计网站界面喜欢先作图然后切割，产生一大堆 001_r5_c1.jpg 这样的文件，讨厌之极
• 使用的外部类库，比如 php 类、js 类等，统统扔到源码目录以外，如果实在没办法要放在目录树中，也可以留出空目录，打包发行的时候再包含进来，依然不进代码仓库
• 不要中文文件名，主要是跨平台使用有问题，文件名完全能够只用字母数字减号下划线

尽量采用相对小、相对独立的提交

Git 是作什么用的？Git 不是代码上传工具，也不是网站更新工具，而是软件开发过程的记录工具，为了更加准确的定位每个问题、每个功能修改，就需要在每完成一部分可以称得上是“一项”的工作时，就 commit 一次。哪怕只是修改了一两行，只要产生了必要的功能改变，就有价值记录。

当采用代码审核机制或者需要用邮件提交补丁时，较小的提交能够更有效、更容易、更准确的被检查和审核，这个在 linux kernel 开发文档中也有提到。

当然不能矫枉过正，必须有可记录的改变才有提交的价值。对应的，Git 日志大多数情况下主要显示第一行，控制每次提交都能用一句话简单概括，也是有必要的。

注释格式

格式属于个人习惯和团队规范范围，有必要采用相对统一的风格。

Git 本身不允许空注释，同时建议注释的第一行写简要说明，下面留一行空行，再写详细说明。

我的个人习惯，喜欢在每条注释前面用大约三个字母来表示本次修改的性质：

• Add something
• Bug [fix|found]: describe the bug or fix.
• Chg something
• Del something
• Enh some treatment
• New something
• Tmp for some cause

为了保持语法通顺，也可以采用前三个字母后面加冒号，后面有啥写啥的方法。

最后，我觉得，能够遵守行业规范和团队约定，主动养成良好习惯，应当是鉴别人才的一项重要因素。

Related posts

• Git 合并 patch 时的冲突处理一例 (0)
• 针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS） (3)
• 用ssh打通反向隧道，内网也可对外提供服务 (2)
• 利用SVN更新网站 (7)
• 你最希望在哪里看到TIPS？ (5)

难道google baidu就不让用proxy连接么？显然不可能，所以打开curl的信息输出（curl_setopt($this->mSh, CURLOPT_VERBOSE, 1);）看看，得到以下结果：

*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 8118 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:80
> CONNECT www.baidu.com:80 HTTP/1.0
Host: www.baidu.com:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

< HTTP/1.0 403 Connection not allowable
< X-Hint: If you read this message interactively, then you know why this happens ,-)
< 
* The requested URL returned error: 403
* Received HTTP code 403 from proxy after CONNECT
* Closing connection #0
... Failed.

可以看到proxy服务器工作正常，的确是baidu返回了403错误，但原因肯定还在我这边。终于，从网上（1of2, 2of2）得到了点启发──我使用的是proxytunnel而非proxy。

在代码中，有这么一句：

	curl_setopt($this->mSh, CURLOPT_HTTPPROXYTUNNEL, true);
	curl_setopt($this->mSh, CURLOPT_PROXY, $phost);

php文档中没有详细说明，不过man curl中有详细解释，两者都是代理，proxytunnel（-p参数）允许其他协议通过http代理传输，而proxy（-x参数）则只能走http协议。所以我猜测，google baidu的服务器和curl的proxytunnel不和，所以返回403。

禁用掉上面2行代码的第一句后，curl访问恢复正常。

比较奇怪的是，几种操作系统下还不一样，一台MAC OSX就要显式的禁用proxytunnel才可以，curl版本：

$ curl --version
curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

而另外一台ubuntu则完全不受影响，怎么都能用，curl版本：

$ curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

MT主机上的centos也没事，curl版本：

$ curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

看来不完全是curl版本问题，MAC OSX的确与众不同啊。

还有一个原因也会导致curl返回403错误，如果设置了：

	curl_setopt($ch, CURLOPT_NOBODY, true);

则需要紧跟着设置：

	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

不然会因为http服务器不允许 HEAD 命令而返回403错误。参考：Trouble with a cURL request in PHP。MAC OSX上curl之所以特殊，也不排除是这种原因吧。

Related posts

• 由一个错误学到的一些php安全配置问题 (4)
• adodb5连接sybase的一个错误 (0)
• 针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS） (3)
• 配置安全的共享web服务器（抛砖引玉） (4)
• 选择Eclipse PHP Development Tools(PDT)作为PHP开发工具 (8)