Home › Forums › Community Forum › s2Member code problem causes conflict
Tagged: action hook, conflict, plugin, redirect
This topic contains 6 replies, has 2 voices. Last updated by Bruce 3 years, 7 months ago.
Topic Author | Topic |
---|---|
Posted: Thursday Jun 6th, 2013 at 11:58 am #51535 | |
|
|
Please refer to this thread – http://wordpress.org/support/topic/experiencing-an-error?replies=28#post-4278240
Meanwhile….
Back to Modal Login… For a fix…I believe it is on the end of s2Member – maybe using the login_redirect filter INSTEAD of the wp_login hook. |
List Of Topic Replies
Author | Replies |
---|---|
Author | Replies |
Posted: Friday Jun 7th, 2013 at 7:11 am #51595 | |
|
|
Thank you for reporting this important issue.I’ll send this to our development team for their thoughts. |
|
Posted: Monday Jun 10th, 2013 at 11:59 am #51716 | |
|
|
I know it’s been over a weekend, but I believe this to be a significant issue with the way s2Member is set up. Is there any new information on this? |
|
Posted: Monday Jun 10th, 2013 at 12:20 pm #51718 | |
|
|
I have made a few changes to s2Member to fit what I believe is the most appropriate place to redirect a logged in user. The first step was changing the logic from hooking into wp_login to filtering the login_redirect. Since s2Member removes all filters on login_redirect, I also had to modify login-redirects-r.inc.php to add the filter back after all others are removed. The altered login_redirect function in login-redirects.inc.php:
My altered filter in hooks.php (replaces the add_action(‘wp_login’)):
My altered remove_login_redirect_filters in login-redirects-r.inc.php:
I realize that filtering the login_redirect twice may be redundant, but I will leave that decision up to s2Member’s team. The summary of my changes are:
|
|
Posted: Tuesday Jun 11th, 2013 at 5:07 am #51748 | |
|
|
Thanks for your patience.I contacted Jason about this. Here is his reply: Unfortunately this is a plugin conflict that is not easy to resolve. s2Member MUST attach itself to the wp_signon hook and NOT to the login_redirect filter, because it needs to make sure it is tracking ALL attempts to log into the site; so it can properly prevent Brute Force attacks, track IP addresses, and maintain its login counters. If we attached only to the One possible solution is for the other plugin to add a filter as follows.
|
|
Posted: Tuesday Jun 11th, 2013 at 8:34 am #51758 | |
|
|
I understand the logic you present about needing to track all logins. However, I still disagree with the need to use the wp_signon hook for the redirection. If you need to track user logins, why not hook the wp_signon to perform user login tracking, then perform your redirect logic separately? I feel like performing user tracking, brute force, and ip logging logic should not lie in a function called login_redirect. I suggest something like:
|
|
Posted: Tuesday Jun 11th, 2013 at 11:34 pm #51791 | |
|
|
Thanks for the information. If you’d like you can use your “patched” file in your installation for now by taking your edited copy of this file and loading it in as a Must-Use Plugin. I’ll send this code to Jason for him to look over and consider for a future release of s2Member, but for now you’ll have to have the plugin’s developer use the information from my last reply. Thanks. |
This topic is closed to new replies. Topics with no replies for 2 weeks are closed automatically.