Search for answers or browse our knowledge base.
How to enforce password policies on custom login, password reset & other pages
Password policies configured through Melapress Login Security are enforced on eligible users via the login page, user profile, and password reset pages.
This works out of the box when using the default applicable WordPress pages. The plugin also offers one-click support for third-party plugins such as WooCommerce and LearnDash.
However, if you use a custom solution or a plugin that does not support one-click integration, you have to integrate the plugin to enforce any applicable password policies manually.
Integrations can be done either on the client-side or the server-side. Client-side integrations are easier to implement. Here we can either use JavaScript or shortcode.
On the other hand, server-side integrations require you to update your code and pass the password to the plugin so that the necessary checks can be done.
Strong password requirements show on custom WordPress user registration & profile page
This article explains how you can implement any of the methods and easily enforce strong password policies on your custom password reset and user profile pages.
Method 1: Client-side JavaScript
With this method the password check is done on the form using client-side scripting (JS).
To implement the client side check so users are notified on which policies their password matches or not you can use the ppm_enable_custom_form hook. You can apply our handy password strength checker to any custom form, such as the password change form found in WooCommerce’s user account area with the ppm_enable_custom_form hook.
This method helps your users use passwords up to the standards you specify in our plugin by leveraging our powerful JavaScript based password strength checker. See the example below, which you can add to your website\’s plugin or functions.php file:
function example_ppm_enable_custom_form( $args ) { $args = array( 'element' => '#user_password', 'button_class' => '#submit_password', 'elements_to_hide' => '#old_pw_hints', ); return $args; } add_filter( 'ppm_enable_custom_form', 'example_ppm_enable_custom_form' );
How can I use the hook?
If you\’re not familiar with PHP code, please don\’t let the above code daunt you. Let\’s take a closer look to see what it\’s doing and how we would customize it to suit my specific needs.
As you can see, the code itself is a simple function which is passed onto our plugin so our snazzy JS knows its needed, and where to target. So, let\’s look at example_ppm_enable_custom_form and see what we need to change to suit.
The function is a simple array of arguments for specifying the ID/class for the password fields and submit buttons you wish to apply our script to. The first argument is \”element\”, in the line:
'element' => '#user_password',
This is where you pass the ID/class for the input field you wish to modify. The second argument is \”button_class\” in the below line:
'button_class' => '#submit_password',
Finally we have an other argument which allows you to hide elements on your PW page where the JS is being applied:
'elements_to_hide' => '#old_pw_hints',
Here you can provide any IDs/classes you wish to hide on the same page as your form. This can be useful for hiding password hints being generated elsewhere and much more.
We will now detail how you would locate this class or ID in your page using your browser\’s developer tools.
Where do I locate this ID or class?
In this example we are going to take a look at a popular plugin which you may wish to apply our check tool to, WooCommece.
To begin, head to your user’s account page. This will be the front-facing page your users go to to change account details such as their name, email address and more crucially, their passwords. Using a web browser such as Chrome, within that page, locate the “new password” fields, right click and select “Inspect”.

You will see a panel in your browser – this is your page’s source. What you\’re looking for here is 1st, ensure the field is the password field by checking it has the type=”password” attribute. Once you know it’s the field you want, locate the unique ID (or a unique class if your specific form does not have an id on this element). Let’s take a closer look at our example, WooCommerce, and what its html markup looks like.

In this example we can determine this particular input has the id password_1. So we would add this to our custom functions ‘element’ argument, just like you can see in the example above. Have more than one password input you wish to use? No problem, using a comma separated list such as ‘#custom_id_1, .custom_pw_class, #another_id’ would be fine.
Method 2: Client-side shortcode
Using this method, the password check is done through client-side scripting, in a similar fashion to client-side JavaScript. The only difference between these two methods is that the client-side shortcode uses a shortcode to reference the required hook instead of having to manually reference it yourself through JavaScript code.
To use the client-side shortcode, all you need to do is enter the following shortcode in the form you want to enforce password policies on:
The same element, button_class, and elements_to_hide arguments used in the client-side JavaScript method are applicable here where:
- ‘element’ is the input ID/class
- ‘button_class’ is the submit button
- ‘elements_to_hide’ allows you to hide elements such as old password hints for example
Method 3: Server-side checks
This is the most robust method of the two because the password is actually sent to our plugin to be checked. However, it requires a higher level of technical expertise to be implemented.
This method applies to anyone who is coding their own function to handle the submission. In this case, you can leverage the plugin\’s functionality to ensure any new passwords meet your requirements.
For this to work, we will be using the validate_for_users() function found in the Password Policy manager plugin. For this to function properly we need to pass it a number of variables. Let\’s take a look at an example of how this would look, using the plugin Gravity Forms for reference.
function check_password_on_submission( $form ) { $ppmwp = new \PPM_WP_Password_Check(); $errors = new \WP_Error; // Get input value for password we want to check. $password = $_POST['input_1']; // We need the user ID to check against. This would be the ID for the user submitting. $user = wp_get_current_user(); // Fire off validity check. $is_valid = $ppmwp->validate_for_user( $user->ID, $password, 'reset-form', $errors ); if ( $errors->errors ) { // If we have errors, it means the PW did not meet policy requirements. // $errors contains simple array of useful messages/reasons for failure. error_log( print_r( $errors->errors , true ) ); } else { // Otherwise. password is fine to use and you can continue as normal. error_log( print_r( 'Password is ok.', true ) ); } } add_action( 'gform_pre_submission_1', 'check_password_on_submission' );
The code explained
To break down what\’s going on above, first we create an instance of WPassword, so we can then use its functions:
$ppmwp = new PPM_WP_Password_Check();
Then we set the variables needed for validate_for_user() to work, these are as follows:
$errors = new WP_Error; $password = $_POST['input_1']; $user = wp_get_current_user()
We then fire off the check, in return we will want to look at $errors to see if the password fails.
$is_valid = $ppmwp->validate_for_user( $user->ID, $password, 'reset-form', $errors );
What does validate_for_user return?
The $errors variable is an object which contains two arrays. The one we need to focus on can be accessed via $errors->error.
If the password is good and matches all the configured policies, the $errors->error array will be empty. This means that the password is safe and you can process your form further. Otherwise, a useful error message is returned which details the problem or problems.