Note that there are some explanatory texts on larger screens.

plurals
  1. POphpinfo is reporting incorrect pcre version
    primarykey
    data
    text
    <p>I've spent the day trying to figure out a strange problem. I have a WordPress site that is running into the following error:</p> <pre><code>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 </code></pre> <p>That line in wp-includes/shortcodes.php is as follows:</p> <pre><code>$text = preg_replace("/[\x{00a0}\x{200b}]+/u", " ", $text); </code></pre> <p>I found this article that seemed to match up fairly well with my problem: <a href="http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/" rel="noreferrer">http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/</a></p> <p>The article describes a situation in which there is different output of <code>phpinfo();</code> in apache and on commandline with regard to <code>libpcre</code></p> <p>I verified that this is my issue by creating a test file with <code>phpinfo();</code> in it and also ran the following from the shell:</p> <pre><code>php -r "phpinfo();" </code></pre> <p>The script (apache?) version returns <code>PCRE Library Version 6.6 06-Feb-2006</code> The commandline version returns <code>PCRE Library Version =&gt; 8.21 2011-12-12</code></p> <p>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.</p> <p>The article mentions "fixing apache start-flags". I'm not sure what that means.</p> <p>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.</p> <p>==== Edit 1 ====</p> <p>I've have more information:</p> <pre><code>/opt/pcre/bin/pcretest -C </code></pre> <p>Returns</p> <pre><code>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 </code></pre> <p>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.</p> <p>==== Edit 2 ====</p> <p>I was tipped this article: <a href="http://www.bigboylemonade.com/pcre-version-problem-on-cpanel" rel="noreferrer">http://www.bigboylemonade.com/pcre-version-problem-on-cpanel</a></p> <p>Running <code>pcretest -C</code> without the full path returns:</p> <pre><code>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 </code></pre> <p>I'm going to see what I can do about performing those last steps and will update shortly</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload