Rainux's Journal

上周六完成了最近的工作，狂睡一天＋猛玩一天之后，昨晚花了一整夜的时间来进行升级工作。包括修改 WP 本身的少量代码，寻找插件的新版本并修改，以及完成去年三月就搁下的 Theme 移植（从 1.2 的 style 移植到 1.5 的 Theme）。是的，去年三月……

意外的发现 MarkDown 这个超好用的写作插件，以前竟然一直无视了它的存在。 简单的说 MarkDown 可以让我们像写纯文本文件那样来写 HTML，再也不需要把 < > 写成 &lt; &gt; 了，直接书写 1. xxx 2. yyy 就可以产生 HTML 的有序列表，直接书写 * xxx * yyy 就可以产生 HTML 的无序列表等等。唯一不爽的是表示引用的效果需要用 Email 格式的 > 符号，并且至少每个段落前面要有一个 > 符号，这样就比直接使用 <blockquote> 麻烦多了，有空得研究一下如何修改它。

Update: 哈，原来要解决这个问题很简单，注释掉 markdown.php 中的这一行就可以了，目的是不去掉 WordPress 本身的段落自动转换过滤器。

//remove_filter('the_content', 'wpautop');

另外发现要使 Auto-hyperlink URLs 和 MarkDown 一起工作的话必须把前者的过滤器优先级设置得比 MarkDown 高，否则也会出些莫名其妙的问题。打开 autohyperlink-urls.php 把最末尾的三行改成这样就行了。add_filter() 函数的第三个参数表示过滤器优先级，由以前的 9 改成 5，因为 MarkDown 的过滤器优先级是 6。

add_filter('the_content', 'c2c_hyperlink_urls', 5);
remove_filter('comment_text', 'make_clickable');
add_filter('comment_text', 'c2c_hyperlink_urls', 5);

刚才看到在 kDolphin 的中英双引号的问题中提到偶曾经说过的 WordPress 1.5 强制转义某些英文标点符号的问题，索性就在这里说说清楚吧。

事实上这个不是浏览器的问题，是 wp-includes\functions-formatting.php 中的 wptexturize() 函数在搞鬼。在页面被显示时（只是被显示时，数据库的标点符号还是正确的），它会把英文的单双引号和键盘上 TAB 键上面那个斜点符号以及其他一些东西都强行转换成了 Unicode 里的 CJK 标点符号，也就是全角的中文标点符号。这个函数会作用于站点标题、blog 标题、blog 内容、回复内容等地方。

它把标点符号变丑也就算了，关键是这样一转换会造成文章本来的意义被破坏，特别是有程序代码的文章。其实这就是我一直没有升级 1.5 的主要原因之一，另一个原因是懒得修改 style。

虽然可以自己很容易的修改一下这个函数，让 WP 1.5 不这么做，但是我不知道 WP 1.5 默认强制这么做会不会是因为某些地方依赖这个做法，比如不这么做可能会在某个地方出大问题。

大家来讨论一下吧。

以下是我注释掉的 wptexturize() 函数中的行

// This is a hack, look at this more later. It works pretty well though.
//$cockney = array("'tain't","'twere","'twas","'tis","'twill","'til","'bout",
//  "'nuff","'round");
//$cockneyreplace = array("’tain’t","’twere","’twas",
//  "’tis","’twill","’til","’bout","’nuff","’round");
//$curl = str_replace($cockney, $cockneyreplace, $curl);

//$curl = preg_replace("/'s/", '’s', $curl);
//$curl = preg_replace("/'(\d\d(?:’|')?s)/", "’$1", $curl);
//$curl = preg_replace('/(\s|\A|")'/', '$1‘', $curl);
//$curl = preg_replace('/(\d+)"/', '$1″', $curl);
//$curl = preg_replace("/(\d+)'/", '$1′', $curl);
//$curl = preg_replace("/(\S)'([^'\s])/", "$1’$2", $curl);
//$curl = preg_replace('/(\s|\A)"(?!\s)/', '$1“$2', $curl);
//$curl = preg_replace('/"(\s|\S|\Z)/', '”$1', $curl);
//$curl = preg_replace("/'([\s.]|\Z)/", '’$1', $curl);
//$curl = preg_replace("/ \(tm\)/i", ' ™', $curl);
//$curl = str_replace("''", '”', $curl);

