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
Ok guys, I finally got the notes from my host about how they fixed the problem:
==================== Begin steps ==============================
when I started on this particular server, this was the data available:
[root@host2] ~ >> 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
[root@host2] ~ >> /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
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:
[root@host2] etc >> echo "/opt/pcre/lib/" >> /etc/ld.so.conf
Then running ldconfig -- now we have the libraries for both versions of PCRE available for the system users:
[root@host2] etc >> ldconfig -v | grep -i pcre
/opt/pcre/lib:
libpcre.so.0 -> libpcre.so.0.0.1
libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
libpcreposix.so.0 -> libpcreposix.so.0.0.0
libpcre.so.0 -> libpcre.so.0.0.1
libpcre.so.0 -> libpcre.so.0.0.1
libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
libpcreposix.so.0 -> libpcreposix.so.0.0.0
libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
libpcreposix.so.0 -> libpcreposix.so.0.0.0
[root@host2] etc >>
Yay! Now, to tell Apache to use those instead of the 6.6 ones, use the handy rawopts file and rebuild Apache:
[root@host2] etc >> echo "--with-pcre-regex=/opt/pcre" >>
/var/cpanel/easy/apache/rawopts/all_php5 [[email protected]] etc >>
/scripts/easyapache --build
When it's done, test it:
[root@host2] etc >> php -i | grep -i "pcre library" PCRE
Library Version => 8.21 2011-12-12 [[email protected]] etc >>
[root@host2] ~ >> pcretest -C PCRE
PCRE version 8.21 2011-12-12
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
[root@host2] ~ >> /opt/pcre/bin/pcretest -C PCRE
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
========================== End ============================
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With