Конструктор форм с drag-and-drop: заявки и опросы без Contact Form 7

На прошлой неделе я считал плагины на одном из клиентских сайтов. Обычный WooCommerce-магазин, промышленное оборудование, ничего экзотического. И вот смотрю на список активных плагинов — а там ради одной формы обратной связи стоит Contact Form 7, к нему Conditional Fields, к нему Flamingo для хранения заявок, к нему ещё File Upload для загрузки файлов, и вишенка на торте — какой-то платный аддон для красивого оформления, потому что стандартные формы CF7 выглядят так, будто их верстали в девяносто восьмом году. Пять плагинов. Пять потенциальных точек отказа. Пять источников обновлений, каждое из которых может что-нибудь сломать. И всё это ради того, чтобы клиент мог написать «Хочу узнать цену на гидравлическое масло, вот мой телефон».

Я тогда задумался — почему так получилось? Почему WordPress-сообщество привыкло к тому, что для решения одной задачи нужно собирать конструктор из пяти-шести разных плагинов, каждый из которых написан разным автором, обновляется в разное время и совместим с другими только до тех пор, пока никто ничего не обновил? Ведь форма обратной связи — это, казалось бы, одна из самых базовых вещей в интернете. Человек заполнил поля, нажал кнопку, данные улетели менеджеру. Что тут сложного? Но стоит копнуть чуть глубже — добавить условную логику, загрузку файлов, хранение заявок в базе данных, нормальные уведомления — и простая задача превращается в инженерный проект по интеграции зоопарка расширений.

Именно этот опыт подтолкнул нас к созданию собственного конструктора форм внутри COS WP Woo. Не ещё одного плагина для форм — мир их видел достаточно — а встроенного модуля, который решает задачу целиком. С визуальным drag-and-drop построителем, условной логикой, хранением заявок, email-уведомлениями и вставкой через шорткод. Всё в одном, без зависимостей, без конфликтов версий, без ежегодных подписок на каждый аддон отдельно. И сегодня я хочу рассказать, как это устроено изнутри, почему мы приняли именно такие решения и чем наш подход отличается от того, к чему все привыкли.

Но прежде чем погружаться в технические детали, давайте честно поговорим о том, что не так с существующими решениями. Не для того, чтобы кого-то обидеть — Contact Form 7 сделал огромную работу для экосистемы WordPress и заслуживает уважения. Но именно понимание проблем помогает оценить, зачем вообще нужна альтернатива.

Contact Form 7 — это плагин, который появился в 2007 году. Девятнадцать лет назад. За это время он был скачан более 340 миллионов раз, и его используют на миллионах сайтов. Но вот в чём штука — его архитектура осталась, по сути, той же самой. Формы описываются через текстовые шаблоны с тегами вроде [text* your-name] и [email* your-email]. Без визуального редактора. Без предпросмотра. Ты пишешь код формы в текстовом поле, сохраняешь, идёшь на страницу и смотришь — похоже на то, что хотел, или нет. И так по кругу. Для разработчика это терпимо. Для менеджера или маркетолога, который хочет поменять форму на сайте — это стена. Непроходимая стена из квадратных скобок и непонятных параметров.

И это только начало. Хочешь, чтобы одно поле показывалось в зависимости от выбора в другом? Ставь Conditional Fields. Хочешь, чтобы заявки сохранялись в базе данных, а не просто улетали на почту? Ставь Flamingo. Хочешь, чтобы клиент мог прикрепить PDF или фото? Ставь File Upload. Хочешь нормальные стили? Ставь CF7 Skins или пиши CSS руками. Каждая из этих задач — отдельный плагин с отдельным автором, отдельным циклом обновлений и отдельной лицензией. На одном проекте я насчитал семь плагинов, связанных с Contact Form 7. Семь. И менеджер проекта жаловался, что после обновления WordPress до 6.5 три формы перестали работать, потому что один из аддонов оказался несовместим. Знакомая история?

