意外的发现 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);

事实上这个不是浏览器的问题，是 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 支持不太好，特别是有关盒式模型的。不过由于我几乎不做网页，所以也没留意过。最近因为给 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 元素之嫌。

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 有强大的插件功能，更幸运的是已经有人写了插件让我们可以这么做。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 ?>，不会有本文提到的这些问题。

在 WordPress 的 Support 上搜索 "backslash"，找到一些帖子。有人说这个问题在 1.3 里已经修正了，也有人提供了 1.2 下解决的办法，具体做法如下。

打开 WordPress 安装目录下的 wp-includesfunctions-formatting.php 文件，搜索 "formattoedit" 会在 266 行附近找到这个函数，它看起来是这样的

function format_to_edit($content) {
    $content = stripslashes($content);
    $content = apply_filters('format_to_edit', $content);
    $content = htmlspecialchars($content);
    return $content;
}

改成这样就可以避免在编辑 Blog 时反斜杠被“吃掉”。

function format_to_edit($content) {
    // 注释掉这行代码可以避免编辑时的反斜杠丢失问题;
    //$content = stripslashes($content);
    $content = apply_filters('format_to_edit', $content);
    $content = htmlspecialchars($content);
    return $content;
}

继续打开 WordPress 安装目录下的 wp-includesfunctions.php 文件，搜索 "start_wp" 将会在 1056 行附近找到这个函数，在它的结尾处有这样一些代码

if (preg_match('/<!--nextpage-->/', $post->post_content)) {
    if ($page > 1)
        $more = 1;
    $multipage = 1;
    $content = stripslashes($post->post_content);
    $content = str_replace("n<!--nextpage-->n", '<!--nextpage-->', $content);
    $content = str_replace("n<!--nextpage-->", '<!--nextpage-->', $content);
    $content = str_replace("<!--nextpage-->n", '<!--nextpage-->', $content);
    $pages = explode('<!--nextpage-->', $content);
    $numpages = count($pages);
} else {
    $pages[0] = stripslashes($post->post_content);
    $multipage = 0;
}

把它们改成这样就可以避免在 Blog 显示时反斜杠被“吃掉”。

if (preg_match('/<!--nextpage-->/', $post->post_content)) {
    if ($page > 1)
        $more = 1;
    $multipage = 1;
    // 修改这两行代码可以避免显示时的反斜杠丢失问题;
    //$content = stripslashes($post->post_content);
    $content = $post->post_content;
    $content = str_replace("n<!--nextpage-->n", '<!--nextpage-->', $content);
    $content = str_replace("n<!--nextpage-->", '<!--nextpage-->', $content);
    $content = str_replace("<!--nextpage-->n", '<!--nextpage-->', $content);
    $pages = explode('<!--nextpage-->', $content);
    $numpages = count($pages);
} else {
    //$pages[0] = stripslashes($post->post_content);
    $pages[0] = $post->post_content;
    $multipage = 0;
}

OK, Enemy down! ;)

WordPress Support 上的原文。

看了一下 Syntax Highlighter 的源代码，发现对于 PHP 代码，它调用 PHP 的 highlight_string() 函数来进行语法高亮的格式化，因此没有其他需求。而对于其他程序设计语言，则需要调用 Web 主机上安装的 GNU Enscript 来进行语法高亮格式化。

好在我的 Blog 是放在自己管理的机器上的，安装软件很容易。在 Free Software Foundation 的 GNU Enscript 页面上下载了 Win32 Binaries Zip 包，解压到准备安装的目录，并且为了能方便 Syntax Highlighter 和我们自己使用 Enscript，还要把这个目录下的 bin 子目录添加到系统环境变量 PATH 里。OK，用如下格式贴一段 Delphi 代码测试一下。

program Hello;
var
  I: Integer;
begin
  for I := 0 to 9 do
    Writeln('Hello');
end.

Good，代码正常的语法高亮显示了。

但是，代码前面多了个大大的 "(stdin)"。猜测应该是 Enscript 产生了不必要的输出。试着手工运行 Enscript 产生代码，果然这个由 <H1> 修饰的输入文件名 (stdin 表示控制台程序的标准输入) 是由 Enscript 输出的。看了一下 Enscript 的命令行参数，发现其中有几个跟 header 有关的参数，遂逐一尝试，但都没有任何效果，讨厌的文件名标题仍然还在。同时发现即使是用 Syntax Highlighter 调用 Enscript 所用的参数运行 Enscript，产生的 HTML 代码也是一个完整的 HTML 页面的代码，因此 Syntax Highlighter 肯定会对 Enscript 输出的 HTML 进行处理。查看其源代码，果然发现在 hilight_enscript() 函数的最后有这两行代码

$code = eregi_replace("^.*<PRE>\n",  '', $code);
$code = eregi_replace("\n</PRE>.*$", '', $code);

这两行代码使用正则表达式强大的模糊搜索替换能力将 Enscript 输出的 HTML 中 <PRE> 标签之前和 </PRE> 标签之后的内容都去掉。从正则表达式语法上，我看不出任何有问题的地方。查 PHP 手册、Google 搜索，换用 preg_replace() 函数，结果引起更多的问题，又去查 Perl 手册中正则表达式的部分…… 搞了好久才发现是因为那个我并不陌生的 Linux 和 Windows 文本文件换行符不一样的问题。\n 明显就是 Linux 的换行符，而运行于 Win32 平台的 Enscript 产生的 HTML 换行符自然是 \r\n，从而导致第一行代码根本没有产生作用。OK，为了这个插件在 Linux 和 Windows 主机上都能正常使用，再加一句，改成这样

$code = eregi_replace("^.*<PRE>\n",  '', $code);
$code = eregi_replace("^.*<PRE>\r\n",  '', $code);
$code = eregi_replace("</PRE>.*$", '', $code);

最后一行的 \n 被我去掉了是因为这样产生的 HTML 源代码更美观并且不会影响显示效果。

另外查看 Syntax Highlighter 源代码还附带发现一出问题，在这段代码中

// FIXME: We are hardcoding the path to the temporary file name
// here. It needs to be changed to be system independent.
$file = tempnam('/tmp', '_syntax');
$handle = fopen($file, 'w');
fwrite($handle, $code);
fclose($handle);

$argv .= ' '.escapeshellcmd($file).' 2>&1 ';

作者说他对临时文件路径进行了硬编码，事实上这个硬编码不会出问题，因为 tempnam() 函数的特性是如果目录不存在则自动在系统的临时目录中建立文件。反倒是最后一行中的 escapeshellcmd() 函数会把 Windows 目录中的反斜杠 \ 替换成空格，导致 Enscript 无法正确得到临时文件路径。简单的把这个函数去掉，让 $file 变量直接参与字符串连接就行了。这个问题只在 PHP 版本低于 4.3 时出现，因为在新版的 PHP 中 Syntax Highlighter 会使用管道而不是临时文件来给 Enscript 提供输入。

OK, mission complete!