Create #confirm property to ensure equality of two input fields

+1 Subscribing!

Setting this to bug report because I feel this is a security related issue. Almost all CMS systems provide this functionality to make sure users are not creating bad passwords.

tagging for novice queue

What about abstracting this to a new property name "#confirm" that can be applied to ANY field?

I will take that on, unless there are objections.

edited for terminology

In this patch:

• Implementation of #confirm property
• Simpletests for #confirm property (in modules/simpletest/tests/form.test)
• JavaScript user feedback ("Confirm values match: yes/no") similar to that of password_confirm FAPI type
• Basic styling of confirm fields and js user feedback
• admin/user/settings field to allow admin control over email confirm field on user/register.

Not in this patch:

• Any changes to password_confirm FAPI field type. The #confirm property implementation has the potential to fully replace password_confirm, but that's not part of this patch.
• Javascript tests

Feedback welcome -- thanks for reviewing & testing

+1, subscribing.

Your coding style needs work - please read http://drupal.org/coding-standards and sub-pages about comment standards.

rerolled @ HEAD

Looks like the intent of this issue has changed. +1 for a #confirm property.

Bot hasn't finished testing yet but either way it needs a lot of work from the coding standards standpoint, as sun pointed out.

Can you please be a bit more specific w.r.t coding standards?
I ran it through Coder already.

reroll, with code style and translation related changes

Change component. This is not related to the Field API.

Guess it's too late for 7.x now.

Is this feature now available in 6.x or have you given up?

Aza: this feature won't make it into 6.x...only bug and security fixes go in at this point, and now that 7.x has reached code freeze, it's not making it in there either, so we can only hope for 8.x at this point.

Is this still a desired feature? As I understand it, it's a toggle to add in an email confirmation field and test whether both match?

PS. What's wrong with leaving in login toboggan? It seems to implement the feature quite well.

I'm working on this, and it seems to me like a useful addition to the Form API.

The implications of aaronbauman's plan (see #5) are:

• a #confirm property would become available for relevant Form API types, which would be textfield, email, phone, password. API addition.
• that the password_confirm type would become redundant, and an API removal seems sensible to remove password_confirm. Password elements needing a 'confirm' input should have #type='password' and #confirm=TRUE
• it might be sensible to warn about & test for people porting D7 modules who have included a password_confirm type, as it would normally fall back to 'textfield', thus exposing user's passwords (which would be bad)...
• there might be terminological confusion with #confirm, because it sounds like confirm_form() (which does something completely different). But I don't know of any alternatives except something more wordy like #require_duplicate

It seems that there won't be any code bloat in this, if it simply replaces all the code that deals with password_confirm.

I'm having a go at rerolling aaronbauman's patch which looks like it will be relatively simple to update for D8.

(by the way I haven't written D8 core patches before)

Initial patch, which just rerolls the form.inc, system.module and user.module parts of aaronbauman's patch.

More patches to follow for tests and JS/AJAX changes, and then yet another patch for the (more controversial) removal of password_confirm.

Updated patch (no exotic #states stuff, and configuration is now in the right place under Account settings).

Potential 'title' option for the #confirm property, which aaronbauman suggested in his @todo:

$example = array(
  '#type' => 'email',
  '#title' => t('E-mail address'),
  '#confirm' => array(
    'title' => 'Enter your e-mail address again', // default: 'Confirm ' . $element['#title']
  ),
);

Updated patch, including jQuery client-side validation (by aaronbauman, adapted from user.js). Working here with @Mac_Weber at DrupalCon. No tests yet.

New complete patch attached (including the PHP, the JavaScript and the tests), doing what aaronbauman describes in #5 above. Patch by @pjcdawkins and @Mac_Weber (novices at DrupalCon Munich).

Note that this patch does not do anything about the password_confirm Form API type (see #5 and #27 above).

Wrote an up-to-date summary based on the template.

Removed "// Text of original report here."

Needs reworking.

tdm:d8 thedavidmeister$ git apply confirm_property_with_js_and_tests-111322-32.patch 
error: patch failed: core/misc/form.js:80
error: core/misc/form.js: patch does not apply
error: patch failed: core/modules/system/system.module:367
error: core/modules/system/system.module: patch does not apply
error: core/modules/user/lib/Drupal/user/AccountFormController.php: No such file or directory
error: patch failed: core/modules/user/user.admin.inc:310
error: core/modules/user/user.admin.inc: patch does not apply

Note that this patch does not do anything about the password_confirm Form API type (see #5 and #27 above).

This is an important part of the patch though, right?

+ '#value' => is_array($value) ? (isset($value['confirm']) ? $value['confirm'] : NULL) : $value,

The legibility of this line could be improved by splitting it across a few lines.

+  // Set #id to make sure FAPI doesn't bust us for a conflicting DOM id.
+  $element['#id'] = 'rand' . rand();

We have drupal_html_id() for this.

This is very old issue so I don't think this is good issue for a novice anymore.