Конечно, есть платные альтернативы — WPForms, Gravity Forms, Formidable Forms. Они решают многие проблемы CF7: визуальный редактор, условная логика, хранение заявок — всё в одном пакете. Но за это просят деньги. WPForms Pro — 199 долларов в год. Gravity Forms — 259 долларов. И это для одного сайта. Если у вас десять проектов — умножайте. А если вам параллельно нужны ещё и WooCommerce-расширения для B2B, поиска, доставки, безопасности — бюджет на плагины начинает выглядеть неприлично. Я работал с компанией, которая платила суммарно больше полутора тысяч долларов в год только за плагины. И формы были далеко не самой дорогой позицией.

Зачем строить формы внутри WooCommerce-плагина

Честно говоря, когда мы планировали модуль форм для COS WP Woo, внутри команды были споры. Аргумент против звучал примерно так: «Формы — это отдельная вселенная, зачем тащить их в e-commerce плагин?» И аргумент был не лишён смысла. Формы — действительно сложная тема, у них свои паттерны UX, свои требования к безопасности (CSRF, XSS, валидация), свои нюансы хранения данных. Но чем больше я работал с реальными WooCommerce-магазинами, тем яснее становилось: формы — это неотъемлемая часть интернет-магазина. Не что-то внешнее, прикрученное сбоку, а органичный элемент.

Подумайте сами. Форма запроса КП — куда она должна вести? В CRM менеджера по продажам, которая завязана на WooCommerce. Форма заявки на подбор аналога — она должна знать о каталоге товаров. Форма обратного звонка — она должна появляться в контексте товарной страницы. Форма опроса удовлетворённости — она привязана к заказу. Всё это не абстрактные «формы на сайте», а элементы торгового процесса. И когда они живут в отдельном плагине, вы теряете контекст. Менеджер видит заявку в Flamingo, но не видит, с какой страницы она пришла и какой товар клиент смотрел. Или видит, но через костыли — скрытые поля, UTM-метки, передача параметров через URL. Всё это работает, пока работает. А потом ломается, и никто не понимает почему.

Поэтому мы решили: формы — это часть платформы. Не аддон, не интеграция, а встроенный модуль, который знает всё о WooCommerce-контексте. Который хранит данные в тех же кастомных таблицах, что и остальные модули. Который отправляет email через тот же SMTP-модуль, что уже настроен в плагине. Который управляется через тот же React-интерфейс, к которому привык администратор. Это решение определило архитектуру всего, что было дальше.

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

Когда вы открываете модуль Forms в админке COS WP Woo (путь: Store — Forms), вы видите список всех форм. Это таблица с названиями, количеством полей, статусом и количеством полученных заявок. Всё просто и понятно. Нажимаете «Создать форму» — и попадаете в полноэкранный конструктор. И вот тут начинается самое интересное.

Полноэкранный режим — это осознанное решение. Мы долго экспериментировали с разными подходами: встроенный редактор в боковой панели, модальное окно, отдельная страница в стандартном WordPress-лейауте. И пришли к выводу, что конструктор форм должен занимать весь экран. Почему? Потому что вы строите визуальный объект. Вам нужно видеть, как форма будет выглядеть, в реальном масштабе. Вам нужно пространство для перетаскивания полей, для настройки условий, для предпросмотра. Зажатый в боковую панель WordPress конструктор — это как рисовать картину через замочную скважину. Можно, но зачем?

Полноэкранный холст и перетаскивание полей

Конструктор разделён на три зоны. Слева — панель доступных типов полей. По центру — холст формы, где поля расположены в том порядке, в котором их увидит пользователь. Справа — панель настроек выбранного поля. Такой трёхколоночный layout знаком любому, кто работал с Figma, Canva или даже PowerPoint. Это интуитивный паттерн, который не требует обучения.

