strongbox

I should also note, this is not an issue just in admin, this causes the front end of site to also go down while plugin is active.

Not sure if they have fixed this in the latest release, haven’t looked at the code, but it seems like it should be a very simple fix to implement. It would be nice to not need to hack the code to get it to work with buddypress.

;o)

Maybe the developer will chime in on this?

P.S. I like micro brews… LOL.

Here is a “final” solution for this issue.

Since $user_login is already converted to lowercase, however it does insert a “_” if there is a space, I then strip the underscore and make the user_nicename an all one word lowercase slug.

$user_nicename = trim( str_replace( '_', '', $user_login ) );

		$userdata = array(
			'user_login'    => $user_login,
			'user_email'    => $user_email,
			'user_nicename' => $user_nicename,

			'first_name'    => $hybridauth_user_profile->firstName,
			'last_name'     => $hybridauth_user_profile->lastName,
			//'user_nicename' => $hybridauth_user_profile->displayName,
			'display_name'  => $hybridauth_user_profile->displayName,
			'user_url'      => $hybridauth_user_profile->profileURL,
			'description'   => $hybridauth_user_profile->description,

			'user_pass'     => wp_generate_password()
		);

This code in the plugin.auth.php file (near the bottom of file) does the trick. Now WSL works with both buddypress and non-buddypress installations as long as you hook WSL into your buddypress registration form.

Like so:

# Add WordPress Social Login
		if (has_filter('activate_wordpress-social-login/wp-social-login.php')) {

		# Login/Registration Button Location
		add_action ('bp_before_account_details_fields', 'wsl_render_login_form_login'); # Top of registration form
		//add_action ('bp_before_registration_submit_buttons', 'wsl_render_login_form_login'); # Bottom of registration form
		}

This of course should be incorporated into the WSL plugin directly to hook into the BP forms if BP is enabled.

Not sure why I did it the other way, I guess they both work but this method is cleaner I suppose.

$userdata = array(
			'user_login'    => $user_login,
			'user_email'    => $user_email,
			'user_nicename' => $user_login,

			'first_name'    => $hybridauth_user_profile->firstName,
			'last_name'     => $hybridauth_user_profile->lastName,
			//'user_nicename' => $hybridauth_user_profile->displayName,
			'display_name'  => $hybridauth_user_profile->displayName,
			'user_url'      => $hybridauth_user_profile->profileURL,
			'description'   => $hybridauth_user_profile->description,

			'user_pass'     => wp_generate_password()
		);

In plugin.auth.php

$userdata = array(
			'user_login'    => $user_login,
			'user_email'    => $user_email,

			'first_name'    => $hybridauth_user_profile->firstName,
			'last_name'     => $hybridauth_user_profile->lastName,
			//'user_nicename' => $hybridauth_user_profile->displayName,
			'user_nicename' => $hybridauth_user_profile->$user_login,
			'display_name'  => $hybridauth_user_profile->displayName,
			'user_url'      => $hybridauth_user_profile->profileURL,
			'description'   => $hybridauth_user_profile->description,

			'user_pass'     => wp_generate_password()
		);

See change made for user_nicename, inserting user login rather than the display_name value which kills buddypress profile links.

looks like an easy update to the files, the only issue is now we need to update the db to fix previously entered user_nicename values.

Are you saying that if you install WSL that it doesn’t do a simple check to make sure the site is allowing new users to register before showing the option to login/register using your plugin?

Personally, if I put in the admin settings of wordpress that I do not want users to register on the site I expect plugins to respect that setting and not override it for no particular reason.

Hey my partner sent you a donation via paypal today, thank you for the hard work on this plugin, we are looking forward to the future development of it.

Thanks!

This is the issue I am having with 2.1.3, when the form is submitted it goes to a “processing” page and then just hangs there, the review is posted to the database however.

If I enable the website field and do not require it and then submit the form, I get the “processing” screen and it does not post the review to the database.

If I enable the website field and require it the review is posted, the page still hangs on “processing” though.

With 2.1.1 the javascript and the css are being called correctly now, when I try a review it says that I did not provide a correct web address even though I am not requiring one to be submitted, only allowing for the option of submitting one. The form will not submit unless I add a web address. If I remove it from the displayed fields it works correctly.

Also, POST information is not being returned to the form when a user is given an error message. You might want to pass that info into a variable so that it can be posted back to the form so that users don’t have to reenter everything again.

I have embedded the CSS into the thesis custom.css file with an include.

I moved the JS into the head using a custom function hook into the Head. Still is not posting to the DB when a review is added. Without the hack I don’t see the JS or the CSS at all.

I have removed the hack for the CSS, and it is not being called into the theme at all now.

Sweet man! Thesis is used by many online marketers such as myself and this is worth a donation for sure.

The page is:

https://www.rhombuspizza.com/reviews

Again, I have manually called the JS and the CSS, however I think what is happening is that maybe the file structure of Thesis might be causing issues with how the function is creating the urls to call scripts as well as the path to posting to the DB for info entered into the form.

If I submit the form, no info is posted.

Thanks!