Gravity Forms Nested Forms - Плагин WordPress

Руководство по настройке и применению Gravity Forms Nested Forms

Gravity Forms Nested Forms нужен там, где обычная форма перестаёт быть удобной: пользователь заполняет одну основную заявку, но внутри неё должен добавить несколько однотипных записей - участников, смены, товаров, сотрудников, объектов, строк сметы или получателей. В этом руководстве разберём не рекламное описание, а практику: как спроектировать родительскую и дочернюю форму, какие поля показывать в сводной таблице, как считать итоги, когда обрабатывать уведомления и что проверять, если модальное окно или дочерние записи работают не так, как ожидалось.

Плагин относится к экосистеме Gravity Perks от Gravity Wiz и добавляет в Gravity Forms отдельное поле Nested Form. Через него одна форма вставляется в другую: дочерняя форма собирает повторяемые данные, а родительская хранит общую заявку и связывает с ней дочерние записи. Это не просто "ещё один список полей": у каждой дочерней записи есть собственная структура, проверки, уведомления, записи в админ-панели и потенциальные интеграции.

Материал рассчитан на владельца сайта, администратора WordPress, специалиста по формам или разработчика, который уже понимает базовую работу Gravity Forms. Если вы только выбираете подход, начните с разделов о сценариях и ограничениях. Если плагин уже установлен, переходите к настройке поля, практическому примеру, проверке результата и диагностике.

В статье намеренно нет инструкций по покупке лицензии или обходу активации. Фокус - рабочий сайт, уже доступный плагин, безопасная настройка, проверка данных и решение частых проблем.

Какие задачи решает вложенная форма в Gravity Forms

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

Без Nested Forms такие сценарии обычно решают тремя неудобными способами. Первый - заранее добавить много повторяющихся групп полей: "Участник 1", "Участник 2", "Участник 3" и так далее. Форма становится длинной, часть полей остаётся пустой, условная логика усложняется. Второй - использовать поле списка, но оно удобно только для простых строк, где не нужны отдельные проверки, сложные поля, файлы, расчёты или уведомления. Третий - заставить пользователя отправлять форму несколько раз, что ломает целостность заявки и усложняет обработку в админ-панели.

Gravity Forms Nested Forms предлагает другой подход: родительская форма собирает общую часть заявки, а дочерняя форма открывается в модальном окне и создаёт отдельные дочерние записи. После добавления они отображаются в родительской форме компактной таблицей. Пользователь может добавить, отредактировать или удалить строки до финальной отправки родительской формы.

Где Nested Forms особенно уместен

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

• Регистрация команды, группы, семьи, сотрудников или участников мероприятия из одной заявки.
• Таймшиты, где сотрудник добавляет несколько рабочих интервалов, а родительская форма считает итог.
• Многострочный запрос стоимости, когда каждая позиция имеет количество, параметры, цену или комментарий.
• Заявки на несколько объектов: недвижимость, оборудование, транспорт, документы, обучающие модули.
• Формы с дочерними уведомлениями или интеграциями, где обработку лучше запускать после финальной отправки родительской записи.

Если повторяемый блок состоит из двух простых текстовых колонок, Nested Forms может быть избыточен. В таком случае иногда достаточно поля List или другой более простой возможности конструктора форм. Сильная сторона плагина - не минимальная форма, а управляемая вложенная структура данных.

Кому подходит плагин и где он может оказаться лишним

Gravity Forms Nested Forms подходит сайтам, где Gravity Forms уже является центральным инструментом сбора данных. Это важное условие: плагин не заменяет Gravity Forms, а расширяет его. Он полезен, когда нужно оставить привычный редактор форм, уведомления, записи, экспорт и интеграции Gravity Forms, но добавить повторяемые дочерние записи без ручного программирования собственного интерфейса.

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

Когда решение будет удачным

Решение стоит рассматривать, если вы уже используете Gravity Forms и хотите собирать повторяемые данные внутри одной отправки. Особенно удобно, когда дочерняя форма должна использовать обычные возможности Gravity Forms: условную логику, поля цен, уведомления, динамические значения, ограничения, файлы или интеграции. В таких ситуациях Nested Forms превращает повторяемую часть в самостоятельную мини-форму, но сохраняет её внутри общего сценария.

