Users not getting password upon activation

There is a recently discovered bug introduced in version 2.9.3 specific to the following conditions:

1. New Install at 2.9.3
2. Moderated registration
3. Using default process of automatically generated password

Part of the activation process checks the plugin’s fields to see if a password is part of the registration form, and if so, it does not generate a password as part of the activation.

Up until 2.9.3, if a plugin users wanted to include a password field in the registration process (for users to create their own passwords when they register), they needed to add this field on their own. The plugin logic for the check described above considers that if the password field is there, it is being used.

In 2.9.3, a password field was added to the default fields, along with password confirmation and email confirmation. The reason these were added is that a lot of users ask for one or the other or both, and in the past, this involved adding the fields as well as custom code snippets for handling the form validation. 2.9.3 added the fields and if used, the form validation. But they are not used in the default install.

The patch for this, which will be part of the next release, 2.9.4 is as follows:

Look at the file /admin/users.php. At line 101 you should see the following:

if( $action == 'activate' || 'activate-single' ) {
	// find out if we need to set passwords
	$chk_pass = false;
	$wpmem_fields = get_option( 'wpmembers_fields' );
	for ( $row = 0; $row < count( $wpmem_fields ); $row++ ) {
		if( $wpmem_fields[$row][2] == 'password' ) { $chk_pass = true; }
	}
}

The key part of this is the last part of the logic:

if( $wpmem_fields[$row][2] == 'password' ) { $chk_pass = true; }

That needs to be changed to this:

if( $wpmem_fields[$row][2] == 'password' && $wpmem_fields[$row][4] == 'y' ) { $chk_pass = true; }

This change adds logic to check to see if the password field not only exists, but is being used.