Передавать имя, телефон, email, сообщение, страницу, UTM, ClientID, источник звонка и данные для дедупликации.
CPT, таксономии, ACF, REST API и собственные модули позволяют построить управляемую систему. Но каждый новый плагин или meta-слой имеет стоимость: обновления, совместимость, безопасность и дополнительные запросы.
Сначала собрать исходные данные
В WordPress важно отделить симптом от источника: тема, плагин, запрос к БД, cron, интеграция или сервер могут выглядеть одинаково — «сайт глючит».
- Проверить тему и плагины на дублирование функций.
- Проверить событие submit в браузере и Network.
- Тестировать телефон, email и мессенджер как отдельные каналы.
- Хранить UTM/source/client ID до создания сделки.
Порядок без лишних движений
- Выбрать подходящее хранилище для каждого типа данных.
- Внедрять через staging и rollback.
- Составить карту сущностей и связей.
- Проверить тему и плагины на дублирование функций.
- Измерить SQL, autoload и cron.
- Разделить шаблоны и бизнес-логику.
Что требует отдельного внимания
Хорошая архитектура означает, что контент можно менять без программиста, повторяемые сущности не копируются вручную, интеграции журналируют ошибки, а новая функция не требует переписывать половину темы.
- обновлять production без staging
- делать тяжёлые WP_Query внутри циклов
- отправлять данные в CRM без логов
Самый дорогой путь — лечить архитектурную проблему ещё одним плагином, не понимая, что уже происходит в теме и базе.
Тест перед production
Перед публикацией я бы повторил не только изменённый шаг, но и соседние сценарии: мобильную версию, формы, аналитику, интеграции и страницы того же шаблона.
- число SQL-запросов
- autoload size
- время PHP-ответа
- ошибки интеграций
Что зафиксировать на будущее
После работы должны остаться понятные доступы, зафиксированные изменения и способ повторно проверить результат.
Если эту задачу нужно внедрить, а не только разобрать
Можно собрать план внедрения, проверить зависимости и довести изменение до работающего production-сценария.