CentOS, CiviCRM and PCRE Unicode Properties

[selfuntitled]

Just wanted to share with the community the solution to a problem I've been wrestling with recently, that isn't well documented here.

Problem
When installing the current version of CiviCRM, or upgrading to v2.1 or higher you receive the following error:
    * warning: preg_replace() [function.preg-replace]: Compilation failed: PCRE does not support \L, \l, \N, \P, \p, \U, \u, or \X at offset 6 in /home/sites/mywebsite.org/public_html/cms/sites/all/modules/civicrm/packages/IDS/Converter.php on line 571.

What's happening
So, lots of web servers run CentOS 4.7 or 5.2 (probably yours if you are getting this error)
CentOS uses a it's own PCRE package, which doesn't have all the features which CiviCRM assumes it will have, specifically, it does not have Unicode Properties Enabled. 

Solution
If you don't have root access to your server, you're pretty much out of luck. 
If you do have root access, you can download the source code for PCRE, enable Unicode Properties Support, recompile the package, and install it. 

If that solution sounds a little daunting - you can download a recompiled version of the package here:
http://gaarai.com/2009/01/31/unicode-support-on-centos-52-with-php-and-pcre/ (includes support for v4.7 x32 v5.2 x32 and x64)

So, all you need to do:
wget http://gaarai.com/wp-content/uploads/2009/01/pcre-6.6-2.7.i386.rpm (this is the 32 bit CentOS 5.2 version - check the site for other versions)
rpm -Uvh [your download directory]/pcre-6.6-2.7.i386.rpm

Your system is patched and ready to run CiviCRM!

[Piotr Szotkowski]

    * warning: preg_replace() [function.preg-replace]: Compilation failed: PCRE does not support \L, \l, \N, \P, \p, \U, \u, or \X at offset 6 in /home/sites/mywebsite.org/public_html/cms/sites/all/modules/civicrm/packages/IDS/Converter.php on line 571.

Thanks a lot for the workaround!

Here are two threads at PHPIDS’s forum about this issue: preg_replace Compilation failed and Drupal and CiviCRM installation.

[davej]

I had a similar error when editing a report:

Code: [Select]

Compilation failed: support for \P, \p, and \X has not been compiled at offset 1 in .../sites/all/modules/civicrm/packages/IDS/Monitor.php on line 445
- This doesn't mention PCRE but I suspect it's the same issue.

Here's a Red Hat bug report:

pcre is configured with no support for Unicode properties
https://bugzilla.redhat.com/show_bug.cgi?id=457064

- Note the comments:
"This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?". "

If you're a paying Red Hat customer affected by this issue, you could contact your rep and encourage them to get this fixed. I have contacted Rackspace, a big Red Hat customer, who are now pursuing this with Red Hat.

Update from Rackspace: Red Hat have said that PCRE unicode properties support will not be included in RHEL 5.5 but may be included in 5.6 . So in the meantime we have the problem that CiviCRM is not fully compatible with current versions of Red Hat or CentOS (which anyway are stuck on PHP 5.1 unless you grab 5.2 packages from a third-party repository). The only solution for now seems to be to rebuild the pcre rpm as described at http://gaarai.com/2009/01/31/unicode-support-on-centos-52-with-php-and-pcre/ .

To check your PCRE:

Code: [Select]

$ pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  No Unicode properties support   <== This is the problem
  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
Dave

[demeritcowboy]

Getting this too. Interestingly it wasn't there in 3.0, but I'm seeing it in trunk/3.2.
If your site isn't public or you aren't worried about malicious form data, a quicker workaround is to just replace the offending lines with
$tmp_value = $value;
$tmp_key = $key;

[Donald Lobo]

we've upgraded the PHP-IDS library to the latest version. hence getting it in trunk but not 3.0

lobo

[demeritcowboy]

Yes it's just interesting that the history of this thread indicates it was a problem before 3.0, then it disappeared, and now it's back.

[asiams]

Here is my PCRE:

# pcretest -C
PCRE version 4.5 01-December-2003
Compiled with
  UTF-8 support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Match recursion uses stack

Would this be ok with new 3.1 installation?

Thanks.

[asiams]

Mine is very old and the version is 4.5.

[davej]

Hi asiams,

That looks like a very old version; the fact that "Unicode properties support" isn't mentioned doesn't look promising.

However I've found that PHP may use its own built-in PCRE rather than the system one, so un unfavourable result from pcretest isn't necessarily a problem. If you create a phpinfo page:

Code: [Select]

<?php echo phpinfo(); ?>

The output will tell you which PCRE version is actually being used - search for PCRE in the output. In Configure Command, if you see something like '--with-pcre-regex=/usr', that indicates it's using the system PCRE. Further down, there should be a section headed "pcre" where you'll see details of the version being used.

Hope this helps,

Dave J

[asiams]

Thank you David,

Here is my phpinfo regarding pcre:

pcre
PCRE (Perl Compatible Regular Expressions) Support    enabled
PCRE Library Version    7.9 2009-04-11

Directive   Local Value   Master Value
pcre.backtrack_limit   100000   100000
pcre.recursion_limit   100000   100000

I guess I am ok with this?

Thanks.

[davej]

Hi asiams,

That's the same version as I have on a server where it works fine. I don't think we can tell directly from the version info whether Unicode Properties Support has been enabled but my impression is that if you have a reasonably recent PCRE, you should be OK.

Regards,

Dave J

[asiams]

I was able to use civi yesterday to add some individual contacts.

Then I set the global setup to default language to Japanese.

I also added some global settings to use addresses for US, Japan, and Korea.

When I saved the settings, there was warning saying you are making this multiligual site or something like that. I saved. After that, previously saved contacts were not visible, but it was recorded in the system. I left it there, this morning, when I tried to add some more contacts, the screen became blank.without any message.

Is there any hint I can use to correct?

Thanks.

[davej]

Hi asiams,

Are there any errors in your apache error log? A blank screen usually indicates a fatal PHP error, such as memory limit reached.

Dave J

[Brainwrap]

Just wanted to share with the community the solution to a problem I've been wrestling with recently, that isn't well documented here.
...

So, all you need to do:
wget http://gaarai.com/wp-content/uploads/2009/01/pcre-6.6-2.7.i386.rpm (this is the 32 bit CentOS 5.2 version - check the site for other versions)
rpm -Uvh [your download directory]/pcre-6.6-2.7.i386.rpm

Your system is patched and ready to run CiviCRM!

Hmmm...According to MediaTemple, the version I have is pcre-6.6-2.el5_1.7

This sounds awfully close to the version you mention, but I'm still getting the PCRE Unicode error described at the top of the thread.

Assuming I *do* need to update it, http://www.pcre.org/ says that the most recent version is actually 8.01.

So, I guess I have a couple of questions here:

1. Assuming that I'm unable to update the version for whatever reason, is it critical to do so? That is, will CiviCRM not work properly without it, or will it just cause those warning messages?

2. If I do update it, which version should I use, and can I use the gaarai.com link to do so, given how close my current version is to the one you linked to?

3. If I do the update, will that in turn cause any disruption/compatibility issues with other sites/functions/scripts on the server?

Thanks...

[demeritcowboy]

The version number is (mostly) irrelevant. It's whether the package was compiled with unicode support or not. So:

1) If you don't mind the warnings, things should still work.

2) You should be able to use the one given in the link.

3) It could. Can't say without knowing what else is on that server. Seems unlikely though. Running that rpm command should give you a warning if there's some kind of package dependency mismatch. Add the --test flag if you want to see dry run output.