If you will work with sessions, then init this at first in your plugin, theme. add_action( ‘init’, ‘my_start_session’ ); function my_start_session() { if ( session_id() ) return; @session_cache_limiter(‘private, must-revalidate’); //private_no_expire @session_cache_expire(0); @session_start(); } Alternative use the library from Eric Mann: WP Session Manager, also his tutorial.
It finally hit me that javascript would be behind the interim login modal behavior, and that gave me a new direction in my search. I have disabled the new login popups by adding the following to my theme’s functions.php file: // Disable login modals introduced in WordPress 3.6 remove_action( ‘admin_enqueue_scripts’, ‘wp_auth_check_load’ ); If anyone’s interested … Read more
This has very little to do with wordpress, but if this answer will help eliminate the usage of session, it might be worth it…. Sessions are stored on the hard disk of the server. This is problematic in a shared hosting scenarion because the session directory is most likely readable and writable by all process … Read more
Here (with some trepidation) is a sketch of a use-once link solution that might be safeish enough if one can depend on the ip being fairly constant (at least in the short-term) to the phone, using a query var and a transient based on $_SERVER[‘REMOTE_ADDR’], though as @Wyck and @G. M. say, any such backdoor … Read more
Transients are just database keys that expire. It’s like telling WordPress you want it to remember a certain piece of information, but for a limited time. In general, transients are accessible to PHP through any request. But since they’re server-side, transients are only exposed to front-end users if you as the developer expose them. A … Read more
Use wp_logout(). It calls wp_clear_auth_cookie() and invalidates the current log-in information immediately. Sample code, not tested: add_action( ‘init’, ‘log_out_banned_user’ ); function log_out_banned_user() { if ( ! is_user_logged_in() ) return; $user = wp_get_current_user(); if ( ! get_user_option( ‘rc_banned’, $user->ID, false ) ) return; wp_logout(); wp_redirect( home_url( “https://wordpress.stackexchange.com/” ) ); exit; }
OK, simple solution after digging in the WordPress code. // get all sessions for user with ID $user_id $sessions = WP_Session_Tokens::get_instance($user_id); // we have got the sessions, destroy them all! $sessions->destroy_all(); This will log the user with ID $user_id out of WordPress. Use case: My use case for this is when a user is approved … Read more
Your problem is that you call wp_logout_url immediately after wp_set_auth_cookie. wp_set_auth_cookie() does some setcookie() calls. Unfortunately setcookie doesn’t make the new value available instantly in the PHP global $_COOKIE. It must be set through a new HTTP Request first. wp_logout_url() (via wp_nonce_url > wp_create_nonce > wp_get_session_token > wp_parse_auth_cookie) fetches $_COOKIE[LOGGED_IN_COOKIE] in order to create a … Read more
I’ll skip steps related to sharing DB and sharing users data and meta, based on assumption that you’ve done it correctly. Let’s concentrate on wp-config.php of both sites. These are defines that MUST BE IDENTICAL for both sites: define(‘COOKIE_DOMAIN’, ‘.domain.com’); // your main domain define(‘COOKIEPATH’, “https://wordpress.stackexchange.com/”); define(‘COOKIEHASH’, md5(‘domain.com’)); // notice absence of a ‘.’ in … Read more
Short introduction After quick look inside WP source code, I think I’ve found solution… WordPress uses two functions to set and parse auth cookies: wp_generate_auth_cookie wp_parse_auth_cookie There is a filter in wp_generate_auth_cookie called auth_cookie which you probably could use to change the contents of cookie, but there is no filter inside wp_parse_auth_cookie, but… Both of … Read more