Timeline for Correct method of redirecting user login
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 6, 2013 at 22:06 | comment | added | s_ha_dum | I don't disagree that the plugin should perhaps be tweaked, but I am not sure this is incorrect use of the hook. I'd have to analyze the code and make a judgement call. Consider though, that if it were to redirect from anywhere it could break anything "down line" of that point. You can't always preserve everything, and sometimes you don't even want to. | |
| Jun 6, 2013 at 21:46 | comment | added | Josh Levinson | Makes sense! My issue really boils down to how using this action hook to redirect the user prevents the wp_signon function from being used as it is designed. I understand that action hooks are meant to "do stuff"; I just feel that this action hook may be not well-suited to be used to redirect as it stops any ajax sign-ins from properly occurring. | |
| Jun 6, 2013 at 17:39 | comment | added | s_ha_dum | @JoshLevinson : see the edit. | |
| Jun 6, 2013 at 17:38 | history | edited | s_ha_dum | CC BY-SA 3.0 |
added 672 characters in body
|
| Jun 6, 2013 at 17:30 | comment | added | Josh Levinson | Hm. Interesting points, but it feels to me in this case that s2Member may be incorrect in redirecting from the wp_login hook. I feel this way because the action hook wp_login is called from wp_signon, which is supposed to return the WP_User object. Blocking the wp_signon function from it's designated functionality seems more than conflict to me, and more along the lines of doing it wrong. It'd be like me modifying the 'the_content' filter and not returning the content when I'm done with it. | |
| Jun 6, 2013 at 17:09 | history | answered | s_ha_dum | CC BY-SA 3.0 |