Настраиваемые формы регистрации для нескольких направлений

Задача

Маркетинговым страницам нужны формы регистрации для нескольких направлений бизнеса. У направлений различаются поля, адресат в CRM и действие после успешной регистрации. Редактор должен менять форму в Elementor без правки PHP и отдельных копий виджета. При этом выбор маршрута и включённые проверки нельзя оставлять на усмотрение браузера: отправитель запроса может изменить любой параметр HTML или JavaScript.

Роль и объём

Реализовал виджет Elementor с настройками формы, отображения, языка, маршрута регистрации, поведения после ответа, CAPTCHA, SMS-подтверждения и отслеживания конверсий. Связал его с несколькими клиентами CRM и общими REST-обработчиками. Отдельные адаптеры передают данные конкретному направлению; этот кейс о настраиваемом виджете и маршрутизации, а не о самописной форме из другого плагина.

Ограничения

Один и тот же виджет используется на разных страницах и может быть настроен по-разному. Требования к SMS и CAPTCHA определяются для конкретного экземпляра формы.
Посадочные страницы могут кешироваться дольше, чем живут nonce и подписанный токен формы. Их обновление нельзя привязывать только к публикации страницы.
Запрос после подтверждения телефона должен попасть в тот же маршрут CRM, который был выбран для формы. Произвольное имя маршрута из запроса принимать нельзя.
Ошибка отправки SMS, неверный код и отказ CRM требуют разных сообщений и следов в журнале.

Архитектура

Страница Elementor
     └── Виджет формы
          ├── поля, язык, вид формы и действие после ответа
          ├── маршрут регистрации и настройки защиты
          └── обновление токена для кешированной страницы
               │
               ▼
Настройки виджета на сервере
     ├── сверка ID виджета и разрешённого маршрута
     └── подписанный токен: маршрут, SMS, CAPTCHA, срок действия
               │
               ▼
REST WordPress
     ├── nonce, токен, лимит запросов, CAPTCHA
     ├── прямой маршрут, если SMS не требуется
     └── SMS: запрос → проверка → расшифрованные данные формы
               │
               ▼
Адаптер выбранного направления → API CRM
     └── дополнительное действие после регистрации, если настроено

Связь между настройкой виджета и обработчиком регистрации проходит через короткоживущий подписанный токен. Его выдаёт отдельный AJAX-запрос с заголовками no-store, поэтому кеш страницы не фиксирует старые условия формы на весь срок кеширования.

Реализация

В редакторе выбираются маршрут CRM, формат показа формы, язык и действие после успешного ответа. Для отдельных экземпляров можно включить CAPTCHA и SMS, если глобальная конфигурация готова. Есть настройки текстов шага подтверждения, таймера повторной отправки и сообщения об ошибках. Виджет также поддерживает событие конверсии и дополнительные сценарии после регистрации, включая связанный с вебинаром.

При выдаче токена сервер находит экземпляр виджета в документе Elementor, сверяет указанный маршрут с его настройкой и формирует подписанные параметры SMS и CAPTCHA. Если виджет не найден, токен не выдаётся. При отправке REST-запроса обработчик проверяет nonce, подпись и срок токена, ожидаемый маршрут, лимит обращений и обязательную CAPTCHA. Если для формы включено SMS, прямой запрос регистрации отклоняется.

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

Виджет использует тот же подход к SMS-проверке, что и самописная форма регистрации, но код находится в двух плагинах. Это перенос и адаптация логики под разные интерфейсы и маршруты CRM, а не общая библиотека, подключённая обоими плагинами во время работы.

Сбои и диагностика

События SMS-проверки записываются в отдельный журнал: отправка, повторная отправка, неверный код, блокировка и успешное подтверждение. Телефон маскируется, номер и IP хешируются; исходный код и содержимое формы не входят в запись аудита. Ошибки транспортного запроса к CRM пишутся отдельно, чтобы отличить сбой интеграции от отказа на этапе подтверждения телефона. Клиент получает результат, по которому может показать состояние формы.

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

границы решения

Проверки SMS и CAPTCHA настраиваются отдельно для каждого виджета и зависят от глобально включённых интеграций. Этот механизм не означает, что все формы сайта всегда требуют обе проверки. Хранилище SMS-сессий и лимитов основано на transients, поэтому при параллельных запросах нет строгой гарантии однократного выполнения. После успешной проверки кода сессия удаляется до обращения к CRM; при её сбое пользователю нужен новый проход подтверждения.

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

Результат

Редактор может собирать разные регистрационные сценарии одним виджетом, а сервер сверяет маршрут и обязательные проверки с настройками конкретного экземпляра. Общая логика защиты работает при разных адаптерах CRM; журнал помогает разбирать сбои SMS и внешнего API. Форма остаётся гибкой для маркетинговых страниц без переноса решения о безопасности в браузер.

Стек

PHP · WordPress · Elementor · REST API · JavaScript · CRM API · SMS API · reCAPTCHA · MySQL