Доступные типы полей покрывают практически все сценарии, которые я встречал в реальных проектах. Текстовое поле — для имени, темы обращения, свободного комментария. Числовое поле — для количества, объёма, бюджета. Email — с автоматической валидацией формата. Телефон — с маской ввода, чтобы номер приходил в единообразном формате. Textarea — для развёрнутых сообщений. Выпадающий список (Select) — когда нужно ограничить выбор конкретными вариантами: тип оборудования, регион доставки, способ связи. Чекбоксы — для множественного выбора: интересующие услуги, желаемые характеристики. Радиокнопки — когда нужно выбрать ровно один вариант. Дата — с календарём для выбора желаемой даты доставки или консультации. Загрузка файла — для чертежей, техзаданий, фотографий. И даже поле подписи — для мобильных пользователей, которые могут расписаться пальцем прямо на экране. Это, кстати, оказалось неожиданно востребованным в формах актов приёмки и заявок на гарантийный ремонт.

Каждое поле — это React-компонент, который рендерится на холсте ровно так, как его увидит посетитель сайта. Никакого «предпросмотра в новой вкладке» — вы видите результат прямо в процессе работы. Перетащили поле из левой панели на холст — оно появилось. Кликнули на него — справа открылись настройки: label, placeholder, обязательность, ширина (полная или половинная для двухколоночных макетов), значение по умолчанию, текст подсказки. Всё это меняется в реальном времени — поправили label справа, и на холсте он тут же обновился.

Для реализации drag-and-drop мы используем библиотеку @hello-pangea/dnd — это форк @hello-pangea, который сам является продолжением react-beautiful-dnd от Atlassian. Выбор не случайный. Мы перепробовали несколько вариантов: react-dnd, dnd-kit, Sortable.js с React-обёрткой. У каждого были свои плюсы, но @hello-pangea/dnd победил по сочетанию факторов. Он даёт отличный тактильный feedback — элемент «отрывается» от панели, следует за курсором, а на холсте появляется placeholder, показывающий, куда элемент встанет. Он корректно работает с сенсорными экранами — а это важно, потому что всё больше людей управляют сайтами с планшетов. И он не требует написания собственных collision-алгоритмов, которые в dnd-kit пришлось бы настраивать вручную.

Но визуальный конструктор — это только внешняя часть. Под капотом каждая форма — это JSON-структура, которая хранит описание всех полей, их порядок, настройки и правила валидации. Когда вы сохраняете форму, этот JSON сохраняется в таблицу wpaic_forms. Когда посетитель открывает страницу с формой, PHP-код на бэкенде считывает JSON и генерирует HTML с правильной разметкой, валидацией и JavaScript-обработчиками. Это означает, что форма работает даже если React-часть плагина не загружена — она полностью серверная на фронтенде. Никаких задержек рендеринга, никаких проблем с SEO.

И вот тут я хочу остановиться на моменте, который многие создатели форм игнорируют. Предпросмотр в реальном времени — это не просто удобство. Это предотвращение ошибок. Когда менеджер строит форму в текстовом режиме, как в CF7, он не видит результат. Он угадывает. И потом удивляется, что поле «Комментарий» оказалось перед полем «Имя», или что чекбоксы расположились в столбик вместо строки, или что на мобильном форма выглядит как длинная простыня. С визуальным конструктором эти ошибки невозможны — вы видите ровно то, что увидит клиент. И это экономит часы. Я знаю, потому что сам провёл эти часы, ковыряясь в шаблонах CF7 и обновляя страницу в браузере снова и снова.

Теперь поговорим о том, что делает формы по-настоящему мощными — условная логика. Представьте форму заявки на подбор масла. Первый вопрос: «Тип оборудования» — выпадающий список: Автомобили, Промышленное оборудование, Гидравлика, Другое. Если клиент выбирает «Автомобили», появляются поля «Марка» и «Модель». Если выбирает «Промышленное оборудование» — появляются «Тип механизма» и «Условия эксплуатации». Если «Другое» — текстовое поле для свободного описания. Без условной логики вам пришлось бы показывать все поля сразу, и форма превращалась бы в анкету на две страницы, от которой клиент убежит, не заполнив.

