在寻求别人帮助前，内部服务器错误通常是由于插件或者主题函数的冲突造成的，因此你可以从手动重置你的插件和主题开始检查，这部分内容我们在WordPress 与白屏之死一文中已经做了介绍。 如果问题还没解决，有可能是 .htaccess 规则是造成的。 要检查这项，你可以通过FTP or SFTP登录到你的服务器，将 .htaccess 文件重命名。 如果你没有找到 .htaccess 文件，请确认你设置了 FTP or SFTP 客户端允许查看隐藏文件。

如果你通过重置插件及主题，或者修改.htaccess文件名还无法解决问题，那么该寻求他人帮助了。如果你能够提供更加详细的信息，将会有助于别人帮你解决问题。 通常可以在错误日志中找到内部服务器错误的详细信息。 如果你可以获取服务器的错误日志，重现你的遇到的错误，记下日期和时间，并立即检查你的服务器错误日志检查在此时间内生成的错误。 如果你无法获取服务器的错误日志，可以向你的主机服务商寻求帮助。

一旦你有了相关的详细信息，可以向主机提供商或者WordPress支持论坛寻求帮助务必要描述错误发生之前你所进行的一些操作，错误发生后尝试的解决办法，以及你的服务器错误日志里的具体信息。

原文：WordPress and the Internal Server Error

警告：Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42

记住故障处理的第一条规则：不要惊慌！ 首先，你需要理解错误信息。 第一反应，看起来可能是 wp-login.php 文件的 42 行是问题的根源，但这只是通常的误解。实际上，wp-config.php 的第 34 行才是问题所在，wp-login.php 的42行只是受害人。

现在你知道该看哪儿，该找什么了吧？ 不管你信不信，问题通常是由于那一行的空格引起的（或者一个空格、或者一个空行）。

现在，你知道了要找什么以及去哪里找，通过FTP或SFTP登陆你的服务器，并使用文本编辑器编辑这个文件。 此外，如果你不想被文件编辑弄迷糊，也可以直接用原始文件去替代这个文件，也可以解决问题。