Когда лучше выбрать другой подход

Плагин может не подойти, если вам нужна вложенность любого уровня, полноценный табличный редактор в стиле электронных таблиц или максимально простая форма без модального окна. В документации Gravity Wiz указано важное ограничение: поле Nested Form нельзя вставить внутрь дочерней формы, которая сама уже используется как вложенная. Если нужна повторяемость внутри повторяемости, придётся пересмотреть структуру, использовать поле списка, нативный Repeater API Gravity Forms для разработческих задач или другой конструктор.

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

Что проверить перед установкой и первым включением

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

Базовая техническая подготовка

Убедитесь, что на сайте установлен и стабильно работает Gravity Forms, а доступ администратора позволяет добавлять плагины, создавать формы, редактировать поля и просматривать записи. Для рабочей страницы формы заранее отключите агрессивное кеширование или подготовьте исключение: по документации Nested Forms загружает дочернюю форму в модальном окне через AJAX, поэтому серверный кеш и оптимизаторы скриптов могут вмешиваться в динамическую разметку.

Если форма будет размещена в конструкторе страниц, всплывающем окне или повторяющемся блоке, проверьте, не встраивается ли одна и та же форма дважды на одной странице. Gravity Forms не поддерживает повторное встраивание одной и той же формы на одной странице, а для Nested Forms это особенно заметно: могут ломаться модальное окно, скрипты и добавление дочерних записей.

Логическая подготовка формы

До добавления поля Nested Form выпишите, какие данные относятся к родительской записи, а какие - к одной дочерней записи. Родительская форма должна содержать общую информацию: контакт ответственного лица, название команды или компании, дату, общий комментарий, итоговую сумму, согласия, выбор сценария. Дочерняя форма должна описывать один повторяемый объект: одного участника, одну смену, одну позицию сметы, одного получателя, один товар или одну запись.

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

Заранее решите, какие поля из дочерней формы нужно показывать в сводной таблице на родительской форме. В документации GravityWiz это настройка Summary Fields. Она не определяет, какие поля есть в модальном окне; она только выбирает колонки, которые пользователь увидит после добавления дочерней записи. Поэтому не нужно выводить всё. Достаточно 3-5 колонок, по которым пользователь быстро узнаёт добавленную запись.

Установка и первичная проверка в WordPress

Общий процесс установки похож на другие плагины WordPress: загрузить ZIP-файл через Plugins - Add New - Upload Plugin, установить и активировать. Если на сайте используется экосистема Gravity Perks, конкретный способ получения и обновления зависит от текущей установки Gravity Wiz, но в рамках настройки формы важнее другое: после активации в редакторе Gravity Forms должно появиться поле Nested Form.

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

Первые действия после активации

1. Откройте Forms в админ-панели WordPress и создайте дочернюю форму для одной повторяемой записи.
2. Добавьте в дочернюю форму поля, которые относятся только к одному объекту: например, имя участника, электронная почта, возраст, роль и комментарий.
3. Создайте родительскую форму с общей частью заявки: контакт ответственного лица, название группы, дата, согласие, общий итог.
4. Добавьте в родительскую форму поле Nested Form и в его настройке выберите созданную дочернюю форму.
5. Заполните Summary Fields, чтобы после добавления дочерней записи пользователь видел понятную сводку.
6. Откройте предпросмотр формы, добавьте две тестовые дочерние записи, отредактируйте одну и удалите другую.
7. Отправьте родительскую форму и проверьте запись в админ-панели.

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

Настройка поля Nested Form: от выбора формы до сводной таблицы

Главная настройка находится не в отдельной странице параметров, а внутри редактора Gravity Forms. Вы добавляете поле Nested Form в родительскую форму и настраиваете его как обычное поле, но с несколькими специфическими параметрами. От этих параметров зависит, насколько понятной будет форма для пользователя и насколько удобно администратору будет разбирать записи.

Выбор дочерней формы

Параметр Nested Form выбирает форму, которая будет открываться в модальном окне. Она должна быть самостоятельной и логически полной: в ней должны быть все поля, нужные для одной дочерней записи. Не добавляйте в неё поля, которые пользователь должен заполнить один раз на всю заявку. Чем точнее разделение, тем легче потом считать итоги, экспортировать данные и объяснять форму пользователю.

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

