Форма в MODX: рабочие приёмы для FormIt

Форма обратной связи в MODX часто ломается не вёрсткой, а на стыке FormIt, проверок полей и почтовой отправки: посетитель видит сообщение об успехе, а заявка не доходит. Ниже — приёмы для MODX Revolution 2.x и 3.x с установленным дополнением FormIt; синтаксис и доступные параметры сверяйте с версией FormIt на сайте.

Сначала разделите форму на три задачи

FormIt принимает данные, проверяет их по правилам и запускает обработчики — hooks. Например, hook email отправляет письмо, а redirect перенаправляет посетителя. Это не одно и то же: успешная проверка ещё не доказывает, что письмо доставлено.

Перед настройкой проверьте, что дополнение FormIt установлено и вызывается как сниппет, форма отправляет запрос методом POST, а на сервере настроена отправка почты. Для диагностики понадобятся доступ к MODX Manager и возможность посмотреть журналы MODX и почтового сервера. В примерах ниже адрес получателя — условный: замените его адресом своего проекта.

Термин: hook — обработчик, который FormIt запускает после валидации. Ошибка в hook может сорвать обработку, даже если поля заполнены верно.

Приём 1. Свяжите поля, плейсхолдеры и правила

У каждого поля должны совпадать имя в HTML, имя в правилах проверки и имя плейсхолдера, если вы повторно показываете введённое значение. Иначе FormIt проверит одно поле, а шаблон выведет другое — особенно неприятно после ошибки.

<form action="[[~[[*id]]]]" method="post">
  <label for="name">Имя</label>
  <input id="name" name="name" value="[[!+fi.name]]">
  <span>[[!+fi.error.name]]</span>

  <label for="email">Электронная почта</label>
  <input id="email" name="email" type="email" value="[[!+fi.email]]">
  <span>[[!+fi.error.email]]</span>

  <label for="message">Сообщение</label>
  <textarea id="message" name="message">[[!+fi.message]]</textarea>
  <span>[[!+fi.error.message]]</span>

  <button type="submit">Отправить</button>
</form>

Вызов сниппета разместите на странице с формой. Пример использует распространённые параметры FormIt; точный набор параметров и синтаксис проверяйте по документации установленной версии.

[[!FormIt?
  &hooks=`email`
  &emailTo=`YOUR_RECIPIENT@example.com`
  &emailSubject=`Заявка с сайта`
  &emailTpl=`ContactEmailTpl`
  &validate=`name:required,email:required:email,message:required`
  &validationErrorMessage=`Проверьте заполнение полей.`
  &successMessage=`Сообщение отправлено.`
]]

ContactEmailTpl — имя чанка с шаблоном письма. В нём используйте плейсхолдеры FormIt для нужных полей и проверьте результат реальной отправкой. Не помещайте введённые посетителем данные в письмо как доверенные инструкции для дальнейшей автоматической обработки.

Проверка результата: отправьте пустую форму — обязательные поля должны получить ошибки; заполните поля корректно — форма должна показать сообщение об успехе, а письмо должно прийти на адрес получателя. Эти две проверки ловят разные классы проблем.

Приём 2. Выбирайте обработчик под задачу

Если достаточно письма, начните с встроенного hook email. Если перед отправкой нужно сохранить заявку, изменить данные или выполнить собственную проверку, потребуется дополнительная логика — например, подходящий для задачи hook или отдельное расширение. Чем больше самописной логики, тем больше мест, которые придётся тестировать после обновления.

Для обычной заявки не усложняйте цепочку обработчиков заранее. Для критичных обращений одной почты может быть мало: письмо способно задержаться или попасть в спам. Сначала решите, где заявка должна храниться и кто отвечает за контроль её доставки.

Приём 3. Считайте браузер помощником, а не охранником

Атрибуты HTML вроде required и type="email" помогают посетителю заметить опечатку, но серверную проверку не заменяют: запрос можно отправить в обход страницы. Поэтому правила FormIt должны покрывать обязательность и формат важных полей независимо от интерфейса.

Не выводите введённый текст без экранирования в HTML-страницу или письмо. В частности, избегайте вывода данных через контексты, отключающие фильтрацию, если вы точно не контролируете содержимое. FormIt и MODX поддерживают разные способы вывода плейсхолдеров; конкретный механизм экранирования выбирайте по контексту и документации вашей версии.

Сообщение «форма отправлена» — это ещё не подтверждение, что заявка дошла до человека. Проверяйте весь путь: браузер, FormIt, почтовую конфигурацию и ящик получателя.

Как выбрать подход и что чаще ломается

Встроенный email-hook подходит для простого уведомления. Когда заявка должна попадать в CRM или базу, выбирайте интеграцию с подтверждаемым результатом и предусмотрите способ найти потерянное обращение. Не добавляйте обработчик только потому, что он доступен: каждый новый шаг усложняет диагностику.

• Ошибки показываются не у тех полей. Сверьте атрибуты name с правилами validate и плейсхолдерами fi.error.*.
• Пустая форма проходит. Проверьте, что вызов FormIt обрабатывает именно отправляемую форму, а правила указаны для актуальных имён полей.
• Успех есть, письма нет. Проверьте почтовую отправку на сервере, папку спама, адрес получателя и журнал ошибок. Настройка формы сама по себе не настраивает почтовую инфраструктуру.
• После правки показывается старая версия. Проверьте кеш MODX и кеширование страницы на хостинге или CDN; затем повторите отправку в приватном окне.
• Форма отправляется повторно. Не считайте отключение кнопки защитой от повторного запроса. Если повторная заявка создаёт проблему, обработайте дубли на уровне логики или системы, куда сохраняются данные.

Что проверить после публикации

Отправьте форму с пустыми полями, с некорректным адресом и с обычной заявкой. Затем проверьте письмо, отображение ошибок и повторную отправку после обновления страницы. Отдельно проверьте форму на мобильном устройстве: длинное сообщение об ошибке не должно скрываться за кнопкой или соседним блоком.

Если используете сторонние hooks или дополнения, повторите тесты после их обновления и после смены версии MODX. Инвалидация кеша и защита от автоматического спама — отдельные темы; здесь важно хотя бы не считать серверную валидацию и работающую почту само собой разумеющимися.

Что делать дальше

Зафиксируйте для каждой формы три ожидаемых результата: какие данные проходят проверку, куда попадает заявка и как вы узнаете о сбое. Затем настройте отправку тестовой заявки после изменений сайта и следите не только за сообщением об успехе, но и за фактическим получением или сохранением обращения.