我花了一天时间试图解决一个奇怪的问题。我有一个 WordPress 网站遇到以下错误：
Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset -1 in /path/to/public_html/wp-includes/shortcodes.php on line 257
wp-includes/shortcodes.php 中的那一行如下：
$text = preg_replace("/[\x{00a0}\x{200b}]+/u", " ", $text);
我发现这篇文章似乎与我的问题非常匹配： http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/
文章描述了 phpinfo(); 在 apache 和命令行上关于 libpcre
我通过使用 phpinfo(); 创建一个测试文件来验证这是我的问题它还运行了来自 shell 的以下内容：
php -r "phpinfo();"
脚本（apache？）版本返回 PCRE Library Version 6.6 06-Feb-2006
命令行版本返回PCRE Library Version => 8.21 2011-12-12
我不知道该怎么办。我不太熟悉命令行的使用，所以我向你们求助，希望得到一些帮助。
文章提到“修复 apache start-flags”。我不确定这是什么意思。
我还在其他地方发现了一条评论：“好吧，事实证明问题是系统上挂着旧版本的 libpcre 并被错误加载。当我更新到最新版本的 libpcre 后，问题就解决了。 ”我不完全确定如何在服务器上审查这些信息。
==== 编辑 1 ====
我有更多信息：
/opt/pcre/bin/pcretest -C
返回
PCRE version 8.21 2011-12-12
Compiled with
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
这并不完全令人惊讶，因为我们已经知道命令行返回正确的版本。但由于某些疯狂的未知原因，PHP 在通过 Web 运行时不会返回正确的 pcre 值。
==== 编辑 2 ====
我收到这篇文章： http:// /www.bigboylemonade.com/pcre-version-problem-on-cpanel
在没有完整路径返回的情况下运行 pcretest -C：
PCRE version 6.6 06-Feb-2006
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
我将看看如何执行这些操作最后的步骤和意愿很快更新
I've spent the day trying to figure out a strange problem. I have a WordPress site that is running into the following error:
Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset -1 in /path/to/public_html/wp-includes/shortcodes.php on line 257
That line in wp-includes/shortcodes.php is as follows:
$text = preg_replace("/[\x{00a0}\x{200b}]+/u", " ", $text);
I found this article that seemed to match up fairly well with my problem: http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/
The article describes a situation in which there is different output of phpinfo(); in apache and on commandline with regard to libpcre
I verified that this is my issue by creating a test file with phpinfo(); in it and also ran the following from the shell:
php -r "phpinfo();"
The script (apache?) version returns PCRE Library Version 6.6 06-Feb-2006
The commandline version returns PCRE Library Version => 8.21 2011-12-12
I'm left wondering what to do. I'm not super well versed in command line usage, so I'm turning to you all hoping for some help.
The article mentions "fixing apache start-flags". I'm not sure what that means.
I've also found a comment somewhere else saying: "OK, it turned out that the problem was an older version of libpcre hanging around on the system and getting loaded by mistake. Once I updated to the latest version of libpcre, problem fixed." I'm not entirely sure how to vet this information on the server.
==== Edit 1 ====
I've have more information:
/opt/pcre/bin/pcretest -C
Returns
PCRE version 8.21 2011-12-12
Compiled with
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
This is not entirely surprising because we already know that the command line returns the correct version. But for some crazy unknown reason PHP, when run via the web, doesn't return the proper pcre values.
==== Edit 2 ====
I was tipped this article: http://www.bigboylemonade.com/pcre-version-problem-on-cpanel
Running pcretest -C without the full path returns:
PCRE version 6.6 06-Feb-2006
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
I'm going to see what I can do about performing those last steps and will update shortly
发布评论
评论（2）
好吧，我终于从我的主机那里得到了关于他们如何解决问题的注释：
当我在这个特定的服务器上启动时，这是可用的数据：
版本 6.6 也出现在任何 phpinfo() 网页以及 php -i 中。
默认情况下，在 php 版本 >= 4.2 中，Apache 编译标志 '--with-pcre-regex'
会自动包含在内，因此任何 EA 运行都将使用 6.6。 cPanel 的版本
提供。关键是让操作系统知道我们的 PCRE 库
希望 Apache 使用，所以第一步是：
然后运行 ldconfig ——现在我们有了两个版本的 PCRE 的库
可供系统用户使用：
耶！现在，要告诉 Apache 使用这些而不是 6.6 的，请使用方便的
rawopts 文件并重建 Apache：
完成后，测试它：
Ok guys, I finally got the notes from my host about how they fixed the problem:
when I started on this particular server, this was the data available:
Version 6.6 was also showing up in any phpinfo() webpage and also in php -i.
By default in php versions >= 4.2, the Apache compile flag '--with-pcre-regex'
is automagically included, so any EA run will use the 6.6. version that cPanel
provides. The key to this was letting the OS know about the pcre libraries we
want Apache to use, so the first step was to:
Then running ldconfig -- now we have the libraries for both versions of PCRE
available for the system users:
Yay! Now, to tell Apache to use those instead of the 6.6 ones, use the handy
rawopts file and rebuild Apache:
When it's done, test it:
在我们的例子中，apache 没有使用 --with-pcre 参数进行编译。
pcre 和 pcre-devel 已安装（来自 yum 或 apt 存储库，无需编译），然后我们只需找到 pcre-config。
在我们的例子中，它是 /usr/bin/pcre-config，“bin”似乎是由 apache 编译器假定的，因此最后的 ./configure 行必须包括：
--with-pcre=/usr
In our case apache was not compiled using the --with-pcre parameter.
Pcre and pcre-devel was installed (from yum or apt repositories, no need to compile it), then we just had to locate pcre-config.
In our case it was /usr/bin/pcre-config, the 'bin' seems to be assumed by the apache compiler, so the final ./configure line had to include:
--with-pcre=/usr