В Contact Form 7 для этого нужен отдельный плагин Conditional Fields, который работает через CSS-хаки и JavaScript-обработчики, нередко конфликтующие с другими скриптами на странице. Мы же встроили условную логику прямо в конструктор. В настройках каждого поля есть раздел «Условия показа». Вы просто выбираете: «Показывать это поле, если поле [Тип оборудования] равно [Автомобили]». Или «Скрывать это поле, если поле [Бюджет] меньше 10000». Можно комбинировать несколько условий через «И» или «ИЛИ». Интерфейс для этого — визуальный билдер правил, похожий на тот, что мы используем для кастомных полей в модуле CF. Никакого кода, никаких текстовых формул.

Условная логика обрабатывается на стороне клиента через JavaScript, который генерируется автоматически из JSON-описания формы. Это значит, что поля появляются и скрываются мгновенно, без перезагрузки страницы, без AJAX-запросов. Пользователь выбрал вариант в списке — и нужные поля плавно появились. Выбрал другой — предыдущие скрылись, новые показались. Это создаёт ощущение интерактивного интерфейса, а не статичной HTML-формы. И, что важно, скрытые поля не участвуют в валидации — если поле скрыто условием, оно не будет считаться обязательным, даже если отмечено как required. Это тонкий момент, на котором спотыкаются многие реализации.

Я помню проект, где мы использовали WPForms с условной логикой, и столкнулись с багом: скрытое обязательное поле блокировало отправку формы, потому что его валидация срабатывала даже когда поле было невидимо. Клиент не мог отправить форму и уходил. Мы потеряли заявки, пока не разобрались и не написали костыль на JavaScript. Это один из тех уроков, которые запоминаются надолго. Поэтому в нашей реализации скрытые поля исключаются из валидации на уровне архитектуры — это не фикс бага, а фундаментальное правило.

Заявки — не в почту, а в базу данных

Вот мы подошли к теме, которая, на мой взгляд, является главным слабым местом Contact Form 7 и подобных бесплатных решений. Куда деваются заявки? В CF7 ответ простой — на почту. Пришла заявка, отправился email менеджеру. Точка. Нет email — нет заявки. А email-сервера имеют свойство терять письма. Спам-фильтры имеют свойство блокировать уведомления от WordPress, особенно если сервер не настроен идеально — нет SPF-записи, нет DKIM, нет DMARC. Я лично знаю три случая, когда бизнес терял заявки неделями, потому что уведомления с Contact Form 7 попадали в спам на почтовом сервере. И никто не знал об этом, пока клиенты не начали звонить с претензиями: «Я оставил заявку, почему никто не перезвонил?»

Flamingo решает эту проблему — он сохраняет заявки в базе данных WordPress. Но это отдельный плагин, со своим интерфейсом, своей логикой хранения и своими ограничениями. Заявки хранятся как кастомные посты (post_type), что создаёт нагрузку на таблицу wp_posts, которая на крупных сайтах и без того раздута. На одном из наших проектов с 16 тысячами товаров таблица wp_postmeta весит 937 мегабайт — и добавлять туда ещё и заявки из форм было бы безумием.

Мы пошли другим путём. Все заявки хранятся в кастомной таблице wpaic_form_entries. Это выделенная таблица с оптимальной структурой: ID записи, ID формы, данные заявки в JSON-формате, дата создания, статус (новая, прочитана, в работе, закрыта), IP-адрес отправителя, User-Agent, ID пользователя (если авторизован). Кастомная таблица — это не прихоть, это осознанное архитектурное решение. Она не засоряет wp_posts, имеет правильные индексы для быстрого поиска и фильтрации, и масштабируется линейно — десять тысяч заявок работают так же быстро, как десять.

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

И, разумеется, экспорт. Формы без экспорта — как CRM без отчётов. Бесполезно. Мы поддерживаем экспорт в CSV с выбором полей, фильтрацией по дате и статусу. Выгрузили CSV, открыли в Excel или Google Sheets, проанализировали — какие товары чаще запрашивают, из каких регионов приходят заявки, какие формы конвертируют лучше. Это данные, которые вы теряете, когда заявки живут только в почте.

