Как добавить пользовательский обработчик проверки в существующую форму / поле?

Как добавить собственный обработчик проверки в существующую форму (или поле формы) в Drupal 8?

У меня есть форма, которую я не создал. Я хочу добавить свои собственные правила проверки для некоторых полей при отправке формы.

Для Drupal 7, Пользовательская проверка формы? объясняет, как реализовать, hook_form_alter()а затем добавить ваш обработчик проверки] [1] в $form['#validate']массив, но в Drupal 8 формы являются классами. Проверка выполняется с помощью validateForm()метода, и я не знаю, как подключить мой код к этому.

Это #validateсвойство все еще используется в Drupal 8. (С помощью решения Adi вы переопределите существующий валидатор)

Если вы хотите добавить свой пользовательский валидатор в дополнение к стандартному, вы должны добавить что-то вроде этого в hook_form_FORM_ID_alter (или аналогичный):

$form['#validate'][] = 'my_test_validate';

Бердир дал правильный ответ, что ограничение - это правильный путь добавления валидации к полю в Drupal 8. Вот пример.

В приведенном ниже примере я буду работать с узлом типа podcast, который имеет поле с одним значением field_podcast_duration. Значение для этого поля должно быть отформатировано как ЧЧ: ММ: СС (часы, минуты и секунды).

Чтобы создать ограничение, необходимо добавить два класса. Первый - это определение ограничения, а второй - это валидатор ограничения. Оба они являются плагинами в пространстве имен Drupal\[MODULENAME]\Plugin\Validation\Constraint.

Во-первых, определение ограничения. Обратите внимание, что идентификатор плагина задан как «PodcastDuration» в аннотации (комментарии) класса. Это будет использовано ниже.

namespace Drupal\[MODULENAME]\Plugin\Validation\Constraint;

use Symfony\Component\Validator\Constraint;

/**
 * Checks that the submitted duration is of the format HH:MM:SS
 *
 * @Constraint(
 *   id = "PodcastDuration",
 *   label = @Translation("Podcast Duration", context = "Validation"),
 * )
 */
class PodcastDurationConstraint extends Constraint {

  // The message that will be shown if the format is incorrect.
  public $incorrectDurationFormat = 'The duration must be in the format HH:MM:SS or HHH:MM:SS. You provided %duration';
}

Далее нам нужно предоставить валидатор ограничения. Это имя этого класса будет именем класса сверху, с Validatorдобавлением к нему:

namespace Drupal\[MODULENAME]\Plugin\Validation\Constraint;

use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;

/**
 * Validates the PodcastDuration constraint.
 */
class PodcastDurationConstraintValidator extends ConstraintValidator {

  /**
   * {@inheritdoc}
   */
  public function validate($items, Constraint $constraint) {
    // This is a single-item field so we only need to
    // validate the first item
    $item = $items->first();

    // If there is no value we don't need to validate anything
    if (!isset($item)) {
      return NULL;
    }

    // Check that the value is in the format HH:MM:SS
    if (!preg_match('/^[0-9]{1,2}:[0-5]{1}[0-9]{1}:[0-5]{1}[0-9]{1}$/', $item->value)) {
      // The value is an incorrect format, so we set a 'violation'
      // aka error. The key we use for the constraint is the key
      // we set in the constraint, in this case $incorrectDurationFormat.
      $this->context->addViolation($constraint->incorrectDurationFormat, ['%duration' => $item->value]);
    }
  }
}

Наконец, нам нужно указать Drupal использовать наше ограничение field_podcast_durationна podcastтип узла. Мы делаем это в hook_entity_bundle_field_info_alter():

use Drupal\Core\Entity\EntityTypeInterface;

function HOOK_entity_bundle_field_info_alter(&$fields, EntityTypeInterface $entity_type, $bundle) {
  if (!empty($fields['field_podcast_duration'])) {
    $fields['field_podcast_duration']->addConstraint('PodcastDuration');
  }
}

Правильный способ сделать это для объекта содержимого, такого как узел, - зарегистрировать его как ограничение.

Видишь forum_entity_bundle_field_info_alter()и соответствующий? ForumLeafограничение проверки (обратите внимание, что нужны два класса).

Сначала это немного сложнее, но преимущество заключается в том, что он интегрирован в API валидации, поэтому ваша валидация не ограничивается системой форм, но может, например, работать и с узлами, отправленными через REST API.

Я хочу добавить немного света по этому вопросу. Добавление валидации точно такое же, как и раньше: в hook_form_alter:

$form['#validate'][] = '_form_validation_number_title_validate';

Использование объекта values ​​внутри $ form_state в функции validate немного отличается. например:

function _form_validation_number_title_validate(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {

  if ($form_state->hasValue('title')) {
     $title = $form_state->getValue('title');

     if (!is_numeric($title[0]['value'])) {
        $form_state->setErrorByName('title', t('Your title should be number'));
     }

  }
}

Так что не с прямым доступом к объекту приватных переменных, а скорее с функцией получения.

для получения дополнительной информации вы можете увидеть полный пример в моем github: https://github.com/flesheater/drupal8_modules_experiment/blob/master/webham_formvalidation/webham_formvalidation.module

ура!

Это очень похоже на D7. Полный пример:

mymodule.module :

use Drupal\Core\Form\FormStateInterface;

/**
 * Implements hook_form_FORM_ID_alter() for the FORM_ID() form.
 */
function mymodule_form_FORM_ID_alter(&$form, FormStateInterface $form_state, $form_id) {
  $form['#validate'][] = '_mymodule_form_FORM_ID_validate';
}

/**
 * Validates submission values in the FORM_ID() form.
 */
function _mymodule_form_FORM_ID_validate(array &$form, FormStateInterface $form_state) {
  // Validation code here
}

В дополнение к этим хорошим ответам я бы добавил:

$form['#validate'][] = 'Drupal\your_custom_module_name\CustomClass::customValidate';

Это как вызвать метод удаленного класса для проверки формы. Я думаю, что лучше, чем вызывать вышеуказанную функцию в файле модуля, как в приведенном примере.

Вы можете использовать модуль проверки клиента . Еще несколько подробностей об этом (со страницы проекта):

... добавляет проверку на стороне клиента (также известную как «Проверка формы Ajax») для всех форм и веб- форм, использующих jquery.validate . Включенный файл jquery.validate.js пропатчен, потому что нам нужно было иметь возможность скрывать пустые сообщения.