[wp-trac] [WordPress Trac] #39385: Set $current_user global in wp_signon() after successful authentication

WordPress Trac noreply at wordpress.org
Tue Jul 12 16:37:04 UTC 2022

#39385: Set $current_user global in wp_signon() after successful authentication
 Reporter:  fjarrett                |       Owner:  (none)
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:  invalid
 Keywords:  close                   |     Focuses:
Changes (by hellofromTonya):

 * keywords:  needs-patch close => close
 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


 Hello 👋,

 Thank you for the ticket and everyone who has contributed.

 As previously state, it's not a defect, but rather by design.

 By design, `wp_signon()` does not handle setting the current user. It's
 job is to check the credentials and set the authentication cookies
 [https://core.trac.wordpress.org/ticket/28116#comment:4 as SergeyBiryukov
 notes here].

 #28116 / [40943] added a note into the function's DocBlock explaining why
 and providing further guidance if a custom requirement is needed:
  * Note: wp_signon() doesn't handle setting the current user. This means
 that if the
  * function is called before the {@see 'init'} hook is fired,
 is_user_logged_in() will
  * evaluate as false until that point. If is_user_logged_in() is needed in
  * with wp_signon(), wp_set_current_user() should be called explicitly.


 Why by design?

 After logging in, a redirect happens, which clears in-memory status
 (including the globals). After the redirect is done, the `$current_user`
 global is empty. It's populated after plugins are loaded, `setup_theme`,
 and `auth_cookie_valid` all run.

 Setting the current user within `wp_signon()` does not retain the current
 user in-memory once the login and redirect are done. Adding that to
 `wp_signon()` adds more tasks to the process without a major benefit for
 the majority users.

 While I understand the need, there are hooks available for customization.

 Since this is not a defect, but by design, and it's been 4 years since
 last activity, I'm closing this ticket. The classification of `invalid`
 seems harsh (sorry about that), but it's used to denote tickets that are
 not a defect/bug
 ([https://make.wordpress.org/core/handbook/contribute/trac/ see in the

 Thank you again everyone!

Ticket URL: <https://core.trac.wordpress.org/ticket/39385#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list