理论上，网页留言并不是很复杂的情况，同时如果要求留言之后仍保留在同一页面，可以有以下两种方式：

1、自包含的页面处理，只要表格是这样的形式：<form method=”…” action=”page_itself”>

2、由别的页面处理，但在处理的末尾使用redirect的方法把页面又重指回到起始页面。Wordpress就用的是这种方式。

在第2种方式下，就需要有一些参数传递。我一开始总想不通这样简单的参数传递为何会引起错误的链接，于是用了小聪明，把404.php给改了一下，其实就是在发现错误链接的时候，试图通过其他信息把它又重定向回起始页面。但是，结果却发现这个方法在IE里又不适用，只有Firefox还行。这使得我只好不偷懒，重新阅读程序。

期间，还发现了另一个错误，那就是在编辑页面预览的地方，如果帖子的url包含中文，竟然也不能正确预览，而之前使用WP 2.0的时候决没有这样的错误。于是对比了一下，在wp 2.1里，调用iframe的地方，使用了一个新的function: clean_url，它会把一些不常见字符之类的给替换掉；而在wp 2.0里，用的是attribute_escape，但处理的只是常见符号。把clean_url改成attribute_escape也就能正常预览了(虽然我还是不明白有什么必要来调用clean_url或者attribute_escape)。

这倒也提醒了我，上面留言时可能出现的错误，于是看了一下wp_redirect，果然有部分内容和clean_url功能相同，把链接里的一些字符给处理了。 我就决定舍弃Wordpress提供的wp_redirect，自己用header(”Location: “.$url)来完成网页重定向，结果又是在IE里碰到了麻烦，一看url完全是乱码。而Firefox里则一切正常。问题其实又回到了一开始我试图用404.php来处理错误的地方。

于是就Google了一下，发现不同浏览器对url的encoding方式就是不同。一般的建议是不要依赖于浏览器来正确统一的解码。也就意味着在服务器端，我得先使用一下urlencode。 然后由于我自己想表现的厉害些，就想用array_map来做encoding，结果就是总有一些意外的情况，虽然总能处理，但却完全违背了我懒惰编程的习惯。所以最后就只是用urlencode来处理了几项会出错的地方。

一切都暂时解决了之后，我就想最当初Stone还问过我Slug是啥，我也没多加理会，还不让Stone用来着，硬是要链接里出现 %e5%92 这样的字符才高兴(当然有些浏览器还是挺好的，可以好好的看出是中文)。但最后也在奇怪，为什么Wordpress帖子(Post)的url是中文其实也没事，而页面(Page)却不行。再仔细查看了一下，原来是Wordpress把帖子的url都已经urlencode过了，而页面的url却没有。不明白Wordpress为什么不好事做到底…

I like this function. It is just like what the search engine, Ask.com, did to display the search results. Even the Wordpress.com started to use it. And I enabled this funtion last week.

But today, there is a serious problem fetching the javascript from spa.snap.com. There is apparently a timeout, about 20 seconds. The preview is not functional now. I hope it won’t die as the Gravatar and I still want to keep this function. I think they can solve the problem later. But I need a solution to download my page faster, at least without the 20s delay.

The solution seems simple, instead of putting the javascript in the header, moving the preview code to the near bottom, just before the end of body . This is just as where the Google analytics code is put.