phpinfo zgłasza nieprawidłową wersję PCR

Question

Spędziłem cały dzień próbując znaleźć dziwny problem. Mam witryny WordPress, który jest uruchomiony na następujący błąd:

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 

To linia w wp-includes/shortcodes.php jest następujący:

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

znalazłem ten artykuł, który zdawał się zgadzać dość dobrze z moim problemem: http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/

Artykuł opisuje sytuację, w której istnieje inna wyjście phpinfo(); w apache i poleceń w odniesieniu do libpcre

I sprawdzeniu, że to jest mój problem, tworząc plik testowy z phpinfo(); w nim, a także prowadził następujące z powłoki:

php -r "phpinfo();" 

Skrypt (? Apache) wersja zwraca PCRE Library Version 6.6 06-Feb-2006 Wersja poleceń zwraca PCRE Library Version => 8.21 2011-12-12

Zastanawiam się, co robić. Nie jestem zbyt dobrze zorientowany w używaniu linii poleceń, więc zwracam się do was wszystkich mając nadzieję na jakąś pomoc.

W artykule wymieniono "naprawianie flag startowych apache". Nie jestem pewien co to znaczy.

Znalazłem również komentarz gdzieś indziej, mówiąc: "OK, okazało się, że problem był starszą wersją biblioteki libpcre, która kolidowała z systemem i została załadowana przez pomyłkę." Po aktualizacji do najnowszej wersji libpcre , problem rozwiązany." Nie jestem do końca pewien, jak zweryfikować te informacje na serwerze.

==== Edycja 1 ====

mam mieć więcej informacji:

/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 

To nie jest zupełnie zaskakujące, ponieważ już wiemy, że wiersz poleceń zwraca poprawną wersję. Ale dla jakiegoś szalonego nieznanego powodu PHP, po uruchomieniu przez sieć, nie zwraca poprawnych wartości pcre.

==== ==== Edycja 2

byłem wyrzucenia ten artykuł: http://www.bigboylemonade.com/pcre-version-problem-on-cpanel

Running pcretest -C bez pełnej ścieżki zwraca:

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 

Idę zobaczyć co mogę zrobić, aby wykonać te ostatnie kroki i zaktualizuję się wkrótce

Answer 1

Ok chłopaki, w końcu dostałem notatki od mojego gospodarza o tym, jak naprawili on problemem:

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

kiedy zacząłem na tym konkretnym serwerze, to było dostępne dane:

[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 

Wersja 6.6 została również pojawiać się w dowolnym phpinfo() strony internetowej, a także w php -I. Domyślnie w wersjach PHP> = 4.2, flaga kompilacji Apache "--with-pcre-regex" jest uwzględniana automagicznie, więc każdy przebieg EA będzie używał 6.6. Wersja, którą zapewnia cPanel . Kluczem do tego było pozwalając OS wiedzieć o bibliotekach pcre chcemy Apache w użyciu, więc pierwszym krokiem było:

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

następnie uruchomić ldconfig - teraz mamy biblioteki dla obu wersji PCRE dostępne dla użytkowników systemu:

[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! Teraz, aby powiedzieć Apache użyć tych, zamiast 6,6 te, użyj wygodnej plik rawopts i odbudować 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 

Kiedy to się robi, przetestować go:

[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

w naszym przypadku Apache został nieskompilowane przy użyciu parametru --with-pcre.
Zainstalowano Pcre i pcre-devel (z repozytoriów yum lub apt, bez potrzeby kompilowania), po prostu musieliśmy zlokalizować pcre-config.
W naszym przypadku był to/usr/bin/pcre-config, "bin" wydaje się być przejmowany przez kompilator apache, więc ostateczna linia ./configure musi zawierać:
--with-pcre =/usr