problem with wp

Discussion:

problem with wp_signon

Guus (IFS)

2014-05-04 08:18:38 UTC

Hi,

I am having a problem signing a user in with wp_signon. When calling it (before the headers have been sent) the first time the user appears not to be logged in when using is_user_logged_in. When going to another page the user is signed in however. Only the first page opened tells the users is signed in, which apparently somehow is the case.

Please advise,

Guus

Nikola Nikolov

2014-05-04 08:31:47 UTC

Permalink

I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.

I could be wrong though, so if someone else has a clue...

On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <

Post by Guus (IFS)
Hi,
I am having a problem signing a user in with wp_signon. When calling it
(before the headers have been sent) the first time the user appears not to
be logged in when using is_user_logged_in. When going to another page the
user is signed in however. Only the first page opened tells the users is
signed in, which apparently somehow is the case.
Please advise,
Guus
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Guus (IFS)

2014-05-04 10:30:45 UTC

Permalink

Thanks for your reply. Tried that and didn't work. I just found myself it's
a bug in is_user_logged_in().

Nicest work around I found is to call set_current_user() just after the
wp_signon(), of course if the user was really logged in. Answer is here:
http://blog.rhysgoodwin.com/programming/wordpress-wp_signon-current_user-is-not-populated/.

I guess it's time for the Wordpress team to fix that bug as it took me hours
and hours to figure this out. Didn't expect this type of bug in Wordpress.

Guys, please fix.

-----Original Message-----
From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] problem with wp_signon

I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.

I could be wrong though, so if someone else has a clue...

On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <

Jaime Martínez

2014-05-04 11:34:19 UTC

Permalink

Hi Guus,

You mind opening a Trac issue for this if it isn't already there on the system. Then it doens't gets lost here on the list and Trac is the place to open bugreports, right? Then the likelyhood of it being fixed will be bigger.
If you attach a possible patch, maybe even bigger. Thanks.

Greetz,

Jaime

Thanks for your reply. Tried that and didn't work. I just found myself it's a bug in is_user_logged_in().
Nicest work around I found is to call set_current_user() just after the wp_signon(), of course if the user was really logged in. Answer is here: http://blog.rhysgoodwin.com/programming/wordpress-wp_signon-current_user-is-not-populated/.
I guess it's time for the Wordpress team to fix that bug as it took me hours and hours to figure this out. Didn't expect this type of bug in Wordpress.
Guys, please fix.
-----Original Message----- From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
Subject: Re: [wp-hackers] problem with wp_signon
I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.
I could be wrong though, so if someone else has a clue...
On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <

_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Guus (IFS)

2014-05-04 13:15:33 UTC

Permalink

https://core.trac.wordpress.org/ticket/28116

-----Original Message-----
From: Jaime Martínez
Sent: Sunday, May 04, 2014 7:34 PM
To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] problem with wp_signon

Hi Guus,

You mind opening a Trac issue for this if it isn't already there on the
system. Then it doens't gets lost here on the list and Trac is the place to
open bugreports, right? Then the likelyhood of it being fixed will be
bigger.
If you attach a possible patch, maybe even bigger. Thanks.

Greetz,

Jaime

Post by Guus (IFS)
Thanks for your reply. Tried that and didn't work. I just found myself
it's a bug in is_user_logged_in().
Nicest work around I found is to call set_current_user() just after the
http://blog.rhysgoodwin.com/programming/wordpress-wp_signon-current_user-is-not-populated/.
I guess it's time for the Wordpress team to fix that bug as it took me
hours and hours to figure this out. Didn't expect this type of bug in
Wordpress.
Guys, please fix.
-----Original Message----- From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
Subject: Re: [wp-hackers] problem with wp_signon
I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.
I could be wrong though, so if someone else has a clue...
On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <

Otto

2014-05-04 19:39:31 UTC

Permalink

This isn't really a bug. I think you're just using the wrong function for
your purpose.

The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.

The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.

In your _my_user_login function, you call wp_signon totally unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.

-Otto