Summary Fields вместо лишней таблицы

Summary Fields - одна из самых важных настроек. Она определяет, какие поля дочерней записи отображаются в таблице родительской формы. В официальной документации GravityWiz подчёркивает, что этот параметр влияет только на таблицу в родительской форме, а модальное окно всё равно показывает все поля дочерней формы. Это полезное разделение: внутри модального окна можно собрать полные данные, а в родительской форме показать только короткую сводку.

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

Row ID и подписи записей

Специальное поле Row ID в Summary Fields добавляет порядковый номер дочерней записи. Документация отмечает, что номер обновляется при добавлении, удалении и дублировании записей. Это удобно для сценариев, где пользователю важно видеть последовательность: участник 1, участник 2, строка 3, смена 4. Но если у каждой записи уже есть уникальное название, номер может быть лишним.

Настройка Entry Labels задаёт подписи для единичной и множественной записи. Не оставляйте универсальные слова, если форма предметная. Вместо "entry" используйте "participant", "shift", "item", "beneficiary" или другой термин, который понятен пользователю. В русскоязычном интерфейсе сайта эти тексты можно локализовать через перевод строк или аккуратную настройку вывода, если это требуется проекту.

Внешний вид модального окна

В настройках внешнего вида есть цвет заголовка модального окна. По документации Nested Forms по умолчанию наследует цвета темы Gravity Forms, поэтому в большинстве случаев поле цвета лучше оставить пустым и сначала проверить форму на реальной странице. Ручной цвет нужен, если модальное окно плохо вписывается в дизайн или если заказчик требует визуально отделить дочернюю запись от основной формы.

Если тема сайта задаёт очень высокий z-index для шапки, всплывающих панелей или виджетов, модальное окно может оказаться под другими элементами. GravityWiz в FAQ предлагает CSS-правку для повышения слоя диалога. Используйте её только после проверки, что проблема действительно в наложении элементов, а не в скриптах, кеше или дублировании формы.

.gpnf-dialog.ui-dialog {
  z-index: 99999999 !important;
}

Добавляйте такой CSS в безопасное место: дочернюю тему, инструмент пользовательского CSS темы или проверенный snippet-менеджер. После вставки откройте страницу формы в режиме инкогнито, нажмите кнопку добавления дочерней записи и проверьте, что модальное окно видно, не перекрывает обязательные элементы формы и закрывается штатно. Откат простой: удалить CSS и очистить кеш страницы.

Лимиты, обязательность и защита от ошибочного ввода

Для повторяемых записей лимиты важнее, чем кажется. Без минимального лимита пользователь может отправить родительскую форму без дочерних записей, хотя бизнес-логика требует хотя бы одну строку. Без максимального лимита можно получить слишком длинную заявку, перегруженную форму или неудобную обработку данных. В Nested Forms лимиты задаются через Entry Limits в расширенных настройках поля.

Как сделать вложенную форму обязательной

Если в родительской заявке должна быть хотя бы одна дочерняя запись, установите минимальное значение Entry Limits равным 1. Это практический способ сделать вложенную форму обязательной. Пользователь не сможет отправить родительскую форму, пока не добавит запись в дочернюю таблицу. Такой подход особенно нужен для регистрации участников, заявок с позициями, списков получателей и любых сценариев, где пустая вложенная часть не имеет смысла.

После включения минимума обязательно проверьте сообщение валидации. Пользователь должен понять, что не заполнено именно поле вложенной формы, а не вся родительская заявка. Если текст выглядит слишком техническим или на английском, проверьте перевод строк Gravity Forms, перевод Gravity Perks и подпись самого поля.

Максимум записей и динамические ограничения

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

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

Антиспам в дочерней форме

Документация GravityWiz прямо отмечает: если дочерние записи не добавляются корректно, нужно проверить, не помечаются ли они как спам. Это особенно вероятно, когда в дочерней форме включены агрессивные антиспам-инструменты или невидимая проверка конфликтует с модальной отправкой. Gravity Forms рекомендует использовать несколько антиспам-подходов, но для Nested Forms важно тестировать именно дочернюю форму внутри родительской страницы, а не отдельно.

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

Как работает связь родительской и дочерней формы

