Installing over existing user table gives misleading instruction

[coffee2code]

WordPress properly handles being installed into a database with an existing wp_users table (and potentially no other tables). In this situation, instead of generating a random password, WP reports:

User already exists. Password inherited.

However, just below that, it also reports:

Note that password carefully! It is a random password that was generated just for you.

The latter statement is incorrect in this scenario, and could be misleading (and concerning) to the person doing the installation. Nothing is in jeopardy, though.

Granted, this is a bit of an edge case. But the fix is trivial (it compares the password against the first message listed above). If the message is later changed in one place and not the other, the code will just fall back to the currently existing behavior.

[coffee2code]

Aforementioned patch

[Denis-de-Bernardy]

patch is better than none, but we should keep this one open even after the commit, due to the fact that if the function gets overridden then the password may not necessarily contain that string.

[coffee2code]

Attaching an alternative implementation of the patch. Just about as simple, but more generic, and probably good enough to warrant closing the ticket if committed. No longer compare the returned random password with a separate copy of the phrase indicating an existing password was inherited, which is a potentially brittle check as the phrase could be changed in one place but not the other.

Instead, simply check the potentially generated password for a space character. A space character is not a valid password character. Its presence would indicate a phrase or sentence of some sort was returned, therefore the instruction to note the password need not be shown. This allows for the message to be changed without needing to change anything here. Also, some other error message could just as well be returned and things will still behave as expected.

[coffee2code]

Alternative (and preferred) implementation

[Denis-de-Bernardy]

this:

strpos($password, ' ') === false

will not work on a chinese install. :-)

[coffee2code]

Ah, oops. Any other idea for something simple? Otherwise, perhaps just the original patch for the time being? Inline comments could be added to both places the message is defined to tell anyone updating the text that it needs to be updated in the other place as well.

Other possible considerations:

• Have wp_install() return '' instead of the "...Password inherited..." message as the password. The presumption being that no password == inherited password. Therefore, the "...Password inherited..." message could just be specified in one place (wp-admin/install.php) and not also in wp_install().

• Or if we anticipate later having other non-password responses such that '' can't be assumed to mean a password was inherited, maybe return a WP_Error object in place of the password and check for that?

[Denis-de-Bernardy]

Replying to coffee2code:

• Have wp_install() return '' instead of the "...Password inherited..." message as the password. The presumption being that no password == inherited password. Therefore, the "...Password inherited..." message could just be specified in one place (wp-admin/install.php) and not also in wp_install().

• Or if we anticipate later having other non-password responses such that '' can't be assumed to mean a password was inherited, maybe return a WP_Error object in place of the password and check for that?

WP_Error object seems like the one that makes the most sense. That it's called WP_Error might confuse whoever looks into it after, though. A WP_Warning comes to mind. :-D

D.

[westi]

I think the best thing here is to move the string generation into wp_install and return the message for both cases from there.

[westi]

(In [11326]) Give better instructions when installing over an existing users table. Fixes #9569 based on patch from coffee2code.