Create a rule for updated passwords to meet certain requirements

Let me address this part first:

if you have multiple languages on your site its better to use $str = __(‘pwd-criteria’, ‘your-theme’) instead of the str_replace()

Actually, str_replace() is what you need to use here. WP’s internationalization functions (__(), _e(), etc) can still be used along with str_replace(). One is for replacing specific text (str_replace()), and one is for internationalizing it (__()). They don’t serve the same purpose.

In this instance, str_replace() is looking for a specific string (“Passwords did not match.”) in the error message because we are going to change it. What this actual string is depends on the following:

• What the actual dialog for “Passwords did not match” is in the plugin’s Dialogs tab (since this can be customized by the site user).
• Whether it needs to be internationcalized/localized (i.e. whether another lanuguage or multiple languages is/are used).
• A combination of these two.

In general, in a single language site that is not English, this section of the filter would look as follows:

$old = __( "Passwords did not match.<br /><br />Please try again.", 'wp-members' );
// In a single language site, directly translate the following accordingly.
$new = "Your password did not meet the criteria of 
   containing at least 2 uppercase letters, two 
   lowercase letters, 2 numbers, and 2 special 
   characters.<br /><br />Please try again.";
$str = str_replace( $old, $new, $str );

First note how $old is constructed. We need the original string so we can properly replace it with a more relevant message (i.e. that the password did not meet the requirements). This is where internationalization is used to find the correct string.

Secondly note the $new variable. It is not translated using internationalization. It could be, and in a multi-language site it would have to be. But that adds some complexity that needs to be managed because your translation files would not have this string in them to serve to the user. You would need to add this string and compile a new custom translation file. If it is a single language site, that’s not necessary. It is better to simply serve the correct translated string (meaning: change the English in the example to suit the needed language).

Then finally, str_replace() is run to search the string and do the search/replace accordingly.

I hope this explains not only how to properly handle it, but also “why” to do it this way.

• This reply was modified 3 years, 5 months ago by Chad Butler.
• This reply was modified 3 years, 5 months ago by Chad Butler.

of course this is only one third of what has to be done. you should validate your password rule

1/ on registration
2/ on password reset, choose new password (wp-members can’t do this for some strange reason)
3/ password change, when logged in (as written in this article)

It’s interesting that you bring up this question as I recently was also asked pretty much the same thing recently via email support. It’s weird, but many times these types of questions come in pairs or more (meaning I get the same question from several users all at the same time). The generally means it’s time to re-address the original article and maybe update it.

Here was part of the explanation to this other user that should shed some light:

When [this] particular post was originally written, the only option for the plugin’s registration was to email a randomly generated password to the user. Adding a password field to the registration process was a custom process. As such, for the subscriber question that generated that particular post, it was expected that the user would receive the random password, login and change their password on first use (and would then need to create a password using the password rules).

In addition to this, the random password would have met the password requirements as well because the WP random password generator was generating passwords that met the kind of criteria in the example. WP’s random password process has changed somewhat since then as well (although, unless filtered, it generates only strong passwords based on the WP password strength algorithm).

A simple filter to address the password at registration (#1 above), assuming that a password is chosen at registration, would be as follows:

add_filter( 'wpmem_pre_register_data', function( $fields ) {
	
	global $wpmem_themsg;
	
	$password = $fields['password'];
	
	if ( $password ) {
		// Check for proper password strength.
		switch ( $password ) {
			// Must have 2 Uppercase characters
			case ( preg_match_all( '/[A-Z]/', $password, $o ) < 2 ):
			// Must have 2 lowercase characters
			case ( preg_match_all( '/[a-z]/', $password, $o ) < 2 ):
			// Must have 2 numeric characters
			case ( preg_match_all( '/[0-9]/', $password, $o ) < 2 ):
			// Must have 2 special chars
			case ( preg_match_all( '/[^a-zA-Z0-9]/', $password, $o ) < 2 ):
			// Must be at least 8 characters.
			case ( strlen( $password ) < 8 ):
				$wpmem_themsg = "Sorry, your password did not meet the password requirements. Please try again.";
				break;
		}		
	}
	
});

In order to address #2 as needed, either a filter for WP’s random_password hook or a pluggable function of wp_generate_password() – either of which would need to check the criteria. I’ll need to put together a working example of that. Once I do, I’ll probably update this entire article accordingly.