This covers information about the password reset link process returning an invalid key error message upon completion of the password reset process (“Sorry, no password reset key was found”).
If the fix is all you need, the potential fix is at the link below. Note that it’s not confirmed as a solution as of yet, but as soon as it is, I’ll update this post.
During the transition in the password reset process in WP-Members, there have been a number of bug reports that have described this issue. Unfortunately, it has been something that has not been reproducible in development.
Based on the number of reported issues, that tells me that there definitely is something wrong, but it’s not something that affects all users.
I have spent considerable time comparing settings of various users looking for a common thread (such as a theme, plugin, etc) as well as running debug testing on various user sites who have reported it.
While I am still uncertain as to the exact cause, I have reached a point where I have a pretty good theory and have taken steps to update the plugin accordingly so as to fix this problem.
Based on site behavior, I believe the issue is something that occurs when multiple instances of “The Loop” are run on the site, or it there are multiple instances where WP’s “the_content” filter is run.
When the process runs, it checks the password reset key for validity. When it completes, it runs WP’s
reset_password() to update the password. At that point, the key is cleared.
My theory is that since this occurs within
the_content filter, if multiple instances of The Loop exist, or if multiple sections of the page run
the_content, or if there is simply a repeated process of running
the_content, the issue may be that this process is run multiple times in a single page load. If that’s the case, when the process is completed and the key is cleared, then the second run (or beyond) would result in an invalid key when it hits
check_password_reset_key() during the second load.
(NOTE: I’m not talking about actually loading the page more than once. That by itself would not be a problem. This is specifically assuming multiple runs of all sets of
the_content filters in a single page load.)
The (potential) solution
If my theory is correct, then moving the actually key validation and password update to an action pre-page load, and only handling the resulting content in
the_content filter should solve it.
The last action hook prior to loading the page is generally
template_redirect. This is actually the action hook that the plugin checks its actions, and the reason for that is that allows for anything hooked to that process to be able to know what page is being loaded. When we hook to
init, that’s unknown. Not that knowing the loaded page it is part of this – I merely mention it to note why that action is used and when.
The important part of that above paragraph is that since
template_redirect is the last action before headers are sent, and that’s where the WP-Members plugin checks what action is being run, and we need to know the password reset action is being run, we need to hook to
template_redirect at a later priority than the action check.
So the solution is presumed to be moving the password reset process into a separate function hooked to
template_redirect. Then we’ll store the result in a class variable to be picked up in
Install the beta release candidate to determine if this fix works for you:
Be sure to report results using the contact form. It doesn’t do me any good if people try the beta with the fix, find out it resolves the problem, but then don’t report that the fix worked for them.