Есть ещё один нюанс, о котором редко говорят. Когда заявки хранятся в базе данных, у вас появляется аудит. Вы точно знаете, сколько заявок пришло. Не «примерно», не «судя по почте», а точно. Менеджер не может сказать «заявки не было» — она зафиксирована в системе с датой, временем, IP-адресом и всеми данными. Это особенно важно для B2B-компаний, где каждая заявка может стоить сотни тысяч рублей. Потерять такую заявку из-за спам-фильтра — это не просто неудобство, это прямые убытки.

Но давайте будем честными — email-уведомления тоже нужны. Не все менеджеры будут заходить в админку WordPress каждый час, чтобы проверить новые заявки. Поэтому мы реализовали двойную систему: заявка всегда сохраняется в базу данных (это гарантия), и параллельно отправляется email-уведомление (это оперативность). Причём email отправляется через встроенный SMTP-модуль COS WP Woo, который вы настраиваете один раз в разделе Email Settings. Никаких отдельных SMTP-плагинов, никакого WP Mail SMTP за 49 долларов в год. Один модуль SMTP для всего — уведомлений о заказах, уведомлений о заявках, уведомлений безопасности.

Email-уведомления настраиваемые. Для каждой формы вы определяете: кому отправлять уведомление менеджеру (можно несколько адресов), какой шаблон использовать, какие данные включить. И отдельно — уведомление клиенту: «Спасибо, ваша заявка принята, мы свяжемся с вами в течение 24 часов». Клиентское уведомление отправляется на email, указанный в поле типа «Email» — плагин автоматически определяет, какое поле содержит адрес получателя. Шаблоны писем — HTML с плейсхолдерами: {{field_name}}, {{form_title}}, {{submission_date}}. Можно кастомизировать внешний вид, добавить логотип компании, контактные данные. Писали мы не универсальный шаблонизатор, а целевой инструмент для конкретной задачи — поэтому он работает предсказуемо и не ломается от нестандартных конструкций.

Расскажу ещё об одном техническом решении, которое может показаться мелочью, но на практике экономит нервы. Загрузка файлов. В Contact Form 7 с плагином File Upload файлы прикрепляются к email как вложения. Это работает, пока кто-нибудь не пришлёт файл на 25 мегабайт, который ваш почтовый сервер не пропустит. Или на 50 мегабайт — тогда PHP упадёт с ошибкой memory limit. У нас файлы загружаются в защищённую директорию на сервере (вне публичного доступа, чтобы роботы не скачивали клиентские документы) и привязываются к записи заявки по ID. В email приходит ссылка для скачивания, которая работает только для авторизованных администраторов. Это безопаснее, надёжнее и не зависит от ограничений почтового сервера. Клиент может прикрепить чертёж на 50 мегабайт — и менеджер его получит, гарантированно.

Теперь — шорткоды. Казалось бы, что тут обсуждать? [wpaic_form id="42"] — и форма появилась на странице. Но дьявол, как всегда, в деталях. Шорткод можно вставить в пост, на страницу, в виджет, в попап-плагин, в шаблон темы, даже в описание WooCommerce-товара. Форма адаптируется к контейнеру — если контейнер узкий (sidebar или попап), форма переключается в одноколоночный режим. Если широкий (полноэкранная страница) — поля, настроенные на половинную ширину, встанут в две колонки. Это responsive-поведение, которое работает без дополнительной настройки. Вы не задумываетесь о CSS-медиа-запросах — конструктор сам позаботился.

Знаете, что меня всегда раздражало в подходе CF7 к шорткодам? Там шорткод — это единственный способ вставки. Нет блока Gutenberg, нет виджета Elementor. Шорткод и всё. В 2026 году. Мы тоже начали с шорткода — это самый универсальный механизм WordPress, который работает везде. Но шорткод у нас умный: он принимает параметры для кастомизации внешнего вида. Можно задать тему (светлая, тёмная, прозрачная), можно скрыть заголовок формы, можно задать кастомный текст кнопки отправки. И всё это без единой строчки CSS — через атрибуты шорткода.

Честное сравнение: мы, WPForms, Gravity Forms и CF7

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

