• I am executing “is_user_logged_in” immediately after “wp_signon” and it returns nothing; no true, no false, no nothing. The “wp_signon” works beautifully. The user IS actually signed on. I tested thoroughly to make sure. What am I missing? Do I need to run something in order to update WPs knowledge of the newly signed on individual?

Viewing 15 replies - 1 through 15 (of 16 total)
  • Same here….what’s going on!?

    Someone from wordpress please look into this! Like we said, the user logs in fine, but is_user_logged_in doesn’t seem to be aware of this. However, wh

    $Login = wp_signon( $creds, false );
    if (is_wp_error($Login)) {
    $LoginErrorMessage = ‘Unknown username or password!’;
    $loginError = true;
    } else {
    $loginError = false;
    $LoginErrorMessage = ‘We are logged in!’;
    }
    }

    if ( is_user_logged_in() ) {
    //user is logged in
    } else {
    //user is not logged in
    }
    echo $LoginErrorMessage; //shows the “we are logged in” message, but doesn’t process the is user logged in stuff

    also, doing a var_dump of $Login shows me the full object….PLEAAAAAAAAAASE HELP

    Just ran into trouble with is_user_logged_in also. I finally got it to work, but in reverse:

    if (!is_user_logged_in()) {
    	// user is logged in
    } else {
    	// user is not logged in
    }

    Anybody else run into this too?

    I’m having the same problem. I’ve dug into the underlying code of is_user_logged_in() and found that the inner call to wp_parse_auth_cookie() returns false. A var_dump($_COOKIE) reveals that there’s actually no cookies named anything like what wp_parse_auth_cookie() is looking for.

    You could almost come to the obvious conclusion that I can’t be logged in, haven’t it been for the utter inexplicable fact that I’m viewing the WordPress Dashboard, logged in as the administrator (or any other user, for that matter) in the same browser and session as the one where is_user_logged_in() returns false.

    After digging through my cookies with Firecookie I’ve found that after logging in, I got a few cookies named wordpress_logged_in_237312a047c89340145b05ba23e10dd3 that had the Path set to //. Removing the last / from the WordPress settings (that are reflected in the WP_HOME constant and bloginfo('home')) seems to have fixed the issue.

    Seeing the same problem in MU 2.9.2 ??

    Oh nevermind, mine was a domain mapping cookie issue. Now working fine.

    Just had this problem whilst working with addon domains. Always good to check the ‘siteurl’ in the ‘wp-options’ table in the database for anyone else still struggling with this. Had the sub-directory instead on the domain’s url in there. Changed it to the domain and that fixed my problem.

    Benedicte Raae

    (@benedicteraae)

    I have the same problem as the first question, anyone found a solution?

    OS1

    (@os1)

    Yes, I am. Just posted another thread on the forum but looking how long this issue has been around I don’t think it’s going to get sorted. In my case it appears that the global $current_user is being wiped. The genuine wp-login.php must be doing something extra to make the user login “stick” but the code is somewhat intractable! If I login using the wp-login form everything is fine, but things stop working if you use the API. It looks like the API is incomplete or an extra function call is required to make the login “stick”.

    Crazy that no one has posted a suitable solution to this.
    In my case (as I suspect it is for others following a successful wp_signon ) failure of is_user_logged_in() isn’t the issue, as much as
    the subsequent failure of $current_user->VALUES;

    Can Anyone out there provide a little insight?

    Many thanks Rhys. This is a more elegant solution to mine, which basically is not really very elegant at all but at least allowed logins and, as tjmcd pointed, out access to the global $current_user!

    I even raised a ticket on this, Ticket #15344 <https://core.trac.www.ads-software.com/ticket/15344&gt;, but it got closed as invalid. I think the issue got lost in my attempts to explain it! The reviewer appeared to think I was reporting an issue in my code rather than WordPress. However, the tests I did using file writes, which I explain at the bottom just before it was closed, do seem to backup my initial observations that the path of execution is being sent right back to index.php, due to calls wp_redirect() and therefore data is being lost. The observations could easily be indicative of something completely different but they do stand.

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘is_user_logged_in not working as expected’ is closed to new replies.