[Resolved] Changing User Password on CRED User Form (not functioning properly)

[Author]

Posts

[nedG]

I am developing a Membership site for a civic league

I have created an EDIT ACCOUNT form for users (CRED Form).

I have 2 different types of users....
MEMBERS (ACTIVE)
MEMBERS (EXPIRED)

The form was working great for all custom user fields that I created. Then I decided that it would be useful for members to be able to change their password using the form.

So I added the Password input field(s) and also forced the user to retype his password in the 2nd field. The password field(s) are not required.

The form works great if I don't make any modifications to the password field(s).

However, if I make a modification the password field(s) , a few things are happening that are unexpected.

PROBLEM #1) If I enter only a single password into the first password field (scaffold_field_id='user_pass') and leave the other password field blank and then try to click "UPDATE" the form indicates that it was submitted successfully. I was expecting it to throw an error and let me know that the password fields don't match (since the 2nd password field was left blank). Also, it doesn't appear that the password actually gets changed to anything in the DB. It remains unchanged.... yet I received no error.

PROBLEM #2) If I opt to modify the password and enter the new password into both password fields, when I click the UPDATE button, I get an NGINX error. It appears that the password actually DOES get changed in the DB... because in order to get back into the Member Account, I have to log back in and use the new password.
I am guessing that I am getting the NGINX error because when the form gets submitted with the new password, it changes the password in the DB and now my existing user account is not longer valid and it cannot follow the CRED form instructions that I have set to "Keep Displaying this form". Not sure what to do and how to get around this issue. Should I simply create a separate CRED User Form for changing the password and only use this Account Update form to change Custom User fields?

[Christian Cox]

Hi, first I would double-check to be sure there's a form messages field in the Form. Otherwise, you may experience some weirdness when using AJAX when validation messages are thrown by the backend. No error will be displayed on the front-end, and it will seem as if the Form was submitted successfully. If you're using the new Form builder expert mode (or editing an older Form), the shortcode looks like this:

[cred_field field='form_messages' class='alert alert-warning']

If you're not using the expert Form builder then you can drag and drop a Form messages field in from the "Extra elements" panel.

If that's not the source of the problem, let's try a few other things.
- Be sure your WP and Toolset plugins are up-to-date.
- Temporarily deactivate all plugins except Types, Forms and Views and test the Form once again. Watch the browser console to see if any JavaScript errors are registered.
- If the problem is resolved, reactivate your theme and plugins one by one until the problem returns. Let me know if you can pin down a single source of conflict.
- Change the Form settings to redirect to a Page that is accessible without being logged in. See if this resolves the nginx error.
- Enable server logs so we can see if anything more specific than a generic nginx error is registered. If you're not familiar with server logs I can show you how to activate them temporarily. Go in your wp-config.php file and look for

define('WP_DEBUG', false);

Change it to:

define('WP_DEBUG', true);

Then add these lines, just before it says 'stop editing here':

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

Submit the Form again to trigger the nginx error. If anything more detailed is thrown, this will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the changes you made to wp-config.php and delete the log file.

[nedG]

Thanks for the help Christian,

Here is the result.

Problem #2 seems to be resolved (the NGINX error). I have no idea what happened, but once I deactivated all of the plugins and then re-activated them one at a time, the problem never came back. No More NGINX errors.

The problem with #1 remains.

I have essentially all Plugins deactivated. I have tested the following conditions with the corresponding results.

1>>>>>>>
CONDITION#1: Submitted the UPDATE USER CRED FORM without any changes to either password field
RESULT #1: No issues. The proper custom msg was displayed at the top ("Your Account Information has been updated successfully!")

2>>>>>>>
CONDITION#2: Submitted the UPDATE USER CRED FORM with identical changes to both password fields
RESULT #2: No issues. The proper custom msg was displayed at the top ("Your Account Information has been updated successfully!") . And it appears that the password was actually changed.

3>>>>>>>
CONDITION#3: Submitted the UPDATE USER CRED FORM with an entry into the 1st password field and no changes at all to the 2nd password field (left empty)
RESULT #3: The custom msg was displayed at the top ("Your Account Information has been updated successfully!") . However since the 2nd password field was left empty, I expected to receive an error message about mismatched passwords. Also, it appears that the password was NOT actually changed in the DB.

4>>>>>>>
CONDITION#4: Submitted the UPDATE USER CRED FORM with an entry into the 1st password field and a different (mismatched) entry into the 2nd password field.
RESULT #4: The custom msg was displayed at the top ("Your Account Information has been updated successfully!") . However since the 2nd password field was mismatched, I expected to receive an error message about mismatched passwords. Also, it appears that the password was NOT actually changed in the DB.

No error messages have been seen in the error log.

I also tried to clear out any custom functions that I had added into the functions.php file (just incase one of my custom functions was bad). But it didn't seem to matter.

Lastly, the only console error that I see is simply a warning... "Password fields present on an insecure (hidden link) page. This is a security risk that allows user login credentials to be stolen.[Learn More]".

Since this site is still in testing and not LIVE, I have not yet installed an SSL cert.

Not sure what else to do from here

[Christian Cox]

Okay thanks, I think the next step is for me to try to replicate the problem on my local environment. Can you export your site's Types, Views, Forms, and Access information from Toolset > Export/Import ? Then post a link where I can download these items and I will try to replicate the same error on my own environment.

[nedG]

Can you set up a "private" message reply and I can provide you with what you need

[Christian Cox]

Sure, private reply fields are active here. For future reference, any full URL you add to a forum post (even in the public area) is obscured from public view, by default. Only you and our support team can see URLs unless you add an "at" symbol in front of the URL. That makes the URL public.

[nedG]

In order to duplicte my problem, go ahead and create any user with a Role of MEMBER (Active) or MEMBER (Expired).

Then once logged in as that user, go here...
hidden link

Click on the Edit Account link...
hidden link

Then perform my tests above to change the password.

[Christian Cox]

Thanks, I'm able to replicate this issue now on my local environment, so I'm escalating to 2nd tier support for additional investigation. Stand by and I'll update you when I have more information to share.

[Christian Cox]

Hi, a quick update to let you know our developers plan to release the fix for this issue in a round of updates currently planned for next week. I'll keep you posted here about the release date.

[Christian Cox]

We have just released updates for Views and Forms that will include the fix for this problem. You can find the updates at https://toolset.com/account/downloads now. They will be available through the automatic update process later today. Please update to the latest plugin versions and let me know if the problem is not resolved.

***Special note about this update: One of the issues that was resolved in this release pertains to the settings for autogenerate nickname, username, and password fields in existing User Forms. Please edit any existing User Forms and confirm the settings for those fields are accurate, then resave the Forms.

[nedG]

My issue is resolved now. Thank you!