Fix login error messages not displaying when redirect_to is present

[sacrefizz]

Summary

When a user is redirected to the PMPro login page with a redirect_to parameter (e.g., after trying to access a members-only page), failed login attempts do not show error messages on the PMPro login page.

Root cause

The redirect_to URL is passed directly to wp_login_form() via the redirect argument, which embeds it as a hidden redirect_to field in the form. When the form POSTs to wp-login.php, this redirect_to value interferes with the authentication flow, causing the error messages to be lost instead of being displayed on the PMPro login page.

Fix

This PR separates PMPro's redirect handling from wp_login_form()'s redirect_to hidden field:

• pmpro_login_form(): Extracts the redirect URL from the args before calling wp_login_form(), and adds it as a separate pmpro_redirect_to hidden field via the login_form_bottom filter.
• pmpro_login_redirect(): Checks pmpro_redirect_to first for successful login redirects.
• pmpro_login_failed(): Checks pmpro_redirect_to first when preserving the redirect URL across failed login attempts, with a fallback to redirect_to for backwards compatibility.

How to reproduce

1. Set up a PMPro login page and a members-only page
2. Visit the members-only page while logged out — you get redirected to /login/?redirect_to=%2Fmembers-page%2F
3. Enter an incorrect password
4. Before fix: No error message is displayed
5. After fix: The appropriate error message is displayed (e.g., "The password you entered for the username X is incorrect")

Test plan

• Visit a members-only page while logged out, verify redirect to login page
• Enter wrong password — error message should display
• Enter wrong username — error message should display
• Enter correct credentials — should redirect to the original members-only page
• Visit login page directly (no redirect_to) — verify login still works normally
• Test with login widget — verify widget login still works

[dparker1005]

Hi @sacrefizz, thank you for submitting this pull request.

I have followed the steps to reproduce this issue, but was not able to replicate the behavior. By default in PMPro, when a logged out user visits a restricted post, they will not automatically be redirected to the login page. They will instead be shown a message allowing them to either purchase access or log in.

When testing, I decided to log in via the restricted content message which did set the redirect_to parameter in the URL as you described. I then tested entering an incorrect password and the error message showed as expected.

Especially given the fact that your site is redirecting users away from restricted content, it sounds like your site may be running other plugins or custom code that may be contributing to this behavior. Can you please confirm whether you can replicate this issue with only PMPro active? If this issue requires other PMPro Add Ons to be active in order to replicate, can you please let me know which plugins are required so that we can test further?

[sacrefizz]

Thanks for testing @dparker1005!

The redirect in my case comes entirely from PMPro's own mechanism — no custom redirect code is involved.

The flow: A logged-out user visits /compte-dadherent/ (PMPro account page, ID 6128 with [pmpro_account]) → PMPro automatically redirects them to /login/?redirect_to=%2Fcompte-dadherent%2F (PMPro login page, ID 6135, using the pmpro/login-form block). When they enter an incorrect password, no error message is displayed.

The issue was severe enough that I had to write a workaround plugin that strips the redirect_to hidden field from the form via JavaScript and stores it in a cookie instead, then uses the login_redirect filter after successful authentication.

Could the difference be the block vs shortcode? I'm using PMPro 3.6 with the Gutenberg block. Could you confirm which version and which login method (block or shortcode) you tested with?

I'm happy to deactivate my workaround plugin and test with only PMPro active. I'll report back with the results.

[dparker1005]

Hi there @sacrefizz,

Thank you for clarify that the redirect occurred when trying to access the PMPro Account page. I was now able to replicate this redirect on my testing site; however when testing a login with an incorrect password, I am still seeing the error. I have tried using both the PMPro login page shortcode and block.

If you are able to replicate this behavior on your site with only PMPro active, or find any other information that may help us to replicate this behavior on our end, please let me know and we can take another look.

[flintfromthebasement]

PR: #3576 — Fix login error messages not displaying when redirect_to is present
sacrefizz → dev | 1 file, +37 -1
#3576

Summary
Correct root cause diagnosis and a clean fix. Separating PMPro's redirect tracking from wp_login_form()'s native redirect_to field is the right approach. The round-trip logic holds: failed login embeds the URL as a query param back to the PMPro login page, which re-injects it into the pmpro_redirect_to hidden field on re-render. Ready to merge with two minor items noted below.

Issues

• Minor includes/login.php:~20 (pmpro_login_redirect) — pmpro_redirect_to is accepted from $_REQUEST and overwrites $redirect_to without validating the host. WordPress core downstream uses wp_safe_redirect() which prevents the open redirect in practice, but the pmpro_login_redirect_url filter exposes the raw value to callers before that safety net kicks in. Defensive fix: wrap with wp_validate_redirect( $value, home_url() ) before assigning.

• Minor includes/login.php:~1095 (pmpro_login_failed) — The pmpro_redirect_to read applies wp_unslash(), but the old redirect_to fallback added two lines later does not. The pre-existing code didn't have it either, so this isn't a regression, but since you're touching this line, worth making consistent:

  $redirect_to = ( ! empty( $_REQUEST['redirect_to'] ) ) ? esc_url_raw( wp_unslash( $_REQUEST['redirect_to'] ) ) : '';

Looks Good

• The closure approach for login_form_bottom is correct — storing a reference to the closure and passing it to remove_filter() is exactly how anonymous filter cleanup works in PHP. No filter leakage between multiple pmpro_login_form() calls on the same page.
• unset( $args['redirect'] ) before passing to wp_login_form() is the cleanest way to prevent the hidden field collision without patching core behavior.
• Backwards compatibility preserved in pmpro_login_failed() via the redirect_to fallback.