Post by Guus (IFS)
Thanks for your reply. Tried that and didn't work. I just found myself
it's a bug in is_user_logged_in().
Nicest work around I found is to call set_current_user() just after the
http://blog.rhysgoodwin.com/programming/wordpress-wp_
signon-current_user-is-not-populated/.
I guess it's time for the Wordpress team to fix that bug as it took me
hours and hours to figure this out. Didn't expect this type of bug in
Wordpress.
Guys, please fix.
-----Original Message----- From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
Subject: Re: [wp-hackers] problem with wp_signon
I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.
I could be wrong though, so if someone else has a clue...
On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <
Hi,

Post by Guus (IFS)
I am having a problem signing a user in with wp_signon. When calling it
(before the headers have been sent) the first time the user appears not to
be logged in when using is_user_logged_in. When going to another page the
user is signed in however. Only the first page opened tells the users is
signed in, which apparently somehow is the case.
Please advise,
Guus
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________

wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Guus (IFS)

2014-05-05 18:03:21 UTC

Permalink

Hi Nikola,

Thanks for explaining, but I tried redirecting after wp_signon and that
still didn't work.

And my problem is either there is a bug in is_user_logged_in() or the
documentation of either wp_signon() or is_user_logged_in() is wrong, at
least unclear,

Guus

-----Original Message-----
From: Nikola Nikolov
Sent: Monday, May 05, 2014 4:16 PM
To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] problem with wp_signon