Понимание связи между формами помогает избежать большинства ошибок. Родительская форма - это главная заявка. Дочерняя форма - шаблон для повторяемой записи. Когда пользователь нажимает кнопку добавления, Nested Forms загружает дочернюю форму в модальном окне, принимает её отправку и добавляет строку в таблицу родительской формы. Финальная отправка родительской формы фиксирует весь набор данных как единый сценарий.

Дочерние записи не равны обычным строкам таблицы

Главная практическая разница в том, что дочерняя запись создаётся как отдельная запись формы. Поэтому она может иметь собственные поля, значения, проверки и потенциальные фиды. Это сильнее, чем простой список, но требует дисциплины. Если вы рассчитываете итог, нужно явно выбрать правильный merge tag. Если экспортируете данные, нужно выбрать дочерние поля при экспорте родительской формы. Если настраиваете интеграцию, нужно понимать, обрабатывается ли фид родительской или дочерней формы.

Merge tag {Parent}

Специальный merge tag {Parent} позволяет передавать значения из родительской формы в дочернюю. Документация описывает два основных применения: заполнить поле дочерней формы данными, введёнными в родительской форме, и вывести данные родительской записи в уведомлениях дочерней формы. Для обычных полей используется идентификатор поля, а для составных полей, например имени или адреса, нужно указывать input ID в формате FIELDID.INPUTID.

Практический пример: в родительской форме есть поле "Название команды", а в дочерней форме нужно скрыто сохранить это название для каждого участника. В дочернем поле, которое поддерживает значение по умолчанию, можно использовать {Parent:3}, где 3 - ID поля родительской формы. Для имени или адреса потребуется более точный input ID, например {Parent:1.3} для части составного поля.

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

Когда обрабатываются фиды дочерней формы

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

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

Расчёты, итоговые суммы и экспорт дочерних записей

Nested Forms полезен не только для сбора повторяемых данных, но и для вычислений. В родительской форме можно использовать значения дочерних записей в формулах. Документация GravityWiz описывает модификаторы :count, :total, :sum и :set. Они решают разные задачи, и путать их нельзя.

Как выбрать нужный модификатор

Формат merge tag выглядит как {FIELD_LABEL:FIELD_ID:MODIFIER}, где FIELD_ID - это ID поля Nested Form в родительской форме, а не ID дочернего поля. Это одна из частых ошибок. Для :sum дополнительно указывается ID целевого поля в дочерней форме: например, если поле Nested Form в родительской форме имеет ID 4, а в дочерней форме поле "Hours" имеет ID 6, формула будет похожа на {Entries:4:sum=6}.

Почему итог может не попасть в родительскую сумму

Если дочерние записи содержат поля цены, итог не появляется в родительской форме автоматически. По FAQ GravityWiz для включения итогов дочерних записей в общий итог родительской формы нужен Calculated Product field на родительской форме и merge tag с модификатором :total. Важно также, что :total учитывает поля типа Pricing, а не обычные Number fields. Если вы считаете часы или количество, чаще нужен :sum=ID, а не :total.

Проверяйте расчёт на трёх тестах: одна дочерняя запись, несколько дочерних записей и удаление одной записи перед отправкой. Если сумма меняется правильно во всех трёх случаях, базовая формула настроена корректно. Если сумма залипает, проверьте ID поля Nested Form, ID дочернего поля и тип поля, который участвует в расчёте.

Экспорт родительских и дочерних данных

Данные Nested Forms можно экспортировать вместе с родительской записью. В документации GravityWiz описан сценарий, где при экспорте родительской формы можно выбрать дочерние поля, которые нужно выгрузить рядом с родительскими данными. По умолчанию родительские данные выводятся отдельной строкой над дочерними строками. Для некоторых отчётов это удобно, но для таблиц в аналитике часто нужно повторять родительские данные на каждой строке дочерней записи. Для этого в документации указан hook gpnf_export_parent_entry_data_on_child_entry_rows.

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

Практический сценарий: форма регистрации команды с участниками

Разберём предметный сценарий, который хорошо показывает механику Nested Forms. Цель - создать форму, где капитан команды отправляет одну заявку, указывает общие данные команды и добавляет несколько участников. Администратор должен видеть общую заявку, список участников, количество игроков и, при необходимости, итоговую сумму или ограничения по числу участников.

