Fix missing field/form element/datetime errors on form submission

This is an incorrect change.

We do not like to look for the messages visible to a user. We need to verify if the *tracking code* is shown.

What bullshit patch has changed the text to these useless error messages??? This errors will not explain a user what gone wrong and how I'm able to solve the form error.

I've tested this on simplytest.me, but it is not what we want.

We need the message text in google analytics - not the error counter and field list that has errors.

It looks like this text is now shown below the field that contains the error.

Sorry for confusion.

We need the "Username/Password field is required." (or how it is spelled today) error message that is now shown below the username form field. This string need to be added inside the ga event tracking code.

You may compare to D7 if it is now confusing... It has been broken by core in last 1-2 weeks.

We are not adding new functionality. This is an old feature and if we do not get the error message the old feature is broken. We need to repair this and I do not like to remove the feature. Your change fixes the test, but the feature is still broken.

This suxxx

use \Drupal\Component\Utility\SafeMarkup;

...
    // Add messages tracking.
    $message_events = '';
    if ($message_types = $config->get('track.messages')) {
      $message_types = array_values(array_filter($message_types));
      $status_heading = [
        'status' => t('Status message'),
        'warning' => t('Warning message'),
        'error' => t('Error message'),
      ];

      foreach (google_analytics_get_messages(NULL, FALSE) as $type => $messages) {
      //foreach (drupal_get_messages(NULL, FALSE) as $type => $messages) {
        // Track only the selected message types.
        if (in_array($type, $message_types)) {
          foreach ($messages as $message) {
            // @todo: Track as exceptions?
            $message_events .= 'ga("send", "event", ' . Json::encode(t('Messages')) . ', ' . Json::encode($status_heading[$type]) . ', ' . Json::encode(strip_tags($message)) . ');';
          }
        }
      }
    }
...

function google_analytics_preprocess_fieldset(&$variables) {
  if ($variables['errors'] !== NULL) {
    google_analytics_set_message($variables['errors'], $type = 'error');
  }
}
function google_analytics_preprocess_form_element(&$variables) {
  if ($variables['errors'] !== NULL) {
    google_analytics_set_message($variables['errors'], $type = 'error');
  }
}
function google_analytics_preprocess_datetime_wrapper(&$variables) {
  if ($variables['errors'] !== NULL) {
    google_analytics_set_message($variables['errors'], $type = 'error');
  }
}

function google_analytics_set_message($message = NULL, $type = 'status', $repeat = FALSE) {
  if (isset($message)) {
    if (!isset($_SESSION ['form_messages'][$type])) {
      $_SESSION ['form_messages'][$type] = array();
    }

    $new = array(
      'safe' => SafeMarkup::isSafe($message),
      'form_messages' => $message,
    );
    if ($repeat || !in_array($new, $_SESSION ['form_messages'][$type])) {
      $_SESSION ['form_messages'][$type][] = $new;
    }

    // Mark this page as being uncacheable.
    \Drupal::service('page_cache_kill_switch')->trigger();
  }

  // Messages not set when DB connection fails.
  return isset($_SESSION ['form_messages']) ? $_SESSION ['form_messages'] : NULL;
}

function google_analytics_get_messages($type = NULL, $clear_queue = TRUE) {
  if ($messages = google_analytics_set_message()) {
    foreach ($messages as $message_type => $message_typed_messages) {
      foreach ($message_typed_messages as $key => $message) {
        // Because the messages are stored in the session, the safe status of
        // the messages also needs to be stored in the session. We retrieve the
        // safe status here and determine whether to mark the string as safe or
        // let autoescape do its thing. See drupal_set_message().
        if ($message ['safe']) {
          $message ['form_messages'] = SafeMarkup::set($message ['form_messages']);
        }
        $messages [$message_type][$key] = $message ['form_messages'];
      }
    }
    if ($type) {
      if ($clear_queue) {
        unset($_SESSION ['form_messages'][$type]);
      }
      if (isset($messages [$type])) {
        return array($type => $messages [$type]);
      }
    }
    else {
      if ($clear_queue) {
        unset($_SESSION ['form_messages']);
      }
      return $messages;
    }
  }
  return array();
}

Merged the preprecess functions and merged the drupal_get_messages() with the form messages. Fully untested.

It would be good if core is able to provide the form errors with a function.

Missed to change one function name.

BUGs:

• Form errors seems never deleted.
• Drupal messages are not merged.
• We need a solution to remove the useless Drupal error messages that tells us there are X errors in the form.

This fixes the not cleared messages issue.

It looks like the drupal_get_messages(NULL, FALSE) is now broken in hook_page_attachments() and does not return anything.

The inline patch #2578561: Move "Inline Form Errors" functionality to optional module and restore D7-style form errors by default has been roled back.

We are back to D7 behaviour and the code works again. The feature is now moved to contrib and may come in again in 8.1 or later. Therefore postponed on Drupal 8.1 or later

It wasn't moved to contrib, it is still in core as an optional, "experimental" module. You're right that it won't be back until 8.1 or later though.

So if this "experimental" module is enabled, how will Google Analytics or other contrib modules function? Should modules be coded to work with both? I don't know how much will be different for contrib.

Note, I haven't really had time to look at what was done in Core in the last 5 days.

The feature may need to be removed completly. With html5 form validation the browser manages the validation and drupal do not get notified. As browsers do not run a callback we are totally blind to what type of form errors happend. That is really bad, but I'm not aware of any reliable workaround :-(

Ok, so now that this module has an RC1, does this error still show up when the experimental inline errors module is enabled?

I'm not sure where to look for it. Steps to reproduce it would be terrific.

The sh** got into core now. Unpostponing, but no idea how we may ever fix it if the browser only does form validation and does not interact with the website.

With the sunset of legacy google analytics, the 8.x-2.x module is now unsupported. If this is still an issue with the 4.x version, please file a new issue in the queue.