这个问题其实纯粹是 IE 的问题和 CSS 的技巧问题，不过因为我是在调整 WordPress 的 style 时遇到并解决的，所以就归类到 WordPress 里了。

以前就听说 IE 对 CSS 支持不太好，特别是有关盒式模型的。不过由于我几乎不做网页，所以也没留意过。最近因为给 blog 添加那个“访客来源”显示，才注意到这个。

问题描述：对于几个相邻的 div 元素，如果使用了一些比较复杂的 CSS 来排版定位，特别是这些 div 元素的 CSS 里都有 padding 属性时，在 IE 中有可能会造成 div 相邻的边界出现很莫名其妙的绘图错误，而 Firefox 里没有这个问题。（如果你有兴趣，可以把偶这个 blog 的首页源代码保存为 UTF-8 编码的 HTML 文件，然后用文本编辑器打开它，搜索“<!–修正 IE padding 问题–>”，把它前面那个 &nbsp; 去掉，然后用 IE 打开，拖动滚动条到页面底部，分别按一次 Page Up、Page Down，就可以看到我所谓的“绘图错误”了。）

可能上面这段话是我平生最烂的问题描述了，因为我没有正式的学过 HTML 和 CSS，只是看过一些比较权威的参考手册，所以也没有对这个问题进行深入研究。不过我可以确定跟 padding 有关，因为我取消了那几个 div 的 padding 后，就不会有这个绘图错误，就算是再加上 margin 也不会有问题。

我的解决办法也比较拙劣，至少我是这么认为的。因为当时我发现在相邻边界出现问题的两个 div 元素中，靠前的那个（当然是指在 HTML 代码里）里面全是块级元素（block-level elements），没有一个内联元素（inline elements）。我就尝试性的在前面的 div 里加了个空格 &nbsp;，结果问题就解决了，呵呵。

其实问题是在几天前解决的，当然，在当时我并没有块级元素和内联元素的概念，是刚刚搜索 CSS 相关的东西时看到的。刚才又试了一下，用 height 和 width 都为 0 的内联元素 img 去代替 &nbsp; 同样也可以让 IE 正常显示，不过这样似乎有滥用 HTML 元素之嫌。

前几天把 Blog 搬到了 Rainice 的 Linux 主机上，结果导致形如 http://rainux.sefans.com/blog/wp-trackback.php/67 的默认 TrackBack URI 无法正常工作。Rainice 猜测是 Apache 的 mod_rewrite 模块禁用造成，不过我在自己的 Windows 主机上禁用 mod_rewrite 后这个 URI 一样可以正常的工作。

Rainice 提议说可以把 URI 中最后一个 / 改成 ?。通过分析 WordPress 的源代码，打开 wp-trackback.php 和 wp-includes\template-functions-comment.php 修改后却仍然无法使用。因为 TrackBack 是以 POST 方法发送的，比较难调试，只好自己写了个简单的 PHP 页面来辅助调试。

$handle = fopen('post.txt', 'a+');
ob_start;
print_r($_POST);
print_r($_SERVER['REQUEST_URI']);
fwrite($handle, ob_get_clean());
fclose($handle);

目的很简单，就是把 POST 过来的数据和请求自身的 URI 保存到文件里以便观察。

几经周折，终于发现是因为 wp-includes/functions.php 里的 trackback() 函数在组织 http request 时没有正确处理带有问号的 URI 造成的。

$http_request  = 'POST ' . $trackback_url['path'] .
                 $trackback_url['query'] . " HTTP/1.0\r\n";

