Contrib.social

Allow forms to set custom validation error messages on required fields

Open on Drupal.org →
Created on 15 March 2010, over 14 years ago
Updated 24 April 2024, 2 months ago

Updated: #175
From Bowersox on #171
Status Summary
In comment 120, @webchick committed the D8 patch. This added the new API, which is good. Folks started working on the D7 backport. But @David_Rothstein pointed out that the committed patch had broken form validation in D8. David suggested that we fix the order that form validation happens in comments 126 and 127. But @sun suggested an alternative work-around in 128 and 140. Currently this is messed up in D8 and we need to implement a solution. The D7 backport discussion may resume later.

New Patch
I support the @David_Rothstein approach, which means doing the required field validation before the #element-validate validation. The new patch attached basically re-orders the logic to restore the order. This could use a code review and a test to make sure the example David points out gets the right error message. andymartha provided screenshots that the patch applies cleanly with error messages tailored to the required field.

Problem/Motivation

Accessibility guidelines recommend specific, meaningful error messages when required form elements are empty. However, FAPI currently does not support custom error messages for required elements.

Proposed resolution

  1. Support a #required_error property for form elements. If set, this message will be used when a required form element is empty, instead of the default "Field x is required."
  2. Additionally set a #required_but_empty flag automatically during validation when the required field is empty. This is an internal property and is not set manually. It allows #element_validate handlers to set a custom required error message, but without havingto re-implement the complex logic to figure out whether the field value is empty.

Remaining tasks

Commit feature and document these properties. The feature is a small API improvement that is applicable to both D8 and D7.

User interface changes

None.

API changes

Minor, backwards-compatible addition only. No existing code will be affected.

Addition of two FAPI element properties:

  1. #required_error
  2. #required_but_empty

Original report by neilnz

Hi,

In a couple of cases working on forms that need to meet government accessibility guidelines, I've been asked by a client to implement specific help text that is shown when a form field is not completed that replaces the generic "[fieldname] field is required". An example might be changing "Password field is required" to "Please enter your password" on the login form.

I know that the error message template can be overridden on a general level to say something different (like "Please fill in [fieldname]"), but it's not easily possible to set it for one specific instance of a field at present.

There are four current solutions to this problem, two of which require core hacks:

  1. My core patch to form.inc, as attached, which adds a new #required_message element to the form definition which is used to override the default message for that form field. This can be applied using hook_form_alter() or used directly in a custom form definition.
  2. Another approach is a different patch to form.inc which wraps the first t() around the error with a second t(), so the message with substituted field name can be overridden by a module like string overrides. Possibly this could be supported more generically by the t() function by scanning for a second translation after the substitution is performed.
  3. Use hook_form_alter() to set #required to false and add a new #validate callback for the element, which sets an appropriate message (obviously can do this natively on a custom form)
  4. Use hook_form_alter() to add a validate callback that uses form_set_error(NULL, '', true) to get and clear errors, parse the errors, replace a particular error message from core, and then store the resulting error array back again (if any).

I guess regexp at the theme/preprocess layer could be used as well, but that's a bit ugly.

At the moment I'm using option 3, which works alright except it removes the asterisk from the field, so this needs to be hacked back in at the theme layer.

The potential for my patch is to make this support a bit more widespread, eg. in a field config form, the user can tick the "Required" option for the field, but also gets an optional textbox to replace the standard error for that field.

I'm submitting this mostly as an RFC to see if it's worthwhile. If so, I'm happy to finish off the support by patching the form API docs etc as well.

Patch is against HEAD.

Thanks

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Form  →

Last updated about 1 hour ago

Created by

🇳🇿New Zealand neilnz

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • API addition

    Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024