Цель

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

Подготовка

Создайте дочернюю форму "Participant". Добавьте поля Name, Email, Number, Age Group и Notes. Если участник должен иметь уникальный номер или обязательную электронную почту, настройте это на уровне дочерней формы. Затем создайте родительскую форму "Team Registration" с полями капитана, названием команды, дивизионом и согласием.

Шаги настройки

1. В родительской форме добавьте поле Nested Form из доступных полей Gravity Forms.
2. В настройке Nested Form выберите дочернюю форму "Participant".
3. В Summary Fields выберите Name, Email, Age Group и при необходимости Row ID.
4. В Entry Labels задайте понятные подписи: например, singular "participant", plural "participants".
5. В Entry Limits установите минимум 1 и максимум, который соответствует правилам регистрации.
6. Добавьте в родительскую форму числовое или расчётное поле для количества участников, если нужно показать счётчик через модификатор :count.
7. Сохраните форму и откройте предпросмотр на странице, максимально похожей на рабочую.

Если нужна передача названия команды в уведомление участника, используйте {Parent} в уведомлении дочерней формы или в скрытом поле дочерней формы. Но сначала проверьте, действительно ли участнику нужно получать отдельное письмо. По умолчанию уведомления дочерней формы завязаны на отправку родительской формы, и это часто правильнее: письма не уйдут, пока капитан не завершит заявку.

Проверка результата

Добавьте трёх тестовых участников. Убедитесь, что после каждого добавления строка появляется в таблице родительской формы. Нажмите Edit для одного участника и измените номер. Удалите другого участника и проверьте, что счётчик или итог перестроился. Отправьте родительскую форму и откройте запись в админ-панели. Там должны быть видны общие данные команды и связанные дочерние записи.

Нюанс, который часто пропускают

Если капитан добавляет участника, закрывает страницу и не отправляет родительскую форму, дочерняя запись может стать orphaned entry - записью без родителя. В FAQ GravityWiz указано, что такие записи считаются истёкшими после определённого периода и очищаются по расписанию, а при возврате пользователя в форму его дочерние записи могут быть восстановлены. Поэтому не используйте дочерние записи как окончательные данные, пока родительская форма не отправлена.

Уведомления, интеграции и работа с оплатой

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

Стандартный безопасный вариант

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

Когда нужна обработка сразу после дочерней формы

Обработка сразу после добавления дочерней записи нужна редко. Пример - дочерняя форма собирает отдельные адреса для рассылки, и бизнес-процесс допускает подписку ещё до финальной родительской отправки. В документации GravityWiz для этого есть фильтр, который включает настройку выбора момента обработки фидов. Но перед включением задайте простой вопрос: что произойдёт, если пользователь добавит дочернюю запись, а потом уйдёт со страницы? Если это создаст лишнюю внешнюю запись, оставьте стандартную задержку.

Платёжные сценарии без опасных допущений

GravityWiz указывает ограничение: платёжные фиды не обрабатываются на дочерних формах. Это означает, что платёжную логику лучше держать на родительской форме, а дочерние записи использовать для расчёта состава и суммы. Если дочерние записи содержат поля цены, добавьте Calculated Product field в родительской форме и включите итог дочерних записей через :total. После этого проверяйте не только форму, но и порядок: добавление дочерних записей, пересчёт, отправка, статус платежа, уведомления.

Для уведомлений, которые нельзя отправлять до успешной оплаты, GravityWiz предоставляет отдельный сниппет "Delay Child Notifications for Parent Payment". Его стоит применять только в проектах, где действительно есть платёжный этап и письмо по дочерней записи должно ждать финального статуса родительской заявки. В простых регистрациях без оплаты такой сниппет не нужен.

Шаблоны, вывод на сайте и аккуратные доработки

По умолчанию Nested Forms выводит дочерние записи в компактной таблице на публичной части сайта и показывает связанные данные в админ-панели. Для многих проектов этого достаточно. Но если форма встроена в сложный дизайн, письма должны выглядеть аккуратно или дочерние записи нужно показать в особом формате, доступны шаблоны, merge tags и хуки.

Когда достаточно стандартного вывода

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

Кастомизация шаблонов

