#5080 closed defect (bug) (fixed)
Buddypress sidebar login broken under specific conditions - appears to be a result of the ordering of parameters in query
Reported by: | newbiesteve | Owned by: | johnjamesjacoby |
---|---|---|---|
Milestone: | 1.8 | Priority: | normal |
Severity: | major | Version: | 1.7 |
Component: | Templates | Keywords: | dev-feedback |
Cc: |
Description
Logging in through the BuddyPress sidebar results in a 408 or 500 error in specific situations. wp-login.php works as normal.
Environment Details:
- Buddypress 1.7.1, Wordpress 3.5.1 (BP 1.7.2 & WP 3.5.2 are also affected, but not sure how far back this goes)
- When served off local machine with Xampp: Works
- When served off professionally hosted remote server: Doesn’t work (408 timeout). However, login directly through wp-login.php did work
Investigation:
I used firebug to compare the HTTP POST messages being sent when I log in through the sidebar or directly through wp-login.php. The only difference I saw between the two was:
Sidebar login order of parameters (broken): login, password, redirect, wp-submit, testcookie
wp-login.php login order of parameters: login, password, wp-submit, redirect, testcookie
I don’t know why they’re swapped in the sidebar code. I also don’t know how or why swapping them could result in working in some environments and timing out in others. Can anyone else chime in here?
Solution:
In bp-themes\bp-default\sidebar.php, find this code:
<?php do_action( 'bp_sidebar_login_form' ); ?> <input type=”submit” name=”wp-submit” id=”sidebar-wp-submit” value=”<?php _e( 'Log In', 'buddypress' ); ?>” tabindex=”100″ />
Swap these two lines:
<input type=”submit” name=”wp-submit” id=”sidebar-wp-submit” value=”<?php _e( 'Log In', 'buddypress' ); ?>” tabindex=”100″ /> <?php do_action( 'bp_sidebar_login_form' ); ?>
This seems to fix the issue by re-ordering the parameters in the query string to match that of wp-login.php.
Thanks for testing and providing a solution, newbiesteve.
Very odd that the load order of the login parameters is causing this issue.
Unfortunately, I'm unable to duplicate the report, but I don't see a problem with adding this fix since it appears that a few other people are experiencing this problem.