Why doesn't CP/WP remember me?

Expected behavior

when i check “Remember me” @ wp-login.php, it should remember me!

Current behavior

if i log in to the back-end and check “Remember me” everything works as expected AS LONG AS i don’t open any of the links from the back-end (the sidebar menu) in a new tab, in which case i may, or not (50/50), be asked to log in again

Steps to reproduce

  1. log in and select “Remember me”
  2. for example, start a new post, then open the “Pages” menu item in the sidebar in a new tab - when the new tab opens, i should be logged in but this is not always the case - if i log in again and switch back to the post tab and try to publish, i get that wonderfully descriptive message (/end sarcasm) “are you sure you want to do that” (or similar)

Additional comments

  • this issue is not specific to CP - i’ve had the problem with WP 5.5.1
  • i’ve had the issue with a default, vanilla theme
  • i’ve had the issue with all plugins disabled
  • i’ve had the same issue with a completely vanilla web browser profile (Firefox)
  • it’s not a cookie/storage issue, at least not at the browser level
  • i replaced the salts for the cookies in wp-config - no joy
  • possible clue: if i run a sitemap plugin, i get an error on the sitemap page (front-end) - i don’t recall what it is, but it’s a very common error
  • i’m starting to think this has something to do with the server config rather than WP/CP

my wp-config.php (sanitized)…

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', '<db_name>');

/** MySQL database username */
define('DB_USER', '<usr_name>');

/** MySQL database password */
define('DB_PASSWORD', '<db_pwd>>');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8mb4');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

/** disable WP CRON schedule (replaced with DirectAdmin CRON) */
//define('DISABLE_WP_CRON', true);

* Authentication Unique Keys and Salts.
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
* @since 2.6.0

define('AUTH_KEY',         '<hash>');
define('SECURE_AUTH_KEY',  '<hash>');
define('LOGGED_IN_KEY',    '<hash>');
define('NONCE_KEY',        '<hash>');
define('AUTH_SALT',        '<hash>');
define('SECURE_AUTH_SALT', '<hash>');
define('LOGGED_IN_SALT',   '<hash>');
define('NONCE_SALT',       '<hash>');


* WordPress Database Table prefix.
* You can have multiple installations in one database if you give each a unique
* prefix. Only numbers, letters, and underscores please!
$table_prefix  = '<db_prefix>';

* WordPress Localized Language, defaults to English.
* Change this to localize WordPress.  A corresponding MO file for the chosen
* language must be installed to wp-content/languages. For example, install
* de.mo to wp-content/languages and set WPLANG to 'de' to enable German
* language support.
define('WPLANG', '');

* Debugging - This will log all errors/warnings to debug.log in
* wp-content (if Apache does not have write permission, you may need to create
* the file first and set the appropriate permissions (i.e. use 666))
define('WP_DEBUG', false);
if ( WP_DEBUG ) {
    define('WP_DEBUG_LOG', false);
    define('WP_DEBUG_DISPLAY', false);                  /* must set 'WP_DISABLE_FATAL_ERROR_HANDLER', true if enabling this */
    define('WP_DISABLE_FATAL_ERROR_HANDLER', false);
    define('SCRIPT_DEBUG', false);
    ini_set('display_errors', 'Off');
    ini_set('error_log', dirname(__FILE__)  . '/~$7530_debug.log');

/** enable database repair and optimization from /wp-admin/maint/repair.php */
/** IMPORTANT: disable this when not in use as it is exposed to the public */
define('WP_ALLOW_REPAIR', false);

define('WP_HOME', 'https://<domain>');
define('WP_SITEURL', 'https://<domain>');

/** That's all, stop editing! Happy blogging. */

/** WordPress updates */
define('WP_AUTO_UPDATE_CORE', true);

/** Absolute path to the WordPress directory. */
if (!defined('ABSPATH'))
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

/** disable built-in file editor */
define('DISALLOW_FILE_EDIT', true);

* Cleanup Image Edits
* By default, WordPress creates a new set of images every time you edit an image
* and when you restore the original, it leaves all the edits on the server.
* Defining IMAGE_EDIT_OVERWRITE as true changes this behaviour. Only one set of
* image edits are ever created and when you restore the original, the edits are
* removed from the server.
define('IMAGE_EDIT_OVERWRITE', true);

 * plugin SNITCH - don't log internal requests

I’m unable to confirm this as a bug at the moment, but, wanted to say that this is a very well-written report!


If you happen to have a GitHub account, reports of this detail are extremely helpful and highly appreciated. Here’s the repository where ClassicPress is actively developed, if you’re interested.





You. Are. Awesome.


This is almost certainly a server config issue, not a bug with ClassicPress itself, which means the support forum is the right place for this issue. We can’t do much with a ClassicPress bug report until there is a clear set of steps to reproduce the bug from a fresh installation, either on any server or on a specific server environment (in which case explaining how to set up that server environment should be part of the bug report).

There was a bit more discussion on the GitHub issue. Key points were that this isn’t really the “remember me” checkbox that is malfunctioning, but rather the session functionality in general, and this partial list of PHP settings active on this server:

session.use_cookies = 1
session.cookie_secure = 1
session.use_only_cookies = 1
session.cookie_lifetime = 0
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

I just checked a server of mine and the only two differences I see are the following:

session.gc_probability = 0
session.cookie_secure = 0

My guess is those settings are also a dead-end though: WP and CP do not use the default PHP session mechanism.

the issue with not being able to stay logged on coincided with a problem i had with the exim mail queue where mails wasn’t being delivered - KnownHost hosts my managed VPS and they seem like very capable people

I doubt that specific issue is related, but as a next step I would contact KnownHost and tell them what is broken (or point them to this thread). Also, I used to live about 2 blocks away from one of their offices and I think I met a couple of them at a conference once.