I'm creating a custom password reset page on a site, and am trying to leverage retrieve_password() to send the reset email. Upon sending the reset email, I'd like to wp_redirect the user back to the login page with a flash message telling them to check their email. Herein lies the problem:

If you take a look at the link above, you'll notice that Hookr's suggested usage of retrieve_password() has a check to see if the function exists yet, and if not includes wp-login.php, where the WordPress (core) defines that function. It would seem that my wp_loaded action that handles this process doesn't occur in a context with that file loaded, so I do need to include wp-login.php before I can use retrieve_password().

The problem is that wp-login.php automatically does some client rendering, which causes headers to be sent, preventing me from sending headers in the future. wp_redirect() relies on the usage of headers to work, and as such is breaking since it's called after wp-login.php is included.

It would seem I have a few options; namely:

  1. Wrap require_once 'wp-login.php in an output buffer to prevent rendering/headers
  2. Copy+Paste or rewrite retrieve_password() outside the context of wp-login.php, and reference my new version.
  3. your suggestion here?

None of these options seem too appealing to me. Using an output buffer seems like a bad practice, and I'm not entirely certain what all else will be run in the background when I do this. I'd prefer to leverage as much of WordPress' built-in password reset functionality as possible, and so I'm also hesitant to rewrite the retrieve_password() function.

I'm sure this has been done before. Does anyone have a suggestion here? Am I chasing a poor solution trying to rely on retrieve_password(), rather than just writing my own email logic?


The login page is a horrible mess mixing functions with output the way it does. It makes projects like your unnecessarily difficult. It is actually better now that is used to be.

You can cheat around the problem with output buffering:


Of course, the page still gets generated so it is consuming resources and not especially efficient, but you do get access to those functions. The downside-- potentially a huge downside-- is that that page does what it does in the background anyway. That could cause trouble if you aren't careful.

  • I'm only using it for password reset, so I don't really see this code being run too often. Resource efficiency shouldn't be a big concern. This is what I'm currently doing (option 1 in my question), but I was hoping to avoid this approach. I suppose not even wordpress is perfect ¯\_(ツ)_/¯ Dec 30 '15 at 13:55
  • I've never understood the structure of the login page. It is really pretty ridiculous.
    – s_ha_dum
    Dec 30 '15 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.