preg_match(): Compilation failed at wp-db.php on line 1657

@rcwall
Pioneer Web Design: Welcome back, though I don’t follow what you are saying.

Anyway, while doing some digging into the specific problem raised by the OP, I came across this:
Example #4 on https://php.net/manual/en/function.preg-match.php
Apologies for the no doubt incorrect formatting

<?php

$str = 'foobar: 2008';

preg_match('/(?P<name>\w+): (?P<digit>\d+)/', $str, $matches);

/* This also works in PHP 5.2.2 (PCRE 7.0) and later, however 
 * the above form is recommended for backwards compatibility */
// preg_match('/(?<name>\w+): (?<digit>\d+)/', $str, $matches);

print_r($matches);

?>

The wp-db.php file from WP 4.9 uses the syntax ?< rather than ?P< in lines relevant to line 1657.
See below, my highlighting, snippet ends at line 1657.

	 * @since 4.9.0
	 *
	 * @param string $host The DB_HOST setting to parse.
	 * @return array|bool Array containing the host, the port, the socket and whether
	 *                    it is an IPv6 address, in that order. If $host couldn't be parsed,
	 *                    returns false.
	 */
	public function parse_db_host( $host ) {
		$port    = null;
		$socket  = null;
		$is_ipv6 = false;

		// We need to check for an IPv6 address first.
		// An IPv6 address will always contain at least two colons.
		if ( substr_count( $host, ':' ) > 1 ) {
			<strong>$pattern = '#^(?:\[)?(?<host>[0-9a-fA-F:]+)(?:\]:(?<port></strong>[\d]+))?(?:/(?<socket>.+))?#';
			$is_ipv6 = true;
		} else {
			// We seem to be dealing with an IPv4 address.
			<strong>$pattern = '#^(?<host>[^:/]*)(?::(?<port>[\d]+))?(?::(?<socket>.+))?#';</strong>
		}

		$matches = array();
		$result = preg_match( $pattern, $host, $matches );

Adding the P i,e changing ?< to ?P< in the highlighted lines in the WP 4.9 version of wp-db.php and reloading manually WP 4.9 (with modified wp-db.php) on my site (curtc.net hosted by Easily) causes the Warning highlighted by the OP to go away… As far as I can tell the site is fully functional.

Of course this is not conclusive as Easily could have updated their php version by now.

Please note, I’m no php expert but this has worked for me. But please proceed at your own risk and frankly I don’t recommend it.

Again, thanks to those who have helped with the problem highlighted by the OP.

Edit Highlighting in the 2nd code box appears as the code for bold and end code for bold, i.e. the lines containing $pattern

• This reply was modified 7 years, 3 months ago by crkm.
• This reply was modified 7 years, 3 months ago by crkm.

@swansonphotos
Thank you for rejoining the discussion. I’m afraid some of your points are lost on me too. The issue appeared immediately I updated to V4.9 – therefore at first sight it had to be a problem either with the version or with the process of updating. When I found a similar (maybe identical) report in the other place, I posted here requesting help. Isn’t that part of the function of a forum? It certainly is over at OEM.

I reviewed the links in your post on page 1 but frankly, to me they seemed irrelevant. After all, I’m a user, not a developer or even a keen bodger, of WordPress.

As for your recent points:

1. Each time a major release is made available, the dashboard (along with well known site responsibilities), includes important warnings about backing up your site(s).

I saw someone make that mistake many decades ago, in the days of the PDP11 and 15″ platters. I run an automatic backup nightly.

2. www.ads-software.com is not your hosting provider. If a specific host has issues, please review the hosting recommendations.

Nobody ever said www.ads-software.com is a hosting provider, and only when it became clear that mainly, maybe only, sites hosted at Easily were having problems (and I for one am grateful to the www.ads-software.com forum for providing this platform) was it becoming evident that there was some degree of certainty that the fault might lie with a specific hosting provider. Before then, it was experience or an educated guess – and there’s nothing wrong with either, but they’re insufficient to apportion blame.

3. If you think this is an issue with a WordPress Plugin, then the proper support channel for help with such issues is at their support page. A simple search will find the plugin of question.

I think I actually ruled out a plug-in fairly early on.

Please help yourself and your site clients by finding a web host that starts with Job One (Security).

I can’t find the hosting provider Job One. The hosting I use has functioned satisfactorily with WordPress for about 7 years, so what changed?

WordPress is not based simply on files. Simply changing a set of files does not affect the MySQL DB. Please all review the Codex for proper details. It’s also not new.

My understanding of WordPress is it is a huge piece of PHP, spread across very many files, that uses MySQL to manage the data. Once again, I don’t think anyone has mentioned MySQL until now, and I’m struggling to see how it is relevant. Where in the Codex should I start looking?

@crkm
It does look as if you’ve found the problem, but my Easily is running PHP 5.5.17, and according to the way I (hurriedly) read the manual earlier, it appears that it should accept both versions. The comment in your snippet is revealing: “however the above form is recommended for backwards compatibility”.

Having our own version of one file is fundamentally wrong and dangerous, so I’m still looking to the maintainer of wp-db.php and to Easily for a proper solution, and won’t implement your patch just yet.

We have a response from Easily. Not the best news, but at least something might happen:

Hello,

I would like to take this opportunity to apologise for the inconvenience caused.
We would like to advise you that Easily does not currently support the latest version of WordPress 4.9. Affected customers should therefore, not upgrade to WordPress 4.9 due to a risk that your websites will not work. We apologise for the inconvenience caused if you have already attempted to upgrade. Easily will be able to support WordPress Installation Version 4.9 in 2018 when we introduce our new service improvements in early 2018.

If you have attempted to upgrade to WordPress 4.9, we recommend you revert back to the previous version until we have confirmed we are able to support the new version.

Once again, we would like to take this opportunity to apologise for any inconvenience this may cause.

Regards,

[redacted]

• This reply was modified 7 years, 3 months ago by Marius L. J.. Reason: Removed personal contact details

Try doing a phpinfo and getting all the relevant versions for everything. PHP, PCRE, any libraries, anything with a version.

I thought this was fixed in PHP 5.2.2, but maybe not. Some hosts use custom builds. It would be nice to know what to look for.

Also, yes, replacing (?< with (?P< will fix the syntax error there.

Hi,
I’m fairly happy to wait and have gone back to 4.8.3. Hopefully the plug-in updates will work.

It’s not good when products are updated and they become unusable.

I have no idea what the coding is about as written above and the forum has satisfied my query and answered the others. Thanks

• This reply was modified 7 years, 3 months ago by pete5000.

Exactly the same issue with https://www.stmaryoftheangels.org.uk just now. “Warning: preg_match(): Compilation failed: unrecognized character after (?< at offset 4”. If you log out of the admin panel you can’t get back in.

Thankfully backed up the Files and DB beforehand so could roll back to prior version and this fixed the issue. I’m not going to upgrade to 4.9 until the issue is fixed, either Easily or with www.ads-software.com.

until the issue is fixed, either Easily or with www.ads-software.com.

WordPress has no control over you hosting provider.

So be in touch with them.

If they don’t fix their server issue as you expect them to, then time to look for an another host ??

@otto42

Samuel Wood (Otto) (@otto42)
www.ads-software.com Admin

Try doing a phpinfo and getting all the relevant versions for everything. PHP, PCRE, any libraries, anything with a version.

Here is what I hope is sufficient (and not enough to give hackers too much help):

PHP Version: 5.5.17
System: Linux lws03.ldn5.groupnbt.net 2.6.18-194.32.1.el5PAE #1 SMP Wed Jan 5 18:43:13 EST 2011 i686
Build Date: Sep 23 2014 13:43:39
PHP API: 20121113
PHP Extension: 20121212
Zend Extension: 220121212
Zend Extension Build: API220121212,NTS
PHP Extension Build: API20121212,NTS
cURL Information: 7.15.5
EXIF Version: 1.4
MySQL Client API version: 5.0.77
MySQLi Client API library version 5.0.77
OpenSSL Library Version: OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
OpenSSL Header Version: OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
PCRE Library Version: 6.6 06-Feb-2006
Phar EXT version: 2.0.2
Phar API version: 1.1.1
SQLite Library: 3.8.4.3
SERVER_SOFTWARE: Apache/2.2.3 (CentOS)

• This reply was modified 7 years, 3 months ago by RWall.
• This reply was modified 7 years, 3 months ago by RWall.

Ooh, that is an old PCRE library. Might be that. I’ll look around, try to find changelogs.

I just had this same issue. You may be interesting in checking out the fix committed in the alpha v5 version of WP.

https://github.com/WordPress/WordPress/commit/fc42c062f1bcaea742fde26068a4cf5fde6d9390

Turns out the error appears when “WordPress is used with (sometimes a modern) PHP that’s compiled against an ancient PCRE version.”

Toodles.

Have you any idea how solid that alpha version is?

I’ve no control over the PHP or PCRE version, and my hosting povider is going to get around to a fix some time early this year! So I’m torn between waiting for them and risking a running site with an alpha version. I’m running WordFence, so I’m not feeling paranoid, but at the same time I don’t want to stay with an old WordPress any longer than necessary.

But that’s nevertheless good information, thank you, and I’ll use it to try to poke them into action sooner rather than later.

.

Hi @rwall
I’ve just noticed that this problem was fixed by the great people at WordPress in WP 4.9.3
from the Summary at https://codex.www.ads-software.com/Version_4.9.3
WPDB
#43109 – Use a PCRE syntax which supports PCRE compiled between 2003 and 2006.

Easily have not updated the PCRE for our account, i.e. it is still PCRE Library Version 6.6 06-Feb-2006. Nonetheless, curtc.net is now running WP 4.9.4 (unmodified) without generating the ‘preg_match(): Compilation failed…’ message

Well spotted – thank you. I’ve updated to V4.9.4 and I’m pleased to say it went without a hitch and everything’s back to normal now.

So a thank-you from me to those who pointed everybody in the right direction, and especially to the WordPress maintainers too. I think I can mark this as resolved.