send password reset token in password recovery email

The language keys for the forgot password email are as follows. Only reason for the password to be missing is somehow Joomlas API to generate a password didn't return a password or problem in the language string. The email body uses sprintf as it's an old email so the third %s would be the password.

Subject: UE_NEWPASS_SUB
Body: UE_NEWPASS_MSG

As for the sent password not working if you've any custom behavior acting on onBeforeUserUpdate or onAfterUserUpdate it's possible the password is being wiped out during storage of the new password if you're not careful.

This happening randomly suggests there's problem a configured behavior causing a conflict. If possible try to find something in common between the users that forgot login fails on.

All I can say about testing results is that you don't have over 25,000 test cases (site members) like I do.

I've 4 test installs. 1 from our GIT. 1 as regular install. 1 is Joomla 3. 1 is Joomla 4. All 4 have over 1 million users. We're consistently testing CB against sites larger than 99% of our userbase. I don't think the number of users is relevant here. I think there's just a conflict of some kind happening.

In the ongoing saga of password reset not working and along the lines of investigating onBeforeUserUpdate/onBeforeUpdateUser-triggered Auto Actions interfering with it, WE ARE STILL SEEING THIS PROBLEM QUITE FREQUENTLY.

When a user requests a password reset, which event is triggered when the password is actually modified with a temporary password in the user's profile?

• onBeforeUserUpdate
• onBeforeUpdateUser
• onAfterUserUpdate
• onAfterUpdateUser
• onBeforeNewPassword
• onNewPassword
• onStartNewPassword

Our current Auto Actions that trigger on profile saving all trigger on both the UserUpdate (front end) and UpdateUser (back end) events, some Before, some After. I am trying to ascertain whether if we were to omit the UpdateUser (back end) events it would that alleviate the issue.

Kyle, can you elaborate on this?

Thanks,
Bruce

When a user requests a password reset, which event is triggered when the password is actually modified with a temporary password in the user's profile?
onBeforeUserUpdate
onBeforeUpdateUser
onAfterUserUpdate
onAfterUpdateUser
onBeforeNewPassword
onNewPassword
onStartNewPassword

The following triggers will be fired during forgot login for password.

onStartNewPassword
onBeforeNewPassword
onNewPassword
onAfterPasswordReminder
onBeforeUserUpdate
onAfterUserUpdate

Our current Auto Actions that trigger on profile saving all trigger on both the UserUpdate (front end) and UpdateUser (back end) events, some Before, some After. I am trying to ascertain whether if we were to omit the UpdateUser (back end) events it would that alleviate the issue.

Backend triggers aren't used here so it shouldn't matter. There's nothing I can suggest without a reliable way to reproduce this. I've yet to see any issues with forgot login in my tests. If you can find a way to reliably cause this problem over and over we can investigate further to see what's going on.

It's definitely not universal, nor does it happen to the same user every time. But it does happen quite a lot. So I am leaning toward your theory that it's some Auto Action interfering with the process. I don't understand the innards of how Auto Actions actually work or what to look for in them that could be at fault. But for instance, one thing we looked into earlier was that all onBeforeUserUpdate (et al) triggered AAs do, in fact, save directly. If there was a way to capture the sequence of all AAs occurring as a result of one of those triggers following a onStartNewPassword event, that would be super helpful. But I don't know how to do that or if it's even possible.

Your account is still enabled on the site if you want to poke around.

Saving directly will push data directly to the database, which is a good thing the majority of the time as it prevents any tampering with the user object. It's also entirely possible it's a 3rd party User or System plugin in Extensions > Plugins acting on Joomla user store behavior, but it's probably more likely something configured somewhere in CB. Without a reliable way to reproduce the problem I just don't have anything further I can suggest. In the future CBs forgot login won't exist as we'll just use Joomlas login module and forgot login page; specifically this is happening in CB 3.x, but might be backported to CB 2.x.