如果你没有发现文件的任何错误，用原始文件替换也没有解决问题呢？ 那就很有可能是某个插件或者主题函数，读取这个文件时造成的问题了。 那就尝试关闭所有的插件。如果问题解决了，重新逐个启用插件，直到找出问题所在。如果还没有解决问题，尝试将主题切换到Default主题 (WordPress 1.5 – 2.9.2)或者Twenty Ten 主题 (WordPress 3.0或更高），来确认是否是主题造成的。 如果你无法登录管理面板，你可以按照WordPress与白屏之死一文中的办法手动关闭WordPress插件和主题。

如果还无法这个解决问题，WordPress支持论坛的热心网友可以帮你解答。一定要记住告诉他们你已经尝试过的步骤。

【补充】：如果你遇到的刚好是 wp-config.php 文件错误，并且你使用的WordPress并非WordPress官方英文原版或者WPChina.org发布的非官方中文版，那么很有可能是 wp-config.php 的错误编码导致的这个错误。包括cn.wordpress.org在内的一些组织发布WordPress中文版本，默认将wp-config.php文件设置为utf 8 no bom编码格式；但是php语言并不擅长处理utf8编码格式。解决办法，使用文本编辑器重新将此文件编码格式设置为ansi或gb2312；或者简单些，从WPChina.org下载一个非官方中文版，用其中的wp-config.php文件去替代。

原文：WordPress and the Headers Already Sent Warning

你的服务器可能会有4G的内存（实际上我们的WordPress专业主机都至少有8G的内存），但这些内存并不能都归你的使用。现在，正常安装一个WordPress程序，32M内存就很不错了。但是，有个别有问题的插件，或者个别的时候（比如通过控制面板导入导出文章）会在瞬间占用大量的内存，这时候程序就会变成了白屏，或者出现类似这样的的提示：“Fatal error: Allowed memory size of 33554432 bytes exhausted.”

如果你看到的是白屏，WordPress与白屏之死这篇文章或许会对你有用。

如果你看到的是内存致命错误的信息，在寻求你的主机服务商帮助前，你可以试试以下三个办法。如果第一个办法不行，就继续试第二个。记住，绝大多数主机商都密切监视内存的使用情况，并禁止你频繁地使用内存。

1. 如果你使用的 WordPress 2.9.2 或者更低的版本，可以在 wp-config.php 文件里添加代码 define('WP_MEMORY_LIMIT', '256M'); 。如果你使用的是 WordPress 3.0 或更高的版本，它会自动尝试这么做，你不需要再进行添加代码。

2. 如果你可以编辑系统的 php.ini 文件，可以尝试提高内存限制。比如，memory_limit = 256M

3. 如果你无法编辑系统的 php.ini 文件，可以将代码 php_value memory_limit 256M 添加到你的 .htaccess 文件中。

如果以上办法都不可行，你可以联系你的主机商要求临时增加你的账户的 PHP 内存限制。记住，绝大多数正常的主机商给每个账户的内存限制是32M，同时绝大多数正常的主机商也都允许用户临时增加内存分配。如果你的主机商不同意这么做，那么你应该考虑换一个更好的主机商了。

如果程序有错误，也会导致同样的错误，比如刚刚发布的WordPress 3.1 beta 1测试版（WP3.1 演示），测试的时候就存在这个bug。当然，这个bug在WordPress 3.1正式发行的时候一定会解决的。

如果你还需要更进一步的帮助，也欢迎你到WordPress官方论坛去发帖求助。

原文：WordPress and the Fatal Memory Error

想象一下你正在修改博客上的一个设置，或安装或升级一个插件，或升级最新版本的WordPress，或只是打开你的博客开始新的一天，但是你看到的，只是一个空白屏幕。

更不幸的是，当很多用户开始升级到WordPress 3的时候，插件的不兼容造成了更多用户的白屏。现在，绝大多数的白屏问题都是由于插件或者主题造成的（主题的函数有时候会导致WordPress函数出现接口问题）。

WordPress 的调试模式有些时候可以帮你找出罪魁祸首，但这并不是灵丹妙药，有时候你什么也查不出来。那该怎么办呢？

如果你可以登录WordPress的控制台（也就是管理面板），你不妨在后台禁用掉所有的插件。如果你无法登录到WordPress的控制台，我可以告诉你一个釜底抽薪的办法：

通过ftp或者其他方式（比如我们WordPress主机的cPanel带有的文件管理器）找到 wordpress 目录下的 wp-content/plugins 目录，将此目录名修改为其他任意名字，比如 plugins.hold ，然后新建一个空白的文件夹叫做 plugins。

这时候重新检查你的博客，如果已经不是空白页面了，将plugins.hold目录内插件复制到plugins目录内，登录主机管理后台，重新一个一个启用这些插件，直到找到那个导致这一问题的元凶。

假如到了这一步无法查出问题所在，那就要检查你所使用的WordPress主题了。如果你可以登录到WordPress的控制台，那么尝试一下将主题切换到Default主题（针对WordPress 1.5 — WordPress 2.9.2 用户）或者Twenty Ten主题（针对WordPress 3.0 及更高版本用户）。如果你无法登录管理面板，就需要采用和上面类似的措施了：

通过ftp或者其他方式（比如我们cPanel主机提供的文件管理器）找到 wordpress 目录下的 wp-content/themes 目录，将你正在使用的主题目录重新命名，比如在后面加上.hold或者任意其他字符，这样就可以强制将主题切换到 Default 主题（WordPress 1.5 — 2.9.2）或者Twenty Ten 主题（WordPress 3.0+）。

如果是由于主题问题导致的WordPress白屏错误，这个办法就可以解决了。

插件和主题是导致WordPress问题的主要原因，但仍然有一些其他的问题可能会导致WordPress白屏。如果你有类似的解决问题的经验，欢迎你向我们投稿，和大家一起分享你的解决白屏问题的办法。

使用 Window Live Writer 发布博客到 WordPress ，最经常遇到 xmlrpc 错误是这样的：

Invalid Server Response

The response to the metaWeblog.newMediaObject method received from the weblog server was invalid:

Invalid response document returned from XmlRpc server

倘若你使用的是中文版的 Window Live Writer ，则是这样的：

服务器响应无效

从日志服务器接收的对 metaWeblog.newMediaObject method 方法的响应无效：

Invalid response document returned from XmlRpc server

即使在 WordPress 官方论坛上，我们也遇到很多 WordPress 遭遇同样的问题；而对于这一问题，并没有确定的原因和解决方案。我们这里将我们所了解的办法，给大家介绍一下，希望能对你有所帮助。

常见的四种情况

1. 这可能是由于 PHP 版本所引起的问题。解决办法：打开 xmlrpc.php 文件(在wordpress的主目录下)，添加如下代码到文件的顶部，<?php 之后：
   $HTTP_RAW_POST_DATA = file_get_contents(“php://input”);
2. 也可能是由于 .htaccess 规则错误所引起的。解决办法：将如下代码复制到 .htaccess 文件：
   <Files xmlrpc.php>
       SecFilterInheritance Off
   </Files>
3. 还有可能是由于 WLW 与某个已经安装启用的 WordPress 插件冲突。解决方案：禁用所有的 WordPress 插件，然后逐一启用，可找出具体的插件。
   WordPress 论坛有位网友曾经遇到过 Window Live Writer 与 WordPress Super Cache 插件冲突的情况，下载新的版本即可解决；还有一个网友是因为 Window Live Writer 与插件 NextGEN 冲突，禁用此插件即可。
   因此，如果你遇到 xmlrpc 错误，可以考虑一下是不是最近增加或者修改过某个WordPress插件。
4. xmlrpc.php 文件中增加了一些代码，调用到一些函数无法执行。解决方案：这个稍微困难一些，你可以使用 Fiddler 来监测 WLW 和你的主机之间的流量，查看都调用了哪些函数，然后找出原因。
   有个网友在使用 Live Writer 上传图片过程中，由于使用的ftp客户端软件将上传的文件名强制修改为小写，也遇到了同样的问题，最后通过这个办法找到了原因:(。

以上四个是解决 Live Writer 的"Invalid server response"错误的常用的办法。

路径错误也会造成同样的问题

昨天我们一个网友网行志，从其他主机迁移到WPChina主机之后，也遇到了同样的问题。不过他的问题并不是由于 xmlrpc 错误造成的，而是主机迁移之后，图片上传文件的路径不一样造成的；因此只要所撰写的博客里有图片，就会遇到 Invalid Server Response 。

在 WordPress 的后台，有个“选项”->“杂项”，其中有一项是用来设置 WordPress 上传目录，你以后通过 WordPress 直接上传的文件，包括使用 Live Writer 写博客的时候，所上传的图片等附件也直接上传到以上目录中。

默认情况下，WordPress 的上传目录是 wordpress/wp-content/uploads/ 文件夹。但是，WordPress 所记住的并不是相对目录，而是根据服务器不同而生成的服务器上的绝对目录。

比如说，当你的网站在 A 服务器上安装的时候，这个目录有可能是：

/home/username/public_html/wordpress/wp-content/uploads/

而到了 B 服务器上之后，即便是 username 完全一致，也有可能变成了：

/home2/username/public_html/wordpress/wp-content/uploads/

只是一个数字之差，但目录错误，WordPress 就找不到对应的目录，无法上传图片和其他文件，也会引发同样的 xmlrpc 错误。

即使在不更换服务器的情况下，如果你修改了 wordpress 的安装目录，也会引发同样的问题，在这里我们提醒 WordPress 用户务必注意这一点。

针对这一情况，你只需要在 WordPress 的“后台”->“选项”->“杂项”中，输入正确的上传目录即可。假如你使用的 WordPress 默认的目录，那么直接删除这一项的内容，重新保留空白即可。

如果你还没有升级到 WordPress 2.7，那么我建议你暂时缓缓尽快升级。这个此前版本发现了重大漏洞，可能会导致遭受 DDoS 攻击。

如何查看自己是否被黑？

通过 FTP 或者 CPanel 查看目录 /wp-content/themes/ ，查看是否存在名字为 remv.php 的文件。如果存在，那么你已不幸中彩。

什么是 remv.php ?

remv.php 是一个叫做 PHPremoteView 的应用，它允许任何人在你的主机商运行任何 php 命令。这样的结果当然很严重（丢失文件、密码，修改你的 AdSense 代码，修改推介程序链接等）。

这种漏洞通常会被用作 DDoS 攻击。如果注意到你的主机负载很高，可能就是这个漏洞所致。

如何修复？

1. 首先删除 remv.php 文件；
2. 查看 WordPress 文件夹内是否有其他文件被修改，尤其是主题的页眉、页脚以及带有推介链接的页面；
3. 通过 XML 方式导出你的 WordPress 文章，并重新安装 WordPress 2.7 ，再导入你的文章；
4. 如果你在服务器上运行多个站点，检查全部文件。
5. 修改你的全部密码，用户、root帐户，WordPress，MySQL数据库 等全部的密码。
6. 升级你的插件到最新版（有些可能在 2.7 下还不能用）。

原文：Hack Alert (remv.php) – Upgrade to WordPress 2.7

中文：WordPress 2.7 出现重大漏洞(remv.php)

这个网友在升级到 WordPress 2.7 beta2 之后，出现了无法登陆后台的情况，并提示如下错误：

Fatal error: Call to a member function request() on a non-object in /public_html/wp-includes/http.php on line 258

在 WordPress 官方论坛也有网友反应同样的问题。我们来看一下介绍：

It was a bug in the HTTP API code, Unfortunately it seems that the nightly version got built after the bug was introduced, but before the fix was applied.

Unfortunately it may render your blog inaccessable as well if you logout, and Cron needs to fire when you log in..

翻译过来就是：

这是一个 HTTP API 接口代码的bug。非常不幸的是，WordPress 今夜编译版是在这个bug出现之后、修复之前发布的。因此当你退出登录，重新登录的时候，就会出现这个情况。

根据官方描述，这个问题可能是重要出现在昨天更新 WordPress 的博客上。

解决办法：

只要下载最新版本的 http.php 文件来替代这个文件即可。下载地址：

http://trac.wordpress.org/browser/trunk/wp-includes/http.php?format=txt

不过，如同前面我们所提到的“图片对齐”功能一样，如果你希望在博客中正常显示图片说明的话，那么还需要你稍微修改一些代码。摩摩诘网友在关于Wordpress2.6的图片说明(image Captioin)对此进行了简单介绍，需要使用此功能的网友，不妨参考一下。

=====题外话=====

如果你在使用 WordPress 2.6 过程中，有任何心得技巧的话，不妨也写下来，然后投稿到本站。在分享技巧的过程中，还能给你带去流量，快快参与投稿吧！

很多网友可能都注意到了，从 WordPress 2.5 到 WordPress 2.6，WordPress 自带的编辑器又有了些许改进。其中主要的一个变化，就是可以给图片增加 alt 域和 caption 域。其中 alt 域中可以填写图片的简单介绍，告诉搜索引擎该图片的信息；caption 则是告诉读者关于图片的描述。

除此之外，WordPress 还允许你插入图片的时候，设置图片的对齐方式。对齐方式包括“居左”，“居中”，“居右”等几种。当你选择了相应的对齐方式，插入图片到文章的时候，图片就会按照你所指定的设置，出现在文章中的相应位置。

在 WordPress 后台的编辑文章区域，看起来一切正常；但是一旦发布，就会发现在博客中，图片并没有完全按照原来所制定的方案进行显示。道理很简单，WordPress 系统在你编辑文章的时候，给这些图片添加了 alignleft, alignright, aligncentered 等 class 参数，分别实现居左，居右，居中。WordPress 对编辑区域的显示设置了相应的参数；但是大部分主题的样式表里，可能并没有此 class 的显示设置；或者有，但并不完全一样。

因此，如果你希望能在你的博客中显示的图片和编辑区域显示一致的话，需要你在所使用的主题的样式表文件中添加如下代码。注意，一般是指在 /wp-content/thems/xxx/style.css 文件，xxx 代表你的主题所在目录。

img.alignleft, div.alignleft {
float:left;
margin:0 0.5em 0.5em 0;
}
img.alignright, div.alignright {
float:right;
margin:0 0 0.5em 0.5em;
}
img.aligncentered, div.aligncentered {
text-align:center;
margin:0 auto;
}

这样，图片就能够在你的 WordPress 博客中正常显示了。

在 WordPress 2.5 的时候，我们曾经专门介绍过这个问题。但是，在 WordPress 2.6 的时候，依然有网友存在类似的问题。不过对 WordPress 2.6 的时候，情况简单了很多，发生错误的文件主要集中在 wp-config.php 文件上。下面是网友 assad 留下的错误信息：

Warning: Cannot modify header information - headers already sent by (output started at /home/xxx/public_html/wp-config.php:1) in /home/xxx/public_html/wp-includes/pluggable.php on line 770

错误的由来：UTF 8 编码的困局

从上面的错误信息来看，是 wp-config.php 文件的第一行出现了问题。实际上是第一行被网友所使用的文本编辑器插入了一个看不见的字符，导致了这个错误。这个字符就是 UTF8 的标志。

绝大多数网友并不了解文件的编码问题，更不了解 UTF 8 编码；当然平时用不到，也确实没有了解的必要。这里我简单地给大家介绍一下 UTF8 编码。我们都知道，计算机使用编码系统来表示不同的字符集。比如最为基本的 ASCII 编码，共包括127个常用字符，可用于处理英语以及其他西欧语言。我们国家则采用 gb2312, gbk, 以及后来 gb18030 等编码系统来处理汉字。其他国家也都分别制定了相应的编码系统，来表示他们自己的文字。所有的这些编码系统，统称为 ANSI 编码。也就是说，在简体中文系统下，ANSI 编码代表简体中文 gb2312 编码；在日本操作系统下，ANSI 编码则代表其常用的编码。

这样，各个国家使用不同的文字，也就有不同的编码系统，不便交流弊病就诞生了。假如你在国内使用 gb2312 编码的系统，发了一封情意绵绵的 email 发给了远在美国留学的女友，如果她所使用的电脑没有 gb2312 编码系统的话，她所看到的将只是一篇乱码。

因此，为了解决全世界各种语言的编码问题，人们提出了 UNICODE 编码，支持全世界 650 多种语言。这样，全世界的计算机上都将安装上这一套编码系统，可以方便地支持不同语言进行书面交流。UTF 8 编码是 UNICODE 编码的一个分支；除了 UTF8 之外，UNICODE 还有 UTF 16, UTF 32 等各种不同的编码方式。

UTF 8 编码比较简单，因为它是用单字节作为编码单元；但是对于 UTF 16 和 UTF 32 而言，则分别使用双字节和四字节作为编码单元，这就涉及到一个编码顺序的问题。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。那么对于 UTF 16 编码系统而言，4E59 究竟是“奎”还是“乙”？这就需要 BOM （Byte Order Mark）来标记字节顺序。

对于 UTF 8 而言，它只有一个字节，显然不必要使用 BOM 来标记字节顺序。但是 BOM 可以用来表明，这是一个 UTF 8 编码的文件。Windows 系统的记事本就喜欢在 UTF 8 文件里面添加一个 BOM 标记。但是，对于包括记事本在内的绝大多数编辑器而言，不管你是 UTF8 with BOM 还是 UTF8 no BOM 编码，都可以正常打开。

看起来晴空万里，但远处却飘来一朵乌云。如果所有的事情都像上面这样一帆风顺的话，那么也就没有必要絮絮叨叨说这么多了。问题的关键在于，WordPress 所使用的动态语言，PHP，在设计的时候没有考虑 UTF8 编码的问题。因此如果是 UTF 8 no BOM 的文件，它可以正常识别；但是如果遇到一个 UTF 8 with BOM 的文件，也就无法识别在文件开头的 BOM 标志。

中文版的疏忽与记事本的缺憾

对于 WordPress 而言，唯一可能需要用户修改的文件，就是 wp-config-sample.php 文件。这是 WordPress 重要配置文件，里面包含了 WordPress 的数据库信息，以及其他的一些参数。在官方发布的英文版中，这个文件使用的 ANSI 编码。但是在我们发布的 WordPress 中文版中，尽管该文件不涉及输出的中文信息，我们还是将这个文件和其他文件一起，保存成了 UTF8 no BOM 格式的文件。

这种格式本身并没有任何问题。但问题在于，大部分网友使用的编辑器，可能都是 Windows 操作系统所自带的记事本程序（Notepad.exe），而这个程序所支持的编码格式只有 ANSI, UTF8, Unicode 和 Unicode big endian 四种。因此，当用户修改为 wp-config-sample.php 文件，另存为 wp-config.php 文件的时候，原本的 UTF8 no BOM 格式，就是自动保存为 UTF8 ( with BOM )格式。记事本给文件自动添加 BOM （字节顺序标志），因此 wp-config.php 第一行就多出了一个 php 无法识别的标志，因此也就带来了上述的困扰。

受困扰的用户群和对应方案

从前面的分析来看，容易受到此问题迷惑的，主要是第一次安装 WordPress，并且使用记事本或者其他不区分 UTF8 with BOM 和 UTF8 no BOM 的编辑器保存 wp-config.php 的网友。而升级安装，以及通过在线填写数据库信息，自动生成 wp-config.php 文件的网友，则未受影响。

那么对于这个问题，我们也在这里提供几个不同的解决方案：

1. 使用 emeditor 或者其他能够区分 UTF8 with BOM 和 UTF8 no BOM 的编辑器，来编辑 wp-config.php 文件，将其保存为 UTF8 no BOM 编码格式；

2. 使用记事本或者其他无法区分 UTF8  with BOM 和 UTF8 no BOM 的编辑器，来编辑 wp-config.php 文件，将其保存为 ANSI 或者 gb2312 编码格式；

3. 如果你的主机支持写目录权限，那么也可以通过在线的方式，来自动生成 wp-config.php 配置文件。

当然，这个疏漏的最根本的原因，是我们在发布中文版的是时候有些自作聪明。虽然并非错误，却也给大家带来了不便，在这里我们向所有的 WordPress 用户道歉。我们也将在近期推出一个修正版，准备重新将 wp-config-sample.php 重新保存为 ANSI/gb2312 编码，彻底解决这个问题。

对于 WordPress 2.6 而言，其中最重要的一个更新就是文章版本管理功能。这个类似于 Wiki 功能的文章版本管理功能，可以随时将你的文章恢复到以前任何一次修改的版本。对于多用户的 WordPress 博客，这个功能尚有些用途；但对于大部分个人博客而言，我们并用不到这个功能。同时，由于使用文章版本管理功能，每一次修改都会占用一个文章ID，也很不舒服。

因此，很多网友升级 WordPress 2.6 之后就想立即关闭这个功能。关闭这个功能的办法很简单，WordPress 给用户和插件开发者预留了一个参数，WP_POST_REVISIONS，可以让你轻松关闭文章版本管理功能。

你可以直接在 wp-config.php 文件中定义 WP_POST_REVISIONS 这个常量，其共有三个参数：

• true, –1: 默认值，将存储文章每一次的修订；
• false, 0: 不保存任何修订的版本，但自动保存功能依然有效；
• >0 的整数: 最多保留的版本数量，超过此数的版本将被删除。

其实，我们可以将 WP_POST_REVISIONS 常量理解为保留版本的次数。如果常量为5，则保留最近5次修改的版本，当你第6次修订文章的时候，那么第1次修订的版本将被删除。如果常量为0，则不保留任何修订的版本。如果常量为-1，则保留每一次修订的版本，这是默认选项。

对于 WordPress 支持最好的当然是 Linux 主机。但国内情况特殊，很多网友不得不采用 Windows 主机。Windows 主机下使用 WordPress，还是存在一些 bug。比如，WordPress 2.6 下的永久链接功能失效了。

我们知道，一般 linux 主机下，我们可以将文章永久链接格式设置为类似于 http://wpchina.org/wordpress-26-english-and-chinese-version-release-276/ ；而在 Win 主机下，则永久链接需要通过 index.php 进行能够跳转，格式通常类似于 http://wpchina.org/index.php/wordpress-26-english-and-chinese-version-release-276/ 。即便如此，在 Windows 主机使用 WordPress 2.6 的网友还是发现，永久链接失效：除了博客首页，所有的链接都打不开了。

昨天下午就有两个网友就同一问题跟我咨询。在 WordPress 官方论坛上，也有很多网友反映统一问题。现在，这个问题已经有了解决方案。

登录 WordPress 后台，进入〖设置〗 –>〖永久链接〗，然后在〖可选〗数据区域添加 分类基础 和 标签基础 两项即可。如下图所示：

其中，category 和 tag 是 WordPress 默认的分类基础和标签基础，这样填写和你原来默认的情况一致（保持一致有利于搜索引擎优化）。当然，如果你愿意，也可以修改为任何自己喜欢的单词。

这样填写之后，点击最下面的〖保存修改〗，再重新打开你的单篇文章。怎么样，一切恢复正常了吧？天也蓝了，水也绿了，写博的好心情也来了吧？

ps: 本系列文章均为短篇小文。欢迎各位网友提出问题，或者给出解决问题的方案，或者也可以参与本系列的撰文，共同分享博客的乐趣！

你知需要修改 .htaccess ，添加如下代码即可：

SecFilterEngine Off
SecFilterScanPOST Off

感谢筱筱网友提供此解决方案。更多关于WordPress 2.5 问题的解决方案，请看WordPress 2.5 找错大行动。

这个 bug 将在 WordPress 2.5.2 中修复。然而，如果你现在就有这方面的麻烦，你可以阅读 Ryan McCue 的文章，通过phpMyAdmin“手动重置 WordPress密码”。此文为英文，感兴趣的网友可以翻译为中文。

此外，Ryan 还发布了一个修正这个漏洞的文件，你可以直接下载覆盖相应的文件。

原文：Reset WP Password Manually

中文：手动重置 WordPress 密码

标签重复问题

举例本站有一个标签叫“精彩主题”，缩略名为“themes-list”。但是如果你在书写新的文章的时候，在WordPress 撰写文章面板里直接添加了标签“精彩主题”，当你保存文章的时候，就发现标签的缩略名为“%E7%B2%BE%E5%BD%A9%E4%B8%BB%E9%A2%98”，这是“精彩主题”四个字所对应的UTF8 编码。

这时，你有了两个“精彩主题”标签，对应两个标签缩略名：一个对应容易看懂的英文“themes-list”，一个对应不容易看懂的“E7%B2%BE%E5%BD%A9%E4%B8%BB%E9%A2%98”。

解决方案

这个问题已经有网友向 WordPress Bug 跟踪系统报告，编号6313，被称之为标签重复问题。mtekk 给出了相应的解决方案，并将在 WordPress 2.6 中正式修复这个问题。现在你可以通过修改以下两个文件来自己修复这个问题。

1. 打开 <WordPress>/wp-includes/taxonomy.php ，大约 746 行附近：

if ( ” === $term = sanitize_title($term) )
return 0;
$where = $wpdb->prepare( “t.slug = %s”, $term );

修改为：

if ( ” === $sanitized = sanitize_title($term) )
return 0;
if ( ‘post_tag’ === $taxonomy ) {
$where = $wpdb->prepare( “(t.slug = %s OR t.name = %s)”, $sanitized , $term );
} else {
$where = $wpdb->prepare( “t.slug = %s”, $sanitized );
}

2. 打开 <WordPress>/wp-admin/wp-includes/taxonomy.php ，大约 136 行附近：

$tags_to_edit = join( ‘, ‘, $tag_names );

修改为：

$tags_to_edit = join( ‘,’, $tag_names );

这样，就应该解决了这个问题。

这个办法需要你的主机支持 .htaccess 文件（即 mod_rewrite 模块），也就是说仅对 Linux 主机 用户有效。打开你的 .htaccess 文件，添加代码：

SetEnvIfNoCase Request_URI ^<WordPress安装目录>/wp-admin/async-upload.php$ MODSEC_ENABLE=Off

其中 <WordPress安装目录>，也就是你WordPress程序所在的目录。假若 WordPress 安装在根目录，则直接 ^/wp-admin/…；假若 WordPress 安装在 wp 目录内，则 ^/wp/wp-admin/…。

在 WordPress 2.5 之前，也有类似的问题；但对于 2.5 之前的版本，网友基本摸索出了解决办法（附在最后），而这个办法已经不能用在 WordPress 2.5 中。

针对 WordPress 2.5 可视化编辑器的问题，在 WordPress 官方论坛上也是一片抱怨，并且至今没有完美的解决方案。不过，你可以按照以下办法来进行尝试。

办法1：清空浏览器缓存。

有时候，此问题仅仅是因为浏览器使用了缓存的原因。你只需要清空浏览器的缓存，重新打开，就发现可视化编辑器可能就重新工作了。

办法2：禁用压缩功能。

有时候，这个问题之所以不工作，仍然是服务器不支持gzip，或者php没有正确配置。你只需要修改禁用gzip即可。办法是，找到 <WordPress安装目录>/wp-includes/js/tinymce/tiny_mce_config.php 文件，其中第167行：

‘compress’ => true,

修改为

‘compress’ => false,

保存。然后重新打开，可视化编辑器可能重新工作了。

办法3：重新安装 WordPress。

有时候不一定是服务的问题，也不是缓存问题。比如说，有的网友在同一台服务器上，全新安装的 WordPress 不存在问题，而升级的 WordPress 存在问题。因此重新安装有时候可以解决问题，但建议按照如下步骤进行：

1. 重新安装 WordPress；
2. 在插件面板，禁用全部插件；
3. 现在去写文章，可视化编辑器出现了吗？如果是，继续往下；如果否，请回第1步；
4. 如果可视化编辑器已经出现，去插件面板激活所有插件；
5. 再次检查可视化编辑器时否工作正常。如果插件激活状态下，可视化编辑器可以正常工作，那基本上就正常了。

目前来说，我们只有通过上述办法来尝试解决 WordPress 2.5 中可视化编辑器不能工作的问题。当然，这里面办法2是相对容易操作的，陈华网友的问题也是按照这个办法解决的。

你在使用 WordPress 2.5 过程中发现别的问题了吗？或者可曾解决过 WordPress 2.5 中的某个问题？如果有的话，都欢迎加入我们的 WordPress 2.5 找错大行动。

附：WordPress 2.5 之前版本（2.3, 2.2, …）中同样问题的解决办法

对于之前的版本，解决办法也是禁用 gzip 功能。具体操作，找到 <WordPress安装目录>/wp-includes/js/tinymce/tiny_mce_gzip.php ，在第87行（WordPress 2.3.3版本，其他版本可能有差异），找到：

if ((in_array(‘gzip’, $encodings) || in_array(‘x-gzip’, $encodings) || isset($_SERVER['---------------'])) && function_exists(‘ob_gzhandler’) && !ini_get(‘zlib.output_compression’) && ini_get(‘output_handler’) != ‘ob_gzhandler’) {
$enc = in_array(‘x-gzip’, $encodings) ? “x-gzip” : “gzip”;
$supportsGzip = true;
}

将其中最后的 $supportsGzip 设置为否，也就是

$supportsGzip = false;

保存，这时候就可以看到你的可视化编辑器了。

Warning: Cannot modify header information - headers already sent by (output started at /home/html/blog/wp-config.php:47) in /home/html/blog/wp-includes/pluggable.php on line 689

前几天就有网友遇到此问题，但是第一个遇到此问题的网友，他 wp-config.php 文件本身有错误，我将这个问题给忽略了。今天，我们重新重视这个问题，并从网上找到了解决方案。答案非常简单：

使用任何文本编辑器打开你的 wp-config.php 文件，删除掉所有在 “<?php” 之前和在 “?>” 之后的空行和空格，保存即可。

该 bug 已经添加到 WordPress 2.5 bug 集里。如果你在使用 WordPress 2.5 也发现有什么问题，欢迎加入我们的 WordPress 2.5 找错大行动。

应该说，我们并没有预料到 WordPress 2.5 会在昨天发布，因为在 2.5 的开发日程上，这一版本还存在 200 多个 bug。如此着急发布，我猜测有可能是开发者受到了投资方的压力。当然，这里面的大部分 bug 对我们使用 WordPress 没什么影响，但有一些可能会影响到 2.5 的正常使用。

现在的问题是，这些 bug 里，究竟有哪些 bug 比较重要呢？因此，我们希望大家来一起加入我们的 WordPress 2.5 挑错大行动，一起找出并验证 WordPress 2.5 中存在的 bug，并寻求临时的应对办法。

如果你发现 WordPress 2.5 中存在的 bug，请你通过留言，或通过 trackback 来告诉我们；我们将在这里列出所有网友发现的问题，与中文社区的 WordPress 爱好者分享这一经验。

我们已经发现的 bug 和应对方案

1. 图片上传功能在 IE7, opera 下不可使用。
   这是 assad 发现的 bug。WordPress 图片上传功能在 ie7（WP 已不支持 ie6）和 opera 浏览器下存在bug，上传的图片无法查看。这是从 rc2 版本开始引入的 bug。
   解决办法：使用 Firefox 浏览器（阴谋论一下，不知道是不是和 matt 的安全浏览 firefox 推介网站有关）。
2. 使用加密协议的博客，feed 地址不加密。
   这是 北风 发现的 bug。其博客使用加密协议，即https://domain/。但是 feed 内所包含的自身地址并未使用加密协议：<atom:link type=”application/rss+xml” rel=”self” href=”http://domain/?feed=rss2″ />
   实际上，在 WordPress 2.5 中，已经包含了相应的代码，但似乎并未生效。代码在 <WordPress安装目录>\wp-includes\feed.php 内 244 行：

function self_link() {
    echo ‘http’
        . ( $_SERVER['https'] == ‘on’ ? ‘s’ : ” ) . ‘://’
        . $_SERVER['HTTP_HOST']
        . wp_specialchars(stripslashes($_SERVER['REQUEST_URI']), 1);
}
解决办法：所幸的是，使用加密协议的博客并不多。但如果你使用了加密协议的话，可以使用的临时解决办法，强制使用 https 协议。将代码修改为：

function self_link() {
    echo ‘https://’
        . $_SERVER['HTTP_HOST']
        . wp_specialchars(stripslashes($_SERVER['REQUEST_URI']), 1);
}

3. 错误警告：Cannot modify header information
   很多网友在升级的时候遇到了这个问题。幸好，解决这个问题并不难。详细介绍以及解决办法，请参考：WordPress 2.5 错误警告: Cannot modify header information
4. WordPress 可视化编辑器不能正常工作
   这时很多 WordPress 用户遭遇的烦心事。这里介绍了一些解决方案，可以让你的的可视化编辑器重现，详细介绍及解决方案：WordPress 2.5 可视化编辑器不能工作及应对方案
5. WordPress 上传图片 Http 错误
   如果你在使用 WordPress 2.5 的图片上传功能，可能遇到这样的问题：http 错误，Http error。详细介绍及解决方案：WordPress 上传图片 Http 错误解决办法

现在，有了 WordPress 密码重置文件（不是插件），你再不用为此问题担忧了。你只要安装此文件到 wordpress 根目录，然后运行即可重置密码。

警告：重置之后请立即删除此文件。

具体使用介绍请查看原文：wordpress忘记密码解决方案。