[wp-trac] [WordPress Trac] #56850: PHP 8.1 deprecation notices from wp_signon() with default parameters (was: pluggable.php - Deprecated errors on PHP 8.1)

WordPress Trac noreply at wordpress.org
Wed Oct 19 22:50:35 UTC 2022


#56850: PHP 8.1 deprecation notices from wp_signon() with default parameters
------------------------------------+---------------------
 Reporter:  lenasterg               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  6.2
Component:  Login and Registration  |     Version:  6.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch php81         |     Focuses:
------------------------------------+---------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 6.2


Comment:

 Thanks for the ticket! I was able to reproduce the issue.

 * It looks like there are actually two deprecation notices here:
  * One from `preg_replace()` in `wp_strip_all_tags()` via
 `sanitize_user()` in `wp_authenticate()`:
 {{{
 Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of
 type array|string is deprecated
 }}}
  * One from `trim()` in `wp_authenticate()` itself:
 {{{
 Deprecated: trim(): Passing null to parameter #1 ($string) of type string
 is deprecated
 }}}
 * The `$credentials['user_login']` and `$credentials['user_password']`
 parameters are passed by reference to the `wp_authenticate` action, and
 this is where the are
 [https://www.php.net/manual/en/language.references.pass.php#124383 created
 as `null` if they don't exist].
 * Since the parameters are documented as strings in various places
 (`wp_authenticate` action, `secure_signon_cookie` filter,
 `wp_authenticate()` function, `authenticate` filter, etc.) is seems like a
 bug that they are created as `null` instead of an empty string.
 Documenting `null` as a possible value does not seem ideal, as it forces
 plugins to deal with the issue on their own instead of fixing it at the
 source.

 I believe the correct solution would be to create these parameters as an
 empty string instead, along the lines of similar fixes in [54351] and
 [54368]. See [attachment:"56850.diff"], which also includes a unit test.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56850#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list