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

Try:
manually resetting your plugins (no Dashboard access required). If that resolves the issue, reactivate each one individually until you find the cause. Also remember to deactivate any plugins in the mu-plugins folder (if you have created such folder). The easiest way is to rename that folder to mu-plugins-old.
– switching to the unedited default Theme (Twenty Seventeen) for a moment using the WP dashboard to rule out any theme-specific issue (theme functions can interfere like plugins).

Thanks, but I tried that – it provoked even more reports from different places of the same error. V4.8.3 is now re-loaded and showing no error.

I would attempt a manual install but first compare the file misc.php as noted above with with the downloaded version. It’s typically the second file listed in headers not sent error. Not always, but more often than not by far. I also have not seen this issue, nor have many others now, so it does seem unique…

• This reply was modified 7 years, 3 months ago by Pioneer Web Design. Reason: typos :-)

V4.8.3 is now re-loaded and showing no error.

Glad to know 4.8.3 is working without any error.

However, it would be better to solve your current problem.

If you like to troubleshoot further, try MANUALLY updating. Download WordPress again and unzip it. Access your server via SFTP or FTP, or a file manager in your hosting account’s control panel (consult your hosting provider’s documentation for specifics on these), and delete then replace your copies of everything on the server except the wp-config.php file and the /wp-content/ directory with fresh copies from the download. This will effectively replace all of your core files without damaging your content and settings. Please read the Manual Update directions first.

Hi, I too am seeing this error on https://www.curtc.net. The site loads but the error message referring to line 1657 in wp-db.php appears at the top. However it is no longer possible to reach the login page for the site (which of course is a but of a pain). This did not happen with 4.8.3 and I will downgrade back to 4.8.3.
Looking at line 1657 in wp-db.php, there is indeed a preg_match statement which is part of a new bit of code (since 4.9.0) that parses the db_host. Could this be a php version issue?
My $0.02
Christie
ps Many thanks to all behind WordPress, its development and this forum. I’d be truly (deleted) without you all.

However, it would be better to solve your current problem.

I agree totally. I downloaded the content and I shall set up WordPress V4.9 locally and see if I can reproduce the problem, meanwhile thank you all for the suggestions. If the local install does not show the fault, then I’ll try as you suggest.

Could this be a php version issue?

That’s surely one to consider. The version I have is 5.5.17 (but I cannot control that – that’s set by the hosting). Locally, I have 7.0.22.

So, having replaced everything with the V4.9 versions (except as noted), disabled all plugins and running on the Twenty Seventeen Theme, I’ve still got the problem.

I did have a “dummy” V4.9 running locally with the database but without any content, and that appeared to be ‘clean’. Whether that reinforces @crkm’s suggestion of a PHP version issue, I don’t know enough PHP to say.

[Edit]
I’m not sure what you were saying about mics.php The V4.9 version has, and V4.8.3 does not have, the function wp_admin_headers() which is where the error is being generated at line 1114: “header( sprintf( ‘Referrer-Policy: %s’, $policy ) );”

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

The complete set of code we are discussing is:

/**
 * Send a referrer policy header so referrers are not sent externally from administration screens.
 *
 * @since 4.9.0
 */
function wp_admin_headers() {
	$policy = 'same-origin';

	/**
	 * Filters the admin referrer policy header value. Default 'same-origin'.
	 *
	 * @since 4.9.0
	 * @link https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
	 *
	 * @param string $policy The referrer policy header value.
	 */
	$policy = apply_filters( 'admin_referrer_policy', $policy );

	header( sprintf( 'Referrer-Policy: %s', $policy ) );
}

Can you review with your host, your install with the issue, that nothing is affected the referrer headers?

As far as I can see, all this does is force the referrer URL’s to not have query vars (?var=value), such as usernames or other data not needed to be shared across sites.

Please review:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

https://blog.mozilla.org/security/2015/01/21/meta-referrer/

I don’t think it’s a PHP version issue as I am sure core has tested at PHP5.5XX

https://www.ads-software.com/about/requirements/

You may want to move to a host that offers PHP 7 regardless of the outcome of this issue. It’s faster and safer.

Can you review with your host, your install with the issue, that nothing is affected the referrer headers?

