Ticket #7002 (closed defect (bug): fixed)
Can't control where a user redirects to when they log in
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 2.6.2 |
| Component: | General | Version: | |
| Severity: | normal | Keywords: | has-patch needs-testing |
| Cc: |
Description
The 'login' case in wp-login FIRST sets $redirect_to THEN runs wp_signon(). If we switch that, a plugin could hook into wp_signon's wp_login hook, and set $_REQUESTredirect_to? based on user type, capabilities, name, etc. It would be nice, and there is no downside that I see.
Attachments
Change History
- Status changed from new to closed
- Resolution set to fixed
comment:5
AaronCampbell — 3 years ago
- Status changed from closed to reopened
- Resolution fixed deleted
- Milestone changed from 2.6 to 2.6.2
- Owner changed from anonymous to ryan
- Status changed from reopened to new
How about a login_redirect filter called after wp_login(). Altering the redirect before login can mess up the SSL detection stuff. See patch.
comment:8
AaronCampbell — 3 years ago
That's fine. I don't think we really need to pass $_REQUEST['redirect_to'] since the only difference would be https vs http right? I would be ok with this:
$redirect_to = apply_filters('login_redirect', $redirect_to, $user);
However, extra data doesn't hurt I suppose. Also, in the 2.6 branch if $_REQUEST['redirect_to'] is set then $_REQUEST['redirect_to'] and $redirect_to are identical.
- Status changed from new to closed
- Resolution set to fixed
comment:10
ryan — 3 years ago
comment:11
ryan — 3 years ago
Went ahead and passed redirect_to from the request just in case someone needs to know if it was set or not.
comment:12
AaronCampbell — 3 years ago
Since it's a super-global, can't you just check that with $_REQUEST['redirect_to'] inside your function? Again, it doesn't matter to me if you add extra in there.
Thanks for handling it.

