Auto-generated Password Nag

[battis]

Whenever I log in, I am warned that "You’re using the auto-generated password for your account. Would you like to change it to something you’ll remember easier?" -- even after having changed my password (and clicked the link to "No thanks, do not remind me again")

This appears in WordPress 3.0-beta2-14550

[dd32]

Was this installed on SVN trunk a few weeks ago? I believe there was a bug for a few revisions which result in this.

Does this occur on a new installation of the latest trunk?

[dd32]

Just tested this, Both changing the users password and clicking the dismiss option appears to be working correctly for me.

If you experience this on a clean install, please re-open with any specifics on the environment/configuration of WordPress you are using.

[TomAuger]

Just had this happen twice with two fresh installs from trunk (3.5-alpha-21499) on a local XAMPP box.

Here's the install process I followed both times:

• create a new directory inside my server path
• checkout ​http://core.svn.wordpress.org/trunk
• create a new DB
• edit wp-config.php
• 5-minute install (more like 5 seconds these days!)
• default user ('admin')
• get the auto-generated pwd message. Copy the pwd
• log in with auto-generated pwd
• get the nag
• click the nag to go to profile
• change the password
• this logs you out
• log in with the new password
• nag is still there.

[SergeyBiryukov]

The latest bug was introduced in [21376].

Now that get_userdata() returns existing data for current user, default_password_nag_edit_user() compares the old password to itself and fails to delete the default_password_nag option:
​http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/user.php?rev=21496#L334

wp_generate_auth_cookie() (called via wp_update_user()) also receives the old data, which causes it to create cookies for the old password and leads to logout:
​http://core.trac.wordpress.org/browser/trunk/wp-includes/pluggable.php?rev=21496#L581

13351.patch​ replaces get_userdata() with new WP_User() in those two places. An alternative would probably be to check if $_POST (or a specific key) is empty in get_user_by().

[SergeyBiryukov]

Fixed in [21563].