crkm

@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 http://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 8 years, 6 months ago by crkm.
• This reply was modified 8 years, 6 months ago by crkm.

@rwall
I updated a site not hosted by Easily to WP 4.9…. no problem, no warnings. The other thing I noted is that all the results from the Google search you suggest contain …./web1/userxxxxx/website/… where the x’s are numbers (4 or 5). This format is the one used by Easily for hosting (my other sites use a different format). So it suggests (but not conclusively) that the websites suffering from this warning after the upgrade to WP 4.9 are from a particular host which brings me back to thinking it is a php version issue.
I suggest we turn our attention to our host!

@rwall
Thanks for the reply. I run and moderate a couple of websites and fully appreciate your comments. While not chartered I too am an Engineer and know what PHP is but little more.
To reiterate, upgrading to WP 4.9 broke (or at least severely impaired) one of the websites I look after. (I have not updated any of the other websites to WP 4.9.) In search of help, I ended up in this thread where you appear to have experienced the same problem, i.e. the warning with the reference to line 1657 in wp-db.php.
I (like you) have now downgraded back to WP 4.8.3 on the site I had upgraded to WP 4.9. The website is now working fine again.

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…

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)