🇺🇸United States @agileadam

Here's another workaround. It doesn't seem to break anything. The result is a "Search..." placeholder in the empty box if there is no value, and a "Search..." placeholder at the end of any existing choices if there are any.

1) Set your Choices configuration as follows:

{
    "removeItemButton": true,
    "placeholder": true,
    "placeholderValue": "Search..."
}

2) Use hook_form_alter or hook_form_FORM_ID_alter to unset the _none option:

/**
 * Implements hook_form_alter().
 */
function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if ($form_id == 'node_mycontenttype_edit_form') {
    unset($form['field_languages_spoken']['widget']['#options']['_none']);
  }
}

While it's not a fix, I find that adding this configuration option makes it easy for the user to remove the "-None-" value:

{
    "removeItemButton": true
}

NOTE: If you leave the "-None-" option in place and choose another option (assuming allow multiple values), the "-None-" value won't get saved to the entity. Next time you edit the entity the "-None-" option won't show.

I'm happy to report: gapple's work in 🐛 PL token won't start new session if old session expired from DB Fixed fixed this issue! I look forward to being able to see this on a tagged release.
Thank you, gapple!

PS: / and /home are both working. I'm not sure what was going on. I have rebooted my machine, which recycled all of my ddev instances. Perhaps there was something funky going on with xdebug. Who knows! \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent is being called on every page load. Phew!

Brilliant! This fixes my issue 💬 User appears logged out until clicking Login link Fixed .

Last post for now... I figure more info is better than less. It seems like this problem is specific to my Drupal front page.

My "Default front page" setting points to a `/home` node (literally just a contentless basic page node; all content placed via blocks for this particular path).

• If I delete the session from the DB then visit https://mysite.com/home I get the authenticated experience
• If I delete the session from the DB then visit https://mysite.com/any-other-page-here I get the authenticated experience
• If I delete the session from the DB then visit https://mysite.com I get the anonymous experience. Refresh and then I see logged in experience.

Caching-related?

Might this be causing the browser cookie to hang around longer than the session in the DB?
I could see someone leaving work on a Friday (browser stays open), then coming back to their desk on Monday and refreshing the page. \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent would still think there is a session (hasSession would see the SSESS cookie) but garbage collection on the server would've removed the session from the DB.

    # Set session lifetime (in seconds), i.e. the time from the user's last
    # visit to the active session may be deleted by the session garbage
    # collector. When a session is deleted, authenticated users are logged out,
    # and the contents of the user's $_SESSION variable is discarded.
    # @default 200000
    gc_maxlifetime: 200000

    # Set session cookie lifetime (in seconds), i.e. the time from the session
    # is created to the cookie expires, i.e. when the browser is expected to
    # discard the cookie. The value 0 means "until the browser is closed".
    # @default 2000000
    cookie_lifetime: 0

Another piece of info: It seems like the culprit, at least for my site, is when there is a SSESS Drupal cookie in the browser, but the session no longer exists in Drupal's sessions table. If I remove the session from the DB and remove the browser's session cookie, everything works as expected (no matter what I do I end up logged back in immediately).

If I leave the browser SSESS session cookie in place and the session is removed from the DB, it takes multiple page refreshes for the user to be logged in.

The associated code in \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent is:

if (!$this->sessionConfiguration->hasSession($request)) {

So, what I'm wondering is... is it normal for a Drupal session record (in the DB) to go away (be removed from the db) before a user's browser session cookie expires? Is there something weird with my configuration maybe?

I can simulate the Drupal session expiring by deleting the Drupal session from the DB.
I recognize this isn't a real world series of events, but it is a reliable way to replicate the experience.

Pattern 1:
- I log in with "Remember me" checked
- I see in the database that I get a Drupal session and a persistent login token
- I load the homepage
- I manually delete the corresponding row in the DB session table
- I click the reload button in my browser (or hit ⌘R) or I click into the address bar and hit ENTER (same result either way)
- The page loads and I appear logged out (no "My Account" link, "Log in" link instead of "Log out" etc.)
- I reload the page again or click an internal link
- The page loads and I appear logged in now

This is the issue. People will go away for a while (days?) and come back to the site from the same computer. They then try to visit the site or refresh it if it's already open, and they appear to be logged out. As soon as they click the "Log in" link (or any other link, or refresh again) they'll be logged in then.

Pattern 2:
- I log in with "Remember me" checked
- I see in the database that I get a Drupal session and a persistent login token
- I load the homepage
- I manually delete the corresponding row in the DB session table
- I click any internal link on the page
- The page loads and I appear logged in immediately

QUESTION: What is different about clicking a link vs reloading/visiting the page?
The user_login_finalize() call in \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent doesn't execute the first time I reload/revisit the page. It does execute immediately if I click a link.

agileadam → created an issue.

agileadam → created an issue.