Документация GravityWiz описывает шаблонную систему. Файлы шаблонов находятся в каталоге плагина /gp-nested-forms/templates, а переопределять их нужно в теме через каталог /your-theme/gp-nested-forms/. Это позволяет менять вывод дочерних записей без правки файлов плагина. Такой способ подходит разработчику или техническому специалисту, который понимает, как работает дочерняя тема и обновления WordPress.

Не копируйте шаблоны просто "на всякий случай". Каждый скопированный шаблон становится вашей зоной ответственности: при обновлениях плагина стандартный шаблон может улучшиться, а ваша копия останется старой. Безопасная практика - сначала решить задачу стандартными настройками, затем попробовать CSS, потом фильтры, и только если этого мало, переходить к переопределению шаблонов.

Письма и подтверждения

Если нужно выводить дочерние записи в подтверждениях или уведомлениях таблицей, в FAQ GravityWiz есть отдельный сниппет для модификатора {all_fields:gpnf_table}. Он полезен, когда получатель письма должен быстро видеть дочерние записи в структурированном виде. Но такой сниппет лучше применять после теста в реальном почтовом клиенте: таблицы в письмах могут выглядеть по-разному, особенно если тема письма или другой плагин меняет HTML.

Частые проблемы и диагностика Nested Forms

Большая часть проблем с Nested Forms связана не с самим фактом вложенной формы, а с окружением: кеш, повторное встраивание формы, антиспам, неверные Summary Fields, ошибочные ID в расчётах или конфликт слоя модального окна. Диагностику лучше вести по симптомам, а не менять все настройки подряд.

Модальное окно не открывается или появляется под шапкой сайта

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

Возможная причина: конфликт слоя z-index, скриптов темы, всплывающего конструктора или оптимизатора. В FAQ GravityWiz указано, что тема с большим z-index может перекрыть окно Nested Forms.

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

Как исправить: добавьте точечную CSS-правку для .gpnf-dialog.ui-dialog или уменьшите слой конфликтующего элемента. Если после CSS окно видно, проверьте мобильный вид и закрытие модального окна. Откатите правку, если она перекрывает другие важные попапы сайта.

Дочерняя запись не добавляется в таблицу

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

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

Что проверить: откройте настройки поля Nested Form и убедитесь, что выбраны поля сводки. Затем проверьте записи дочерней формы, включая спам. Если тестовые записи попадают в спам, временно отключите спорную антиспам-проверку только на дочерней форме и повторите тест.

Как исправить: назначьте Summary Fields, исключите страницу формы из кеша, отключите агрессивную минификацию для скриптов Gravity Forms или замените антиспам-метод. Если форма встроена через конструктор, проверьте, не дублируется ли она на странице.

Расчёт показывает ноль или неправильную сумму

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

Возможная причина: в формуле указан ID дочернего поля вместо ID поля Nested Form, выбран неверный модификатор или используется обычное числовое поле там, где ожидается поле цены.

Что проверить: найдите ID поля Nested Form в родительской форме и ID нужного поля в дочерней форме. Для подсчёта строк используйте :count, для суммы конкретного числового поля - :sum=ID, для итогов Pricing Fields - :total.

Как исправить: перепишите формулу и протестируйте добавление, редактирование и удаление дочерней записи. Если расчёт связан с оплатой, проверьте весь путь до финального статуса родительской заявки.

Форма ломается в Elementor или другом конструкторе

Симптом: в редакторе или на опубликованной странице Nested Forms работает нестабильно: окно открывается один раз, повторное добавление не работает, значения не обновляются.

Возможная причина: кэширование элементов конструктора, скрытые вкладки, попапы или повторная отрисовка формы. В документации GravityWiz отдельно упоминается настройка Elementor Element Cache как возможный конфликт с динамическими элементами формы.

Что проверить: разместите ту же форму на простой тестовой странице без конструктора. Если там всё работает, отключайте конфликтующие функции конструктора по одной. Также проверьте, не вставлена ли форма дважды на одной странице.

Как исправить: отключите кэширование элемента для страницы с формой, используйте штатный блок Gravity Forms или отдельную страницу вместо сложного попапа. Если форму нужно показать в нескольких местах, создайте копию формы с другим ID, а не вставляйте одну и ту же форму повторно.

Данные не попадают в Zapier или другую интеграцию родительской формы

