MediaWiki v1.19.1 installation: Compilation failed: support for \P, \p, and \X has not been compiled
AFAIK the only things that can be done are to (1) recompile PHP using make, (2) check to see if another version of PHP is available, or (3) report the bug to the distribution maintainers. The source code can be found here.
Ideally the MediaWiki installer would check for this condition and issue a warning and (best) work around the limitation, or (failsafe) if that's not possible then issue a warning and abort the install.
The workaround I opted for is simply an older version of MediaWiki (v1.16.5 installed fine, I didn't try any intermediate versions).
\P is a unicode regex. The installer should check for unicode support and fail if it is not available. (and i believe that check was there in 1.16 too). If you can install mediawiki without Unicode PCRE support, it is a bug.
v1.16.5 installs with no complaints or errors in regards to this issue, nor does it seem to show any misbehavior while running in my brief testing.
v1.19.1 fails to install, but fails very ungracefully. A simple check during the compatibility check phase of the installer would catch the problem:
if (!@preg_match('/\pL/', 'test')) {
$PCREfail = true;
}
or if you want to use a shell call: if (!preg_match('/^ *Unicode properties support *$/im', `pcretest -C`)) {
$PCREfail = true;
}
We do the following:
793 protected function envCheckPCRE() {
794 if ( !function_exists( 'preg_match' ) ) {
795 $this->showError( 'config-pcre' );
796 return false;
797 }
798 wfSuppressWarnings();
799 $regexd = preg_replace( '/[\x{0430}-\x{04FF}]/iu', '', '-АБВГД-' );
800 wfRestoreWarnings();
801 if ( $regexd != '--' ) {
802 $this->showError( 'config-pcre-no-utf8' );
803 return false;
804 }
805 return true;
806 }
Note: pcretest is not neccesarily compiled with the same version of PCRE as php, so we wouldn't want to do a shell callout.
A brief skim of the man page seems to indicate PCRE can be compiled with --enable-utf but not --enable-unicode-properties which I think would make the above test pass, but MediaWiki fall on its face. Hence the above test needs to be improved.
With UTF and without Unicode properties seems to be the default configuration of Plesk 11 (with PHP 5.3.x) on CentOS (5.4), and it does indeed fall on its face.
Tracked in bugzilla:38249. I'll probably fix this at some point later in week if no one else does first.
Hi. Is there any update on this problem? I have a 1.15 MW installation that failed miserably when I tried to bring it to 1.19 and this seems to have been the major culprit. I am trying to migrate onto the latest version of my virtual distributed server platform (GoDaddy CentOS 6 with PLESK 11), so I imagine others must be running into this as well.
Can anyone confirm what the most current version of MW is that DOESN'T have this problem? My MW uses Sphinx and the SphinxSearch extension. There was a major update to SphinxSearch in MW 1.16 which also supports the most current Sphinx implementation. Because of the work and uncertainty in upgrading MW, I'd rather only do it once, but SphinxSearch is important, so I'd updated to a less-than-current MW if this problem won't be solved for a while.
Thanks!
Michael Greis
I seem to be having the same problem in 1.19.2:
Warning: preg_split(): Compilation failed: support for \P, \p, and \X has not been compiled at offset 192 in /var/www/html/wiki/includes/parser/Parser.php on line 1483 Warning: array_shift() expects parameter 1 to be array, boolean given in /var/www/html/wiki/includes/parser/Parser.php on line 1484 Warning: preg_split(): Compilation failed: support for \P, \p, and \X has not been compiled at offset 192 in /var/www/html/wiki/includes/parser/Parser.php on line 1483 Warning: array_shift() expects parameter 1 to be array, boolean given in /var/www/html/wiki/includes/parser/Parser.php on line 1484
Hi, Is there any update on this?
I am still on 1.16.5 because of this isses. :-(
HELP!
