Как безопасно менять старую форму заказа и не потерять заявки

Старая форма заказа часто выглядит как обычная HTML-форма, но за ней может стоять половина бизнеса: письмо менеджеру, запись в базу, CRM, оплата, склад, аналитика, промокод, антиспам и уведомления. Если просто “добавить поле” или “переделать кнопку”, можно потерять заявки.

Безопасная правка начинается с фиксации текущего поведения. Нужно понять, что форма делает сейчас, даже если код выглядит странно.

Описать текущий сценарий

Перед изменениями нужно пройти форму как пользователь и записать результат:

• какие поля обязательны;
• какие ошибки показываются;
• что происходит после отправки;
• создаётся ли заказ в базе;
• уходит ли письмо;
• уходит ли заявка в CRM;
• срабатывает ли аналитика;
• есть ли защита от повторной отправки.

Лучше сделать несколько тестов: успешная отправка, пустые поля, неверный телефон, повторная отправка, мобильная версия.

Найти все обработчики

У старой формы может быть несколько слоёв: HTML, JavaScript, AJAX, PHP-обработчик, почтовый шаблон, CRM-интеграция.

grep -R "order" -n templates app local
grep -R "mail(" -n .
grep -R "crm" -n app local
grep -R "fetch(" -n web js

Важно найти не только главный обработчик, но и скрытые побочные эффекты: цели аналитики, SMS, webhooks, сохранение cookie.

Проверить backend validation

Фронтенд-валидация может быть красивой, но она не защищает данные. Сервер должен проверять обязательные поля, телефон, email, состав заказа и цену.

if (empty($data['phone'])) {
    throw new RuntimeException('Телефон обязателен');
}

Если сейчас сервер принимает всё подряд, добавлять новые frontend-поля без backend-проверки опасно.

Логи перед правкой

Перед изменением формы полезно добавить аккуратные логи: старт обработки, успешное создание заказа, отправка письма, ошибка CRM.

Yii::info([
    'event' => 'order_form_submit',
    'source' => 'site',
], 'orders');

В лог не нужно писать полные персональные данные. Достаточно ID заказа, статуса, источника и короткой ошибки.

Не менять всё сразу

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

1. Сначала добавить логирование.
2. Потом обновить валидацию.
3. Затем изменить внешний вид.
4. Отдельно менять интеграцию.

Fallback

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

<form method="post" action="/order/create">
    ...
</form>

JavaScript может улучшать форму, но не должен быть единственным способом передать заказ, если бизнес не готов к такому риску.

Защита от дублей

При повторном клике по кнопке форма может отправиться два раза. Нужно блокировать кнопку на frontend и иметь защиту на backend.

$key = hash('sha256', $phone . '|' . $cartHash . '|' . date('Y-m-d H:i'));

if ($this->isDuplicate($key)) {
    return $existingOrderId;
}

Конкретное правило зависит от проекта. Главное — не создавать два одинаковых заказа от двойного клика.

Проверка после релиза

После правки нужно пройти полный путь заявки:

1. Открыть форму на desktop и mobile.
2. Отправить тестовый заказ.
3. Проверить запись в базе.
4. Проверить письмо менеджеру.
5. Проверить CRM или внешнюю систему.
6. Проверить цель аналитики.
7. Проверить логи ошибок.

Чек-лист

1. Зафиксировать текущее поведение формы.
2. Найти HTML, JS, PHP и интеграции.
3. Проверить backend validation.
4. Добавить логи до серьёзной правки.
5. Не менять дизайн, логику и CRM одним большим коммитом.
6. Оставить fallback, если возможно.
7. Защититься от двойной отправки.
8. Проверить полный путь заявки после релиза.
9. Иметь план быстрого отката.

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