If a form element mapped to a #config_target has multiple constraint violations, only the last one is displayed

OK, test coverage is written! Now to fix the bug...

Ran the test-only feature

There was 1 failure:
1) Drupal\Tests\system\Functional\Form\ConfigTargetTest::testMultipleViolations
Element matching xpath "//div[@data-drupal-messages]//div[(contains(@aria-label, "Error message") or contains(@aria-labelledby, "error")) and contains(., "Absolutely not. Durians are the worst.")]" not found.
/builds/issue/drupal-3402228/core/tests/Drupal/Tests/WebAssert.php:830
/builds/issue/drupal-3402228/core/modules/system/tests/src/Functional/Form/ConfigTargetTest.php:160
/builds/issue/drupal-3402228/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
FAILURES!
Tests: 4, Assertions: 18, Failures: 1.

Which shows the issue of the first error not showing.

The fix provided seems to work, if that's the one you want to go forward with could you update the proposed solution section please.

We need to ensure this works consistently with how >1 constraint violation on a single content entity field item property is presented. So we need to research that first.

I'm trying to figure out how to get a content entity even set up in such a way that I could violate two conditions of a particular field type. It's not easy.

But, a review of the code reveals this, in \Drupal\Core\Field\WidgetBase::flagErrors()

          if (is_numeric($delta)) {
            $violations_by_delta[$delta][] = $violation;
          }
          // Violations at the ItemList level are not associated to any delta.
          else {
            $item_list_violations[] = $violation;
          }

That is very, very similar to what I'm proposing here.

OK, so I had to contrive this a bit, but I tested how it works on content entity forms.

Short answer: If there are multiple violations on a single field, only one appears to be displayed. That is terrible UX, a perfect way to make people hate Drupal, and should be fixed ASAP in another issue.

How I tested

I changed \Drupal\Core\Field\Plugin\Field\FieldType\StringItem::getConstraints() so that it both checks the maximum length of the input, and prevents the input value from starting with a number. Here was the code I used for that:

      $constraints[] = $constraint_manager->create('ComplexData', [
        'value' => [
          'Length' => [
            'max' => $max_length,
            'maxMessage' => $this->t('%name: may not be longer than @max characters.', ['%name' => $this->getFieldDefinition()->getLabel(), '@max' => $max_length]),
          ],
          'Regex' => [
            'pattern' => '/^\d/',
            'match' => false,
            'message' => $this->t('Cannot start with a number.'),
          ],
        ],
      ]);

Then I disabled the #maxlength property in the form system, and in the string_textfield widget, by commenting out a line or two in \Drupal\Core\Form\FormValidator::performRequiredValidation(), \Drupal\Core\Render\Element\Textfield::getInfo(), and \Drupal\Core\Field\Plugin\Field\FieldWidget\StringTextfieldWidget::formElement().

I then went to /node/add/article (on a standard install) and entered this value for the title of the node, which is a string_textfield (bear in mind I had to use the inspector to remove the maxlength attribute added by default):

99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;99 red balloons;

Here's what I saw when I tried to submit the form:

There should have been two errors, not one, because that input string is longer than the field's default maximum length of 128
characters. I disabled the length validation at the form level, you see, but not at the constraint (data) level.

So it would appear that my supposition in #7 was incorrect.

Conclusion

Look...if you want as many people as possible to hate Drupal as much as possible, we should keep this UX exactly the way it is. There is nothing, N O T H I N G, more frustrating than getting one error on a field, only to fix it and discover that there was, in fact, another error underneath it that the system didn't tell you about.

This should be fixed for both content entity forms and #config_target-using config forms in this issue.

The current MR would address multiple violations on a non-sequence value, but if an item within a sequence has multiple violations it looks like only the last one will be kept.

ConfigFormBase::formatMultipleViolationsMessage() also assumes it's being called on a sequence, so multiple constraint violations on a non-sequence value would still be formatted like "Entry 0: Constraint 1 message \n Entry 1: Constraint 2 message".
Forms can override the method to change the output based on the form element name in this case though.

To simplify the solution, we can focus directly on collecting error messages for each field without using an index. Instead, we’ll gather each violation message into an array for the field and then concatenate them when setting the error.

• We skip indexing and directly store each violation message under $form_element_name.
• Each field's error messages are combined into a single string in one step with implode(' ', $messages).