If you look into wp-login.php, you'll see that after wp_signon() is called,
the user is redirected(if the credentials were correct) right away, which
basically loads another page and the cookie becomes available.
In general this is how cookies work :) If you set a cookie with PHP, it
will not be available in the same script execution, but in a following
one(since I assume PHP gets cookies data before/at the very beginning of
execution and doesn't modify it after setcookie() calls).

Slightly off-topic - whenever I need to log-in to a site without the
credentials(for instance when the admin hasn't given me access to the
dashboard, but wants me to fix a problem), I use a combination of
wp_set_current_user( $user->ID, $user->user_login );
wp_set_auth_cookie( $user->ID, true );
do_action( 'wp_login', $user->user_login, $user );

This immediately makes me seem logged-in(because of wp_set_current_user()
), but obviously doesn't make any security checks.

Well, I'm not sure how it was all meant to be, but to me it's pretty
confusing if I try to sign the user in with wp_signon() and then cannot
check later on in the code if the user is logged in with
is_user_logged_in(), especially finding that the user was actually logged
in with wp_signon() when going to another page (which was also confirmed
as
a user object was returned and not an error code.
It took me hours in actual time and weeks in lead time to finally find out
it doesn't work as I expected it to work.
-----Original Message----- From: Otto
Sent: Monday, May 05, 2014 3:39 AM
Subject: Re: [wp-hackers] problem with wp_signon
This isn't really a bug. I think you're just using the wrong function for
your purpose.
The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.
The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.
In your _my_user_login function, you call wp_signon totally unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.
-Otto
com
Thanks for your reply. Tried that and didn't work. I just found myself

it's a bug in is_user_logged_in().
Nicest work around I found is to call set_current_user() just after the
http://blog.rhysgoodwin.com/programming/wordpress-wp_
signon-current_user-is-not-populated/.
I guess it's time for the Wordpress team to fix that bug as it took me
hours and hours to figure this out. Didn't expect this type of bug in
Wordpress.
Guys, please fix.
-----Original Message----- From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
Subject: Re: [wp-hackers] problem with wp_signon
I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.
I could be wrong though, so if someone else has a clue...
On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <
Hi,

Guus (IFS)

2014-05-06 10:00:02 UTC

Permalink

I just called wp_signon() before the headers were sent as you can find
anywhere. Tried different places and result object was user, so user
supposedly logged in.

Then I called is_user_logged_in() in the template which returned false. When
clicking any menu item after, the user was logged in. I tried to call
header('Location: xxx') just after the wp_signon(), but that didn't work.

That's all I found and I found a similar issue described on the internet
http://wordpress.org/support/topic/is_user_logged_in-not-working-as-expected,
where I also found the solution/work-around with calling
wp_set_current_user() just after wp_signon(). And that worked straight away.

-----Original Message-----
From: Nikola Nikolov
Sent: Tuesday, May 06, 2014 2:22 AM
To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] problem with wp_signon

The thing is there shouldn't be a problem, since that's what is used in
WP-core to log users in from wp-login.php.. Can you post your code(to
gist.github.com or similar), so we can look at an example where this
occurs? If you can strip as much possible until you get code that can be
used to reproduce the issue, that will be pretty helpful as well.

Nikola

Post by Guus (IFS)
Hi Nikola,
Thanks for explaining, but I tried redirecting after wp_signon and that
still didn't work.
And my problem is either there is a bug in is_user_logged_in() or the
documentation of either wp_signon() or is_user_logged_in() is wrong, at
least unclear,
Guus
-----Original Message----- From: Nikola Nikolov
Sent: Monday, May 05, 2014 4:16 PM
Subject: Re: [wp-hackers] problem with wp_signon
If you look into wp-login.php, you'll see that after wp_signon() is called,
the user is redirected(if the credentials were correct) right away, which
basically loads another page and the cookie becomes available.
In general this is how cookies work :) If you set a cookie with PHP, it
will not be available in the same script execution, but in a following
one(since I assume PHP gets cookies data before/at the very beginning of
execution and doesn't modify it after setcookie() calls).
Slightly off-topic - whenever I need to log-in to a site without the
credentials(for instance when the admin hasn't given me access to the
dashboard, but wants me to fix a problem), I use a combination of
wp_set_current_user( $user->ID, $user->user_login );
wp_set_auth_cookie( $user->ID, true );
do_action( 'wp_login', $user->user_login, $user );
This immediately makes me seem logged-in(because of wp_set_current_user()
), but obviously doesn't make any security checks.
com
Well, I'm not sure how it was all meant to be, but to me it's pretty

confusing if I try to sign the user in with wp_signon() and then cannot
check later on in the code if the user is logged in with
is_user_logged_in(), especially finding that the user was actually logged
in with wp_signon() when going to another page (which was also confirmed
as
a user object was returned and not an error code.
It took me hours in actual time and weeks in lead time to finally find out
it doesn't work as I expected it to work.
-----Original Message----- From: Otto
Sent: Monday, May 05, 2014 3:39 AM
Subject: Re: [wp-hackers] problem with wp_signon
This isn't really a bug. I think you're just using the wrong function for
your purpose.
The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.
The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.
In your _my_user_login function, you call wp_signon totally
unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.
-Otto
com
Thanks for your reply. Tried that and didn't work. I just found myself

http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________

Nikola Nikolov

2014-05-06 10:32:11 UTC

Permalink

Hi Guus,

Here's what worked for me:

if ( isset( $_GET['login'] ) && ! is_user_logged_in() ) {
if ( ! is_wp_error( $result = wp_signon( array( 'user_login' => 'admin',
'user_password' => 'demo', 'rememberme' => true ) ) ) ) {
wp_redirect( remove_query_arg( 'login' ) );
exit;
} else {
var_dump( $result );
}
}

All I did was put that code this code in twentytwelve's functions.php and
it worked like a charm.

Again - there's no apparent reason for wp_signon() followed by
wp_redirect() (or similar) not to work - if it didn't, you'd know :)

To sum it up:

wp_signon() followed immediately by is_user_logged_in() or similar *will
not work*, due to the way that cookies are processed(the browser received
the cookie and will send it back to the server in the following requests).
wp_signon() followed by a page reload(so that the browser can make a new
request) *will work*.

Hope that makes sense,
Nikola

Post by Guus (IFS)
I just called wp_signon() before the headers were sent as you can find
anywhere. Tried different places and result object was user, so user
supposedly logged in.
Then I called is_user_logged_in() in the template which returned false.
When clicking any menu item after, the user was logged in. I tried to call
header('Location: xxx') just after the wp_signon(), but that didn't work.
That's all I found and I found a similar issue described on the internet
http://wordpress.org/support/topic/is_user_logged_in-not-
working-as-expected, where I also found the solution/work-around with
calling wp_set_current_user() just after wp_signon(). And that worked
straight away.
-----Original Message----- From: Nikola Nikolov
Sent: Tuesday, May 06, 2014 2:22 AM
Subject: Re: [wp-hackers] problem with wp_signon
The thing is there shouldn't be a problem, since that's what is used in
WP-core to log users in from wp-login.php.. Can you post your code(to
gist.github.com or similar), so we can look at an example where this
occurs? If you can strip as much possible until you get code that can be
used to reproduce the issue, that will be pretty helpful as well.
Nikola
com
Hi Nikola,

Post by Guus (IFS)
Thanks for explaining, but I tried redirecting after wp_signon and that
still didn't work.
And my problem is either there is a bug in is_user_logged_in() or the
documentation of either wp_signon() or is_user_logged_in() is wrong, at
least unclear,
Guus
-----Original Message----- From: Nikola Nikolov
Sent: Monday, May 05, 2014 4:16 PM
Subject: Re: [wp-hackers] problem with wp_signon
If you look into wp-login.php, you'll see that after wp_signon() is called,
the user is redirected(if the credentials were correct) right away, which
basically loads another page and the cookie becomes available.
In general this is how cookies work :) If you set a cookie with PHP, it
will not be available in the same script execution, but in a following
one(since I assume PHP gets cookies data before/at the very beginning of
execution and doesn't modify it after setcookie() calls).
Slightly off-topic - whenever I need to log-in to a site without the
credentials(for instance when the admin hasn't given me access to the
dashboard, but wants me to fix a problem), I use a combination of
wp_set_current_user( $user->ID, $user->user_login );
wp_set_auth_cookie( $user->ID, true );
do_action( 'wp_login', $user->user_login, $user );
This immediately makes me seem logged-in(because of wp_set_current_user()
), but obviously doesn't make any security checks.
com
Well, I'm not sure how it was all meant to be, but to me it's pretty

confusing if I try to sign the user in with wp_signon() and then cannot
check later on in the code if the user is logged in with
is_user_logged_in(), especially finding that the user was actually logged
in with wp_signon() when going to another page (which was also confirmed as
a user object was returned and not an error code.
It took me hours in actual time and weeks in lead time to finally find out
it doesn't work as I expected it to work.
-----Original Message----- From: Otto
Sent: Monday, May 05, 2014 3:39 AM
Subject: Re: [wp-hackers] problem with wp_signon
This isn't really a bug. I think you're just using the wrong function for
your purpose.
The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.
The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.
In your _my_user_login function, you call wp_signon totally
unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.
-Otto
com

Post by Guus (IFS)
Thanks for your reply. Tried that and didn't work. I just found myself

it's a bug in is_user_logged_in().

Post by Guus (IFS)
Nicest work around I found is to call set_current_user() just after the
http://blog.rhysgoodwin.com/programming/wordpress-wp_
signon-current_user-is-not-populated/.
I guess it's time for the Wordpress team to fix that bug as it took me
hours and hours to figure this out. Didn't expect this type of bug in
Wordpress.
Guys, please fix.
-----Original Message----- From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
Subject: Re: [wp-hackers] problem with wp_signon
I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.
I could be wrong though, so if someone else has a clue...
On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <
Hi,
I am having a problem signing a user in with wp_signon. When calling it

Post by Guus (IFS)
(before the headers have been sent) the first time the user appears not to
be logged in when using is_user_logged_in. When going to another page the
user is signed in however. Only the first page opened tells the users is
signed in, which apparently somehow is the case.
Please advise,
Guus
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list

Nikola Nikolov

2014-05-05 18:22:34 UTC

Permalink

The thing is there shouldn't be a problem, since that's what is used in
WP-core to log users in from wp-login.php.. Can you post your code(to
gist.github.com or similar), so we can look at an example where this
occurs? If you can strip as much possible until you get code that can be
used to reproduce the issue, that will be pretty helpful as well.

Nikola

confusing if I try to sign the user in with wp_signon() and then cannot
check later on in the code if the user is logged in with
is_user_logged_in(), especially finding that the user was actually logged
in with wp_signon() when going to another page (which was also confirmed
as
a user object was returned and not an error code.
It took me hours in actual time and weeks in lead time to finally find out
it doesn't work as I expected it to work.
-----Original Message----- From: Otto
Sent: Monday, May 05, 2014 3:39 AM
Subject: Re: [wp-hackers] problem with wp_signon
This isn't really a bug. I think you're just using the wrong function for
your purpose.
The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.
The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.
In your _my_user_login function, you call wp_signon totally unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.
-Otto
com
Thanks for your reply. Tried that and didn't work. I just found myself

Guus (IFS)

2014-05-05 04:49:53 UTC

Permalink

Well, I'm not sure how it was all meant to be, but to me it's pretty
confusing if I try to sign the user in with wp_signon() and then cannot
check later on in the code if the user is logged in with
is_user_logged_in(), especially finding that the user was actually logged in
with wp_signon() when going to another page (which was also confirmed as a
user object was returned and not an error code.

It took me hours in actual time and weeks in lead time to finally find out
it doesn't work as I expected it to work.

-----Original Message-----
From: Otto
Sent: Monday, May 05, 2014 3:39 AM
To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] problem with wp_signon

This isn't really a bug. I think you're just using the wrong function for
your purpose.

The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.

The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.

In your _my_user_login function, you call wp_signon totally unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.

-Otto

Post by Guus (IFS)
Thanks for your reply. Tried that and didn't work. I just found myself
it's a bug in is_user_logged_in().
Nicest work around I found is to call set_current_user() just after the
http://blog.rhysgoodwin.com/programming/wordpress-wp_
signon-current_user-is-not-populated/.
I guess it's time for the Wordpress team to fix that bug as it took me
hours and hours to figure this out. Didn't expect this type of bug in
Wordpress.
Guys, please fix.
-----Original Message----- From: Nikola Nikolov
Sent: Sunday, May 04, 2014 4:31 PM
Subject: Re: [wp-hackers] problem with wp_signon
I think the cookies are not set on the first load - so you'd have to
redirect them in order for WordPress to detect that the user is actually
logged-in.
I could be wrong though, so if someone else has a clue...
On Sun, May 4, 2014 at 11:18 AM, Guus (IFS) <
Hi,

Nikola Nikolov

2014-05-05 08:16:53 UTC

Permalink

If you look into wp-login.php, you'll see that after wp_signon() is called,
the user is redirected(if the credentials were correct) right away, which
basically loads another page and the cookie becomes available.
In general this is how cookies work :) If you set a cookie with PHP, it
will not be available in the same script execution, but in a following
one(since I assume PHP gets cookies data before/at the very beginning of
execution and doesn't modify it after setcookie() calls).

Slightly off-topic - whenever I need to log-in to a site without the
credentials(for instance when the admin hasn't given me access to the
dashboard, but wants me to fix a problem), I use a combination of
wp_set_current_user( $user->ID, $user->user_login );
wp_set_auth_cookie( $user->ID, true );
do_action( 'wp_login', $user->user_login, $user );

This immediately makes me seem logged-in(because of wp_set_current_user()
), but obviously doesn't make any security checks.

Well, I'm not sure how it was all meant to be, but to me it's pretty
confusing if I try to sign the user in with wp_signon() and then cannot
check later on in the code if the user is logged in with
is_user_logged_in(), especially finding that the user was actually logged
in with wp_signon() when going to another page (which was also confirmed as
a user object was returned and not an error code.
It took me hours in actual time and weeks in lead time to finally find out
it doesn't work as I expected it to work.
-----Original Message----- From: Otto
Sent: Monday, May 05, 2014 3:39 AM
Subject: Re: [wp-hackers] problem with wp_signon
This isn't really a bug. I think you're just using the wrong function for
your purpose.
The purpose of calling wp_signon is to validate credentials and then send
back appropriate authentication cookies to the visitor's browser. It
doesn't set the current user because it doesn't have to do that. Setting
the current user in wp_signon would serve no real purpose at this point in
the code.
The thing is, you don't need a username or password or anything else to set
the current user. Just call wp_set_current_user with the user's ID, and
bam, you're that user.
In your _my_user_login function, you call wp_signon totally unnecessarily.
You can just take the ID you got from the user you created in the function
before that and simple set the current user to that ID. The only thing
calling wp_signon will do here is send the auth cookie back to the browser.
-Otto
com
Thanks for your reply. Tried that and didn't work. I just found myself