I’ve changed nothing there – are you saying that the hosting company has added/changed the header and it was compatible with V4.8.3 and it’s incompatible with V4.9?

I don’t think it’s a PHP version issue

I concur. I looked at the PHP manual and sprintf is in V5 upwards, and no mention of any change.

You may want to move to a host that offers PHP 7 regardless of the outcome of this issue.

I don’t own the site, I only maintain it technically; so that’s not an option.

Hi @rwall, Thanks for the update. I’m no pHp expert either! But just looking at the syntax of the infamous preg_match statement in the infamous line 1657, it is rather different to the preg_mayvh statements in the corresponding file in 4.8.3 (and indeed the other preg_match statements in the 4.9.0 file).
However if it is simply a version issue, I would have thought they would be more folks having the same problem. I will find some time to try a few things next week (hopefully)

@swansonphotos The complete error message I’m getting on a desktop browser for https://www.curtc.net is
Warning: preg_match(): Compilation failed: unrecognized character after (?< at offset 4 in /web1/userxxxxx/website/wp/wp-includes/wp-db.php on line 1657

Warning: Cannot modify header information – headers already sent by (output started at /web1/userxxxxx/website/wp/wp-includes/wp-db.php:1657) in /web1/userxxxxxx/website/wp/wp-content/plugins/sign-up-sheets-pro/lib/dls-session.php on line 105
xxxxx=user number

The second part varies in a way I don’t understand. For example on loading the login page I get

Warning: preg_match(): Compilation failed: unrecognized character after (?< at offset 4 in /web1/userxxxxxx/website/wp/wp-includes/wp-db.php on line 1657

Warning: Cannot modify header information – headers already sent by (output started at /web1/userxxxxx/website/wp/wp-includes/wp-db.php:1657) in /web1/userxxxxxx/website/wp/wp-includes/pluggable.php on line 1216

The
Warning: preg_match(): Compilation failed: unrecognized character after (?< at offset 4 in /web1/userxxxxxx/website/wp/wp-includes/wp-db.php on line 1657
appears common to all these error messages.

The relevant code in wp-db.php is (ending in 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 ) {
$pattern = ‘#^(?:\[)?(?<host>[0-9a-fA-F:]+)(?:\]:(?<port>[\d]+))?(?:/(?<socket>.+))?#’;
$is_ipv6 = true;
} else {
// We seem to be dealing with an IPv4 address.
$pattern = ‘#^(?<host>[^:/]*)(?::(?<port>[\d]+))?(?::(?<socket>.+))?#’;
}

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

Have gone back to 4.8.3 by replacing wp-admin and wp-includes directories along with wp-settings.php with the 4.8.3 equivalents. curtc.net now loads without warnings…

@crkm

Seems you have not wrapped your code in ticks. Could you please review how best to post code?

Please also stop using my @ as I have no more advise for your issue other than noted.

• This reply was modified 7 years, 3 months ago by Pioneer Web Design.
• This reply was modified 7 years, 3 months ago by Pioneer Web Design.

Thanks for your incredibly helpful reply
ps Please also stop using my @ as I have no idea who you are

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

@crkm

Have gone back to 4.8.3 by replacing wp-admin and wp-includes directories along with wp-settings.php with the 4.8.3 equivalents.

That’s exactly what I had to do.

I’m one of the moderators of the community forum over at https://www.openenergymonitor.org, and there I think I can rightly say that we go a little further in our efforts to help people who are struggling with something that is foreign to them, that they don’t fully understand.

I’m a Chartered Engineer, not a programmer. I know a little PHP, but I don’t have – and honestly I don’t have the time to acquire – the in-depth knowledge of WordPress that’s likely to be required to untangle this. Like you, I’ve been forced to take the safe (but I hope, temporary) option of reverting to the working version. What I don’t want to do is waste time and effort to convert to one of the other CMS offerings, so I’m hoping that someone else will see this and be able to help.

(And over at OEM, I just dive in and tidy up the posts for those who haven’t learned all the presentation tricks – and we don’t berate the poster. I quite often correct spelling and grammatical mistakes too – particularly, but not exclusively, for those whose first language is not English.)