phpinfo сообщает о некорректной версии pcre

Question

Я потратил этот день, пытаясь понять странную проблему. У меня есть сайт 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 

Эта линия в сор-включает/shortcodes.php выглядит следующим образом:

$text = preg_replace("/[\x{00a0}\x{200b}]+/u", " ", $text); 

Я нашел эту статью, в которой, казалось, совпадают довольно хорошо с моей проблемой: http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/

в статье описывается ситуация, в которой отличается выход phpinfo(); в апач и командной строки в отношении libpcre

Я проверил, что это мой вопрос, создав тестовый файл с phpinfo(); в нем, а также запускал вытекающий из оболочки:

php -r "phpinfo();" 

скрипта (? Апач) версия возвращает PCRE Library Version 6.6 06-Feb-2006 версия командной строки возвращает PCRE Library Version => 8.21 2011-12-12

Мне осталось интересно, что делать. Я не очень хорошо разбираюсь в использовании командной строки, поэтому я обращаюсь к вам с надеждой на помощь.

В статье упоминается «исправление начальных флагов apache». Я не уверен, что это значит.

Я также нашел комментарий где-то в другом месте: «Хорошо, оказалось, что проблема была в старой версии 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 при запуске через Интернет не возвращает правильные значения 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 

Я буду видеть что я могу сделать для выполнения этих последних шагов и скоро обновится

Answer 1

Хорошо, ребята, я наконец получил заметки от своего хозяина о том, как они фиксировали t роблема:

==================== Begin steps ============================== 

, когда я начал на этом конкретном сервере, это доступные данные:

[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 

Версия 6.6 также показывает в любом phpinfo() веб-страницы, а также в PHP -i. По умолчанию в версиях php> = 4.2 флаг компиляции Apache '--with-pcre-regex' автоматически включается, поэтому любой запуск EA будет использовать 6.6. версия, которую предоставляет cPanel . Ключ к этому был позволить OS знать о PCRE библиотеках мы хотим Apache использовать, таким образом, первый шаг был:

[root@host2] etc >> echo "/opt/pcre/lib/" >> /etc/ld.so.conf 

Тогда работает LDCONFIG - теперь у нас есть библиотеки для обоего версий PCRE Доступно для пользователей системы:

[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! Теперь, чтобы сказать Apache использовать те вместо 6,6 из них, использовать удобный rawopts файл и восстановить Apache:

[root@host2] etc >> echo "--with-pcre-regex=/opt/pcre" >> 
/var/cpanel/easy/apache/rawopts/all_php5 [root@host2.brucesallan.com] etc >> 
/scripts/easyapache --build 

Когда это сделано, проверить:

[root@host2] etc >> php -i | grep -i "pcre library" PCRE 
Library Version => 8.21 2011-12-12 [root@host2.brucesallan.com] 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 ============================ 

Answer 2

В нашем случае апача было не скомпилированный с использованием параметра --with-pcre.
Pcre и pcre-devel были установлены (из yum или apt репозиториев, нет необходимости его компилировать), тогда нам просто нужно было найти pcre-config.
В нашем случае это было/usr/bin/pcre-config, «bin», по-видимому, предполагается компилятором apache, поэтому окончательная строка ./configure должна включать:
--with-pcre =/usr