Contact Form 7 — бесплатный, лёгкий, проверенный временем. Если вам нужна одна простая форма без условной логики и без хранения заявок — CF7 справится. Его знают все WordPress-разработчики, под него написаны тысячи гайдов. Но как только задача становится чуть сложнее «имя-email-сообщение» — начинается зоопарк плагинов. И стоимость этого зоопарка в поддержке и отладке конфликтов часто превышает стоимость любого платного решения.

WPForms — отличный плагин с великолепным визуальным редактором. Их drag-and-drop один из лучших на рынке. Условная логика, хранение заявок, интеграции с CRM — всё есть. Но WPForms — это отдельный плагин, который решает только задачу форм. Он не знает о вашем WooCommerce-каталоге, не интегрирован с вашей системой доставки, не использует ваш SMTP-модуль. Он существует в своём пузыре. И стоит 199 долларов в год за Pro-версию, которая нужна для условной логики и загрузки файлов. За 5 лет — тысяча долларов только на формы.

Gravity Forms — пожалуй, самый мощный конструктор форм для WordPress. Многошаговые формы, расчёты, интеграции с платёжными системами, Webhooks, потрясающая экосистема аддонов. Но эта мощь имеет цену — и в долларах (259 в год за Elite-лицензию), и в сложности. Gravity Forms может всё, но настройка этого «всего» требует времени и экспертизы. Для простых форм обратной связи это как стрелять из пушки по воробьям.

Наш конструктор форм в COS WP Woo — это золотая середина. Он не претендует на то, чтобы заменить Gravity Forms в сценариях со сложными расчётами или многошаговыми опросами на сотню вопросов. Но он покрывает реальные потребности WooCommerce-магазина на все сто. Формы обратной связи, заявки на подбор, запросы КП, опросы удовлетворённости, анкеты для B2B-регистрации — всё это строится за минуты в визуальном конструкторе. При этом формы — часть единой платформы. Они используют общий SMTP, хранятся в оптимизированных кастомных таблицах, управляются из того же интерфейса, что и все остальные модули. И не стоят дополнительных денег — они входят в лицензию COS WP Woo.

Давайте я приведу конкретный пример из практики. Клиент — дистрибьютор промышленных масел. Ему нужно три формы. Первая — «Запрос цены» на товарных страницах: имя, компания, телефон, email, выпадающий список «Объём партии» (от 20 до 200 литров, от 200 до 1000, от 1000), комментарий. Вторая — «Подбор аналога» на странице каталога: тип оборудования (условная логика для дополнительных полей), текущее масло (текст), желаемые характеристики (чекбоксы), загрузка файла (ТЗ или паспорт оборудования). Третья — «Стать партнёром» на странице «Сотрудничество»: реквизиты компании, ИНН (с валидацией длины), регион, объём закупок, загрузка учредительных документов.

С Contact Form 7 на этот проект ушло бы: CF7 + Conditional Fields + Flamingo + File Upload + стилизация = 5 плагинов и минимум 3 часа настройки (включая правку CSS). С WPForms Pro — 1 плагин, 199 долларов в год, и около часа настройки. С нашим конструктором — 0 дополнительных плагинов, 0 дополнительных расходов, и около 40 минут в визуальном конструкторе. Причём все три формы сразу интегрированы с SMTP, заявки хранятся в единой базе с поиском и экспортом, а менеджер видит их в том же интерфейсе, где управляет всем остальным.

Я хочу рассказать ещё об одном аспекте, который часто упускают при сравнении. Производительность. Contact Form 7 загружает свои стили и скрипты на каждой странице сайта, даже если на ней нет формы. Это известная проблема, которую решают либо дополнительными плагинами (Asset CleanUp, Perfmatters), либо ручной правкой кода. WPForms загружает assets только на страницах с формами, но его JavaScript-бандл весит 60-80 KB в минифицированном виде. Наши формы рендерятся на сервере как чистый HTML с минимальным JavaScript для условной логики и валидации. CSS формы — 5 KB, JavaScript — 8 KB. И загружаются они только на страницах, где шорткод формы фактически присутствует. Для магазина с 16 тысячами товарных страниц разница ощутимая — каждый лишний килобайт CSS и JS умножается на тысячи страниц в кеше, на время парсинга в браузере, на Core Web Vitals.

