Better UX after supplying incorrect information to setup-config

Description

In #15682 I added a 'Try Again' button to step 2 of setup-config.php if the credentials were incorrect.

The button is a simple link with a javascript:history.go(-1) hack. This should instead be a form with hidden values that submits back to setup-config.php?step=1, and fills out the form so they can try again.

Additional enhancement: If the prefix is malformed (can only contain letters, numbers and underscores), we do a wp_die(). We should again have a form with a 'Try Again' button that returns them.

As an added bonus, incorrect credentials should be filled out (for reference) but marked as incorrect and potentially with the focus set on that field.

Only caveat I can think of: This will require the use of esc_attr(), which we don't have access to yet. Not sure how to solve that without reverting to htmlspecialchars() with some extra work.

You're right, it's tough. There's no way to tell if it's user, server, or password. But there is a differentiation between these three:

user, host, password

database name

table prefix

In lieu of border colors, let's just try a simple error message at the top in <p> tags, with three different error messages (one for each case). "Cannot check to the database server with this username and password.", "Cannot select this database.", "The table prefix can contain only letters, numbers, and underscores."

Then, focus the first applicable field via injected JS, either name, user, or table prefix.

Take a look at our coding standards: ​http://codex.wordpress.org/WordPress_Coding_Standards. Function names should be written with underscores separating the words.
I think we can avoid a new function all together. That would also avoid the overuse of globals here. What we can do is create our own WP_Error object, then modify the branching a bit to allow the DB connection to only be tested if the prefix is valid, and either way, we can then show a form to send them back to. It doesn't even need to be a WP_Error object
, just something we can keep track of.

For both hidden elements and in the form inputs, we need to properly escape these. We don't have access to esc_attr() here, so a call to htmlspecialchars( $string, ENT_QUOTES ) sh
ould do. Rather than just doing this for the prefix. Also, always escape as late as possible -- so in the form in both cases.

Perhaps we should use htmlspecialchars( $dbname, ENT_QUOTES, 'UTF-8' ) instead of just htmlspecialchars( $dbname, ENT_QUOTES ). Though I'm not exactly sure if MySQL allows UTF-8 characters in database name, username or password, I've tried to create a MySQL user with Cyrillic username and it seems to be working.

The button is a simple link with a javascript:history.go(-1) hack. This should instead be a form with hidden values that submits back to setup-config.php?step=1, and fills out the form so they can try again.