So here's the problem. When an individual logs in using the widget for example, it processes the login and then attempts to redirect them only for it to fail with a blank white page.
The direct url that is becoming a white page and stopping dead in its tracks is "?oa_social_login_source=widget" which appears to be the root of the problem. Its a secure website thus https:// and doesn't register any errors server side at least in the places I've checked. Any help would be appreciated regarding this matter. The regular login page works fine with OneAll disabled, however I would prefer to have the functionality of OneAll since our users generally like to auto register/login using their social networking accounts.
Answers
To help troubleshoot, could you comment the following lines in wordpress/wp-content/plugins/oa-social-login/includes/communication.php, about lines 483 and 489:
//$redirect_to = apply_filters ('registration_redirect', $redirect_to);
//$redirect_to = apply_filters ('login_redirect', $redirect_to, (! empty ($_GET ['redirect_to']) ? $_GET ['redirect_to'] : ''), $user_data);
(comment them out by placing '//' in front).
And tell us if you still get the redirection error?
Commenting out the lines above prevents the plugin from calling other redirections. So, the fact that it now works means something else is redirecting your user login.
It is strange that the profile.php page is blank (the user's profile?), and that standard login does not redirect.
Perhaps you can log the configured redirections (to see where they were set).
In your theme's functions.php file, you can add some logging to hopefully show something, like this (add the lines towards the end):
function log_redirections ($url) { global $wp_filter; $filt_to_show = array( 'login_redirect', 'oa_social_login_filter_login_redirect_url', 'oa_social_login_action_before_user_redirect', ); foreach ($filt_to_show as $filt) { if (isset($wp_filter[$filt])) { error_log(__FUNCTION__ .' filter '. $filt .' '. print_r($wp_filter[$filt], true)); } } error_log (__FUNCTION__ .' redirecting to '. print_r ($url, true)); return $url; } add_filter('login_redirect', 'log_redirections', 100, 1); function log_redirect_status($status, $location) { error_log (__FUNCTION__ .' redirecting to '. $location); return $status; } add_filter('wp_redirect_status', 'log_redirect_status', 100, 2);
Of course, you need to temporarily enable debug logging to file https://codex.wordpress.org/Debugging_in_WordPress.
Finally, when logging in, the debug.log file in your Wordpress directory will hold some information.
Weird, on a test site here, the user profile is on wp-admin/profile.php. Anyway.
We still need to find out how is the redirect set, so it can be changed to a correct value.
if ( ( empty( $redirect_to ) || $redirect_to == 'wp-admin/' || $redirect_to == admin_url() ) ) {
// If the user doesn't belong to a blog, send them to user admin. If the user can't edit posts, send them to their profile.
if ( is_multisite() && !get_active_blog_for_user($user->ID) && !is_super_admin( $user->ID ) )
$redirect_to = user_admin_url();
elseif ( is_multisite() && !$user->has_cap('read') )
$redirect_to = get_dashboard_url( $user->ID );
elseif ( !$user->has_cap('edit_posts') )
$redirect_to = ('activity');
}
wp_safe_redirect($redirect_to);
exit();
Where it reflects "activity" is where I went ahead and altered it from the original admin url and profile.php redirect. Again a tempo workaround but at least it resolves the issue for now. Initially I resolved the blank white page by adjusting the permissions on the profile.php itself, but now it just goes to an actual 404 which is even more curious.
https://www.vastgamer.com/wp-admin/profile.php
Any last suggestions or ideas that you can think of? I really don't think its an issue relating to this plugin at this point.
Thanks for this information!
Where did you set your workaround for the login redirect?
We noticed that BuddyPress interacts with the redirects for login (login_redirect filter), with their bp_login_redirect() hook. Perhaps your workaround can be set there too, to make it active only with BuddyPress.
Original code was...
if ( ( empty( $redirect_to ) || $redirect_to == 'wp-admin/' || $redirect_to == admin_url() ) ) {
// If the user doesn't belong to a blog, send them to user admin. If the user can't edit posts, send them to their profile.
if ( is_multisite() && !get_active_blog_for_user($user->ID) && !is_super_admin( $user->ID ) )
$redirect_to = user_admin_url();
elseif ( is_multisite() && !$user->has_cap('read') )
$redirect_to = get_dashboard_url( $user->ID );
elseif ( !$user->has_cap('edit_posts') )
$redirect_to = admin_url('profile.php');
Notice where the "$redirect_to = admin_url('profile.php');" reflected the admin url and profile.php which is where I changed it to ('activity'); which with buddypress sends the user after a successful login to the activity page, which is basically similar to the social media newsfeed that you'd see if you say, went to facebook.com to login. It won't be a successful workaround when it comes to wordpress updating, unless I make the modification each time, however it does work to ensure users are able to login each time. Debug shows no issues other than the error 404 which according to the specific profile.php it redirects to....
<?php
/**
* User Profile Administration Screen.
*
* @package WordPress
* @subpackage Administration
*/
/**
* This is a profile page.
*
* @since 2.5.0
* @var bool
*/
define('IS_PROFILE_PAGE', true);
/** Load User Editing Page */
require_once( dirname( __FILE__ ) . '/user-edit.php' );
As far as that file is concerned, I checked permissions and its all correct. Really weird issue, though I'm glad I was able to figure out the specific area to modify it so it doesn't hinder the users ability to login. Granted, we're relaunching our brand after a failed merger, but there have still been individuals trying to login before switching it that had issues with the blank page.