Отдельно хочу отметить безопасность. Формы — это точка входа для злоумышленников. SQL-инъекции через поля ввода, XSS через текстовые поля, CSRF-атаки через подмену формы, спам-боты, которые заливают тысячи заявок в минуту. Мы обрабатываем все данные через WordPress-функции санитизации: sanitize_text_field(), sanitize_email(), wp_kses_post() для HTML-полей. Каждая форма защищена nonce-токеном. Загружаемые файлы проверяются по MIME-типу и расширению — вы не сможете загрузить PHP-файл, даже если переименуете его в .jpg. А если у вас активирован модуль Security в COS WP Woo, то WAF дополнительно проверяет все входящие данные на паттерны SQL-инъекций и XSS-атак. Это интеграция, которая невозможна, когда формы и безопасность — разные плагины от разных авторов.

И последнее, что я хочу сказать о техническом устройстве. Архитектура модуля форм следует тому же паттерну, что и все остальные модули COS WP Woo: PHP-сервис (FormService) для бизнес-логики, REST-контроллер (FormController) для API, React-страница (FormBuilder) для интерфейса. Сервис зарегистрирован в class-plugin.php, эндпоинты работают через namespace wpaic/v1, данные хранятся в кастомных таблицах. Если вы знакомы с архитектурой нашего плагина — вы уже знаете, как устроены формы. Если нет — формы станут отличной точкой входа, потому что они показывают паттерн в чистом виде: от JSON-описания формы через REST API до рендеринга на фронтенде.

Когда нашего конструктора недостаточно

Я не хочу заканчивать эту статью на маркетинговой ноте «наше решение лучше всех». Это было бы нечестно. Есть сценарии, для которых наш конструктор форм — не лучший выбор.

Если вам нужны многошаговые формы с десятками шагов, прогресс-баром и сохранением промежуточных результатов — посмотрите на Gravity Forms. У них это реализовано зрело и надёжно. Если вам нужна интеграция с CRM вроде HubSpot, Salesforce или AmoCRM из коробки — у WPForms и Gravity Forms есть готовые аддоны, а нам придётся использовать Webhooks или писать кастомную интеграцию. Если вам нужны формы оплаты с интеграцией Stripe или PayPal прямо в форме — это не наш сценарий, для этого у нас есть полноценный WooCommerce-чекаут с модулем оплаты. Если вы строите сложный опросник на 100 вопросов с ветвлением и скорингом — вам нужен специализированный инструмент типа Typeform или Google Forms.

Но если вы — владелец или администратор WooCommerce-магазина, и вам нужны рабочие формы обратной связи, заявок, запросов КП, опросов с условной логикой, загрузкой файлов и хранением в базе данных — наш конструктор форм сделает это быстрее, надёжнее и дешевле, чем любая комбинация из CF7 + аддонов или ежегодная подписка на WPForms Pro.

И знаете, что для меня стало самым убедительным доказательством того, что мы на правильном пути? Не технические метрики, не количество типов полей, не сравнительные таблицы с конкурентами. А тот момент, когда менеджер клиентского проекта — человек, который всю жизнь боялся «залезть в код» — за двадцать минут собрал форму заявки с условной логикой, вставил её на три страницы через шорткод, и на следующий день пришёл с вопросом: «А можно ещё форму для опроса сделать? Я уже примерно понимаю, как». Вот это и есть настоящий показатель качества инструмента — когда человеку не нужна инструкция, не нужен разработчик, и не нужны пять плагинов ради одной формы.

Попробуйте COS WP Woo и соберите свою первую форму за пять минут. Модуль Forms доступен в разделе Store — Forms. Перетащите поля, настройте условия, вставьте шорткод на страницу — и начните получать заявки, которые гарантированно дойдут до менеджера.