很显然经过这么一拼凑 TrackBack URI 中的问号就被处理掉了一个。

正为发现一个 WordPress 的 bug 而窃喜准备去 WordPress 论坛报告时，才发现 1.5 beta 版里这个问题已经被修正了。

可叹平常我都对软件的追新乐此不彼，还时常以“新功能”、“就算用不上新功能，Bug 修正也是很重要”之类的理由“引诱”朋友也尽力使用新版本的软件，没想到今天自己居然因为一时偷懒没升级 WordPress 而吃了大亏，白白浪费了几个小时来除错，唉！

要修改的地方有 wp-trackback.php 第 6 行附近

// 修改 / 为 ?，在 mod_rewrite 禁用的情况下正常使用
//$tb_id = explode('/', $_SERVER['REQUEST_URI']);
$tb_id = explode('?', $_SERVER['REQUEST_URI']);

wp-includes\template-functions-comment.php 第 266 行附近 trackback_url() 函数中

// 修改 / 为 ?，在 mod_rewrite 禁用的情况下正常使用
//$tb_url = get_settings('siteurl') . '/wp-trackback.php/' . $id;
$tb_url = get_settings('siteurl') . '/wp-trackback.php?' . $id;

wp-includes\functions.php 第 562 行附近 trackback() 函数中

// 此处修改保证带有问号的 URI 能正确处理
//$http_request  = 'POST ' . $trackback_url['path'] . 
                   $trackback_url['query'] . " HTTP/1.0\r\n";
$http_request  = 'POST ' . $trackback_url['path'] . 
                 ($trackback_url['query'] ? '?' . 
                 $trackback_url['query'] : '') . " HTTP/1.0\r\n";

OK, Good job! 不过我很郁闷 :(

基于安全性考虑，WordPress 的文章是不能直接运行写进去的 PHP 代码的，但是某些时候我们需要文章有提供一些动态内容的能力，这个限制就很让人不爽了。

幸运的是 WordPress 有强大的插件功能，更幸运的是已经有人写了插件让我们可以这么做。Mark Somerville 的 Run PHP 就是其中一个，并且工作得很好。

安装并激活 Run PHP 后，我们就可以在 WordPress 的文章里使用

<phpcode>
    echo 'Hello, This is from PHP!';
</phpcode>

这样的格式来插入 PHP 代码了，并且可以调用 WordPress 及其插件提供的函数。

大多数时候它工作得很好，但是因为这对伪标签跟 HTML 标签一样使用 <> 符号，所以在某些时候会出问题，例如

<a href="<phpcode>echo 'test';</phpcode>just a test">test</a>

这样就会造成很严重的问题。

为此，我把 runphp.php 里 26、27 两行的代码

while($phpstart = strpos($data, "<".$tag.">")) {
    $phpend = strpos($data, "</".$tag.">");

改成了

while($phpstart = strpos($data, "[".$tag."]")) {
    $phpend = strpos($data, "[/".$tag."]");

修改之后，就应该使用 [phpcode] [/phpcode] 来插入 PHP 代码了，这样刚才那个问题就解决了。

其实，刚才那个在链接目标里使用 PHP 代码的情况是很有用，我们可以用

[phpcode]bloginfo('url');[/phpcode]

来代替文章里出现的自己 Blog 的 URI，这样可以保证在 Blog 的 URI 改变了的情况下，文章内容无需任何修改里面的链接也一样正常。虽然使用相对路径也可以解决这个问题，但是在一些新闻阅读软件里阅读 Blog 时相对路径是无法正常工作的。

Updated on 2009/02/22: 对于最新版的 WordPress 2.7.1 来说，Exec-PHP 比 runPHP 更值得推荐，因为不知何故 runPHP 不会出现在 WordPress 的插件管理里。并且不管是最新的 Exec-PHP 还是 runPHP，使用 PHP 代码的语法都是最正常的 <?php ?>，不会有本文提到的这些问题。