Users cannot log in if Password Compatibility module is not enabled

I am updating (1) in the proposed resolution: make it earlier on the page.

@benjifisher, pinged me in Slack about this. I can confirm the problem using the steps to reproduce in the issue summary.

Even though there is a workaround (using a one time login link) and there is no data loss I am changing to Critical, this should be done before 10.1 is released.

Talked to catch, who pointed out that there is update_free_access and drush for situations where you can't login. and moving back to Major.

I have done #2, updated the CR with the data from the Q and A section of the module doc page. I think that section can be removed from the docs page. For the CR, I moved the phpass section to the top of the API section and added formatting. I was going to add text to strongly suggest reading the CR but it just became too late.

I updated the release notes to encourage reading the change record, but not as suggested in #1. Is it sufficient?

@quietone:

I fixed a broken link in the release notes, and I formatted the Q&A section of the module docs using <h3> tags.

I think we still need to do more in the release notes. If I am a site administrator who does not read instructions carefully, and find that I cannot log into my site, then I need something in the release notes that says, "If you cannot log in, then READ THIS." It should go on to tell me how I can install the module even though I cannot log in.

I think that a separate <h3> near the top of the release notes, as I suggested in #1 of the proposed resolution, is the best way to help administrators in this situation. It should include something like the unordered list (bullet points) at the start of the proposed resolution.

Thanks for turning the "API deprecations and behavior changes" section into a list. The previous formatting did not make it clear where one point finished and another started.

I think I should pay some more attention to the text I added to the module doc page. I will try to do that in the next few days.

Oops. And I usually check links. Thanks for the fix.

I have added the module docs to the parent guide and added a section 'if you can not log in' to the change record. While not being to log in is disconcerting, getting a one-time login link is common practice. So, I don't think a new section in the release notes is needed.

MR 3991 implements (3) and (4) from the proposed resolution. I have not yet updated the text on the module doc page.

Most of the new text on the module's help page comes from the online documentation page. The paragraph at the end is new:

Passwords created before Drupal 10.1.0 will not work unless they are used at least once while this module is installed. Make sure that you can log in before uninstalling this module.

I hope that gets the point across. While the module is installed, legacy passwords will work. When the module is not installed, legacy passwords will work if they have been used while the module was installed.

I made one change to the existing text on the help page: I replaced "user entities" with "user accounts". I made the same change in the .info.yml file. (That text appears on /admin/modules.)

@benjifisher thank you so much for pointing this out. I was considering upgrading a site to 10.1 that will launch end of June and this made me pause more.

@rkoller left some comments and I chimed in but would refer to his expertise on the wording.

@smustgrave:

Thanks for updating the issue status. I did not notice the comments on the MR.

I updated 10.1.x to 10.1.0 in the MR and in the issue summary. I disagree with the other suggestions on the MR. Back to NR.

Changes look good.

I added 📌 Add counts of legacy password hashes Active for Part 5 of the proposed resolution.

This looks like a good improvement and it should get in before 10.1.0 - committed/pushed to 11.x and cherry-picked to 10.1.x, thanks!

Automatically closed - issue fixed for 2 weeks with no activity.