Симптом: родительская запись уходит в интеграцию, но дочерние поля в ней отсутствуют или приходят не в том формате.

Возможная причина: дочерние записи хранятся как отдельные entries, а фид родительской формы получает только данные родительской записи. В FAQ GravityWiz указано, что встроенного способа напрямую сопоставить дочерние данные в фиде родительской формы может не быть; практический обход - отдельные фиды для родительской и дочерней форм или API-подход.

Что проверить: определите, какая система должна получить данные: родительскую заявку, каждую дочернюю запись отдельно или объединённый JSON. От этого зависит архитектура интеграции.

Как исправить: для простых сценариев используйте два отдельных потока: один для родительской формы, второй для дочерней. Для сложных API-интеграций используйте инструмент, который умеет отправлять родительские и дочерние записи в нужном формате, либо проектируйте отдельную серверную обработку.

Проверка результата перед публикацией формы

После настройки нельзя ограничиться нажатием Preview. Nested Forms затрагивает публичную часть сайта, админ-панель, записи, уведомления, расчёты и иногда внешние интеграции. Поэтому перед публикацией нужен короткий, но полный тест-план.

Минимальный тест-план

1. Откройте страницу формы в обычном браузере и режиме инкогнито.
2. Добавьте одну дочернюю запись, затем несколько записей подряд.
3. Отредактируйте первую запись и убедитесь, что сводная таблица обновилась.
4. Удалите одну запись и проверьте лимиты, счётчики и расчёты.
5. Попробуйте отправить родительскую форму без дочерних записей, если минимум должен быть обязательным.
6. Проверьте форму на мобильном экране: модальное окно, поля, кнопки и сводная таблица должны быть usable.
7. Отправьте финальную заявку и откройте родительскую запись в админ-панели.
8. Проверьте дочерние записи, уведомления, экспорт и интеграции, если они участвуют в сценарии.

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

Что считать хорошим результатом

Хорошая форма с Nested Forms не заставляет пользователя думать о технической вложенности. Он видит понятную кнопку добавления, заполняет одну дочернюю запись, возвращается к родительской форме и видит краткую таблицу. Администратор после отправки видит родительскую заявку, связанные дочерние записи, корректные итоги и понятные уведомления.

Если после теста приходится объяснять пользователю, "какую форму он на самом деле отправляет", структура перегружена. Упростите названия, уменьшите число Summary Fields, сократите дочернюю форму или разделите процесс на несколько шагов.

Видео по практическому сценарию

В официальной документации GravityWiz для Nested Forms есть точный YouTube-сценарий про invoice или purchase entry forms with multiple products. Он полезен тем, кто хочет увидеть не абстрактную вложенную форму, а практическую идею: одна родительская заявка собирает несколько позиций, а Nested Forms помогает держать повторяемые строки внутри общей отправки. Видео лучше использовать как визуальное дополнение к разделам про расчёты, позиции и проверку результата, а не как замену настройке из этой статьи.

Когда Gravity Forms Nested Forms будет удачным выбором

Gravity Forms Nested Forms стоит использовать, когда у вас уже есть Gravity Forms и нужна не просто длинная форма, а аккуратная структура "родительская заявка плюс несколько дочерних записей". Плагин особенно хорош для регистраций, смет, таймшитов, заявок с несколькими объектами и процессов, где повторяемая часть должна иметь собственные поля, проверки и понятный вывод.

Перед запуском проверьте ограничения: не планируйте nested form внутри nested form, не рассчитывайте на платёжные фиды в дочерней форме, осторожно работайте с Save and Continue и заранее тестируйте кеш, конструкторы страниц, антиспам и повторное встраивание формы. Большинство проблем решается не сложным кодом, а правильной архитектурой формы: что относится к родителю, что относится к дочерней записи, какие поля видны в Summary Fields и когда должны срабатывать уведомления.

Если после настройки у вас есть понятная родительская форма, короткая сводная таблица дочерних записей, корректные расчёты, проверенный экспорт и рабочая диагностика, можно переходить к тестированию на копии сайта или сразу загрузить Gravity Forms Nested Forms для дальнейшей установки в рабочем проекте. Главное - не переносить форму в продакшен без тестовой отправки, проверки записей и просмотра уведомлений глазами реального пользователя.