Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/peoplesofthesalmon/public_html/wp-includes/block-supports/layout.php on line 167

[oneearth27]

Hi,

Running WP 5.9 and upon visiting the website, am now getting several repetitions of the same message:

Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/peoplesofthesalmon/public_html/wp-includes/block-supports/layout.php on line 167

Also in the dashboard, there are some repetitions of the same message (the first part of the message seems to be blocked by the black left column):

null to parameter #1 ($string) of type string is deprecated in /home/peoplesofthesalmon/public_html/wp-includes/formatting.php on line 2761

You can reproduce the problem when you visit
​https://peoplesofthesalmon.org

The problem occurs even when all the plugins are deactivated. The default 2022 theme is being used.

It may be related to some changes I made to the server when I switched from php8.1-fpm port connection to Unix socket connection. The website is currently using a Unix socket. I am running Debian 10, using Virtualmin 6.17 as a control panel, with nginx 1.21, with PHP7.1, 7.3, 8.1 available for use. The peoplesofthesalmon.org is running on PHP8.1.

Initially the Unix socket connection didn't work and the Unix socket ownership would switch back to root after a systemctl restart php8.1-fpm.

So I added the nginx owner, www-data, in the /usr/lib/systemd/system/php8.1-fpm.service under the [Service] section, adding both User=www-data and Group=www-data.

I also had to change the owner of the /var/log/php8.1-fpm.log from root to www-data in order to get the website to show.

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the report.

WordPress core is not fully compatible with PHP 8.1 yet, there are still some deprecation notices. If you need a workaround, I would suggest switching to PHP 8.0 for now.

You can find more details in this post: ​WordPress 5.9 and PHP 8.0-8.1.

Fixes PHP 8.1 notices on the login screen caused by passing null values to wp_authenticate().

Currently, user_login and user_password are set by a side-effect of this line ​https://github.com/WordPress/wordpress-develop/blob/793fa4185d6512967e557eed5ac9c419176d2a28/src/wp-includes/user.php#L67
See ​https://3v4l.org/8JMRM for an example.

I used a simple empty() check which matches the behaviour of functions like ​`wp_authenticate_username_password()` which are hooked into the authenticate filter.

Trac ticket: https://core.trac.wordpress.org/ticket/55119

[ramonopoly]

Running WP 5.9 and upon visiting the website, am now getting several repetitions of the same message:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/peoplesofthesalmon/public_html/wp-includes/block-supports/layout.php on line 167

I think this has already been addressed in April, 2022 (this year) in the follow PR:

​https://github.com/WordPress/gutenberg/pull/39927

And the fix made it to WordPress 6.0

https://core.trac.wordpress.org/browser/tags/6.0/src/wp-includes/block-supports/layout.php#L180

Thanks for the PR! Merged in r55301.

[hellofromTonya]

Running WP 5.9 and upon visiting the website, am now getting several repetitions of the same message:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/peoplesofthesalmon/public_html/wp-includes/block-supports/layout.php on line 167

As @ramonopoly noted, this was fixed via [53420] / #55567, which included ​Gutenberg PR 39927.

[hellofromTonya]

The title of this ticket has been fixed. But the description has 2 different deprecations, which may not be related to one another:

Also in the dashboard, there are some repetitions of the same message (the first part of the message seems to be blocked by the black left column):
null to parameter #1 ($string) of type string is deprecated in /home/peoplesofthesalmon/public_html/wp-includes/formatting.php on line 2761

Hmm, I'm not able to reproduce these null to non-nullable deprecations with this testing environment:

• Localhost: Docker with wp-env
• PHP: 8.1
• WordPress: 6.2
• Theme: Twenty-twentytwo TT2
• Plugins: none
• Content: default fresh install
• Testing constants set wp-config.php:

  define( 'WP_DEBUG', true );
  define( 'WP_DEBUG_LOG', true );
  define( 'WP_DEBUG_DISPLAY', true );
  define( 'SCRIPT_DEBUG', true );
  define( 'WP_ENVIRONMENT_TYPE', 'local' );
  

I'm curious if the null to non-nullable has already been resolved indirectly by a fix that then invoked one of the formatting functions. To further investigate, more information is needed from @oneearth27.

@oneearth27 you noted:

The problem occurs even when all the plugins are deactivated. The default 2022 theme is being used.

By "problem occurs", does this apply to the null to parameter #1 ($string) of type string is deprecated in formatting.php? In other words with all plugins deactivated and using 2022 (TT2) theme, do you still get these specific deprecations in your server logs?

If yes:

• Does it happen on specific webpages, only in the admin or front-end, or all the time?
• Does it happen on WordPress 6.x, such as the latest 6.2?

Any additional information you can provide could help contributors investigate, including steps of how to reproduce.

[hellofromTonya]

Given no response to the 2nd part, I'll close this ticket as fixed in WP 6.0 by [53420] / #55567.

If the 2nd deprecation is not solved, please reopen and provide the requested information.

[SergeyBiryukov]

Replying to hellofromTonya:

I'm curious if the null to non-nullable has already been resolved indirectly by a fix that then invoked one of the formatting functions.

Yes, this notice appears to come from untrailingslashit() called on a null value.

That would be a duplicate of #54997. The only known instance in core was resolved in [54349] and [54351] / #55967.