Gravity Forms Debug - Плагин WordPress

Руководство по диагностике форм с Gravity Forms Debug

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

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

Главная идея проста: Gravity Forms Debug особенно полезен на живом сайте, где нельзя грубо отключить тему и все плагины для каждого посетителя. Но это не магическая кнопка ремонта. Add-on помогает сузить круг причин, а исправление всё равно зависит от найденного источника: темы, оптимизатора, конструктора страниц, платежного add-on, кода в дочерней теме или серверной настройки.

Что решает add-on и где он полезен

По официальной документации и обсуждениям поддержки Gravity Forms, основная задача Debug Add-On - дать инструмент Conflict Tester. Он позволяет проверить конфликт темы и плагинов так, чтобы изменения применялись к текущему пользователю, который включил режим диагностики. Для остальных посетителей сайт продолжает работать в обычном виде. Это важное отличие от ручного теста, где администратор временно включает стандартную тему и отключает сторонние плагины глобально.

Такой подход полезен, когда проблема проявляется только в реальном окружении сайта. Например, форма корректно считает итог в режиме предпросмотра, но на странице с активной темой расчёт не обновляется. Или в конструкторе форм ломается кнопка выбора merge tags, не работает экспорт записей, исчезает reCAPTCHA на мобильной версии, не появляется кнопка добавления feed для платежного add-on. В этих случаях сначала нужно доказать, что проблема не в самой форме, а в окружении.

Gravity Forms Debug не заменяет системные логи Gravity Forms, консоль браузера и System Status. Скорее он отвечает на вопрос: "Кто мешает форме работать в этом окружении?" Логи отвечают на другой вопрос: "Что именно произошло во время отправки, обработки feed, фоновой задачи или уведомления?" Хорошее расследование обычно объединяет оба подхода.

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

Типовые задачи, где Debug Add-On уместен

Плагин особенно полезен в сценариях, где ошибка похожа на конфликт JavaScript, CSS или серверного окружения, но нет очевидного виновника. К таким ситуациям относятся:

• Форма работает в Preview, но ломается на публичной странице с темой, конструктором или всплывающим окном.
• Поля расчёта, total, date picker, CAPTCHA или условная логика ведут себя иначе на реальной странице.
• В админ-панели Gravity Forms не открываются элементы конструктора, не работает экспорт, пропадает часть интерфейса.
• После включения оптимизации, минификации или отложенной загрузки скриптов форма перестаёт отправляться.
• Нужно проверить конфликт на рабочем сайте, но нельзя показывать посетителям стандартную тему и отключённые плагины.

Во всех этих случаях add-on не должен быть первым и единственным действием. Сначала проверьте обычные вещи: обновления, отсутствие явных ошибок в консоли браузера, корректность embed формы, права пользователя и включённые логи Gravity Forms. Затем используйте Debug Add-On как контролируемый тест изоляции.

Кому подходит этот способ диагностики и кому он может помешать

Gravity Forms Debug лучше всего подходит администраторам сайтов, агентствам и разработчикам, которые поддерживают формы на рабочем WordPress-сайте. Он экономит время, когда нет отдельной staging-копии или когда ошибка проявляется только в реальном окружении: в текущей теме, с текущим кешем, с конкретным набором add-ons и пользовательских ролей.

При этом add-on не делает расследование полностью безопасным в организационном смысле. Технически Conflict Tester изолирует изменения для пользователя, который включил режим, но администратор всё равно может ошибиться: тестировать не ту страницу, включить не тот плагин в диагностической сессии, забыть сохранить активные элементы, не отключить режим после проверки. Поэтому перед стартом нужен короткий план.

Инструмент подходит, если вы:

• Понимаете, какая форма, страница или feed вызывает проблему.
• Можете войти в админ-панель под пользователем с достаточными правами.
• Имеете доступ к резервной копии или хотя бы к хостингу, если потребуется откатить конфликтный плагин.
• Готовы тестировать по одному изменению и записывать результаты.
• Не пытаетесь чинить форму прямо на глазах у клиента без фиксации исходного состояния.

Плагин может быть лишним, если проблема уже очевидна: например, в логах видна ошибка внешнего API, письмо не уходит из-за SMTP, сервер блокирует loopback-запросы, а в System Status прямо указана проблема с правами папки загрузок. В таких случаях Conflict Tester можно оставить на потом и сначала устранить подтверждённую причину.

Ограничение для сетевых установок

В источниках поддержки Gravity Forms встречается важная оговорка: для WordPress multisite часто рекомендуют выполнять ручную проверку конфликтов вместо Debug Add-On. Поэтому на сетевой установке не обещайте, что Conflict Tester будет доступен и поведёт себя так же, как на одиночном сайте. Проверьте документацию именно для вашей версии Gravity Forms и текущего окружения.

Практическое правило: если сайт критичен для продаж или заявок, сначала повторите ошибку на staging-копии. Debug Add-On полезен на live-сайте, но staging остаётся лучшим местом для разрушительных экспериментов, массовых обновлений и проверки спорных исправлений.

Что проверить перед установкой

Перед установкой диагностического add-on важно не спешить. Если вы включите Conflict Tester без исходных данных, результат будет трудно интерпретировать. Сначала подготовьте короткую карту проблемы: какая форма ломается, где она встроена, чем публичная страница отличается от предпросмотра, какие add-ons участвуют, есть ли платежи, регистрация пользователей, webhooks, уведомления или фоновые задачи.

Начните с базового чек-листа. Он не заменяет диагностику, но помогает не тратить время на очевидные причины:

• Откройте проблемную форму в Preview и проверьте, повторяется ли ошибка без темы и конструктора страницы.
• Откройте страницу в браузере с включённой консолью и зафиксируйте ошибки JavaScript, если они есть.
• Проверьте, не встроена ли одна и та же форма несколько раз на одной странице, включая вкладки, модальные окна, слайдеры и повторяющиеся блоки.
• Проверьте, включены ли кеширование, минификация, отложенная загрузка скриптов или объединение файлов JavaScript.
• Откройте Forms - System Status и посмотрите окружение, активную тему, активные плагины, права загрузочной папки и доступность логов.
• Убедитесь, что пользователь имеет права на настройки Gravity Forms, системный статус и логи, если в проекте используется плагин управления ролями.

Не все пункты будут применимы к каждой ошибке. Если, например, не отправляется feed в сторонний сервис, важнее включить логирование core и соответствующего add-on. Если ломается внешний вид или расчёт на странице, важнее проверить тему, конструктор, кеш и фронтовые скрипты.

Минимальный набор доступа

Для нормальной работы с Debug Add-On вам нужен доступ к админ-панели WordPress, странице плагинов, меню Gravity Forms и проблемной странице. Хорошо, если есть доступ к хостингу или файловому менеджеру, но в обычном сценарии Conflict Tester не требует ручной правки файлов. Доступ к хостингу нужен как страховка: если сайт уже нестабилен, администратор должен понимать, как отключить проблемный плагин вне админ-панели.

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

Что записать до первого теста

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

1. URL страницы с формой и ID формы.
2. Точное действие, после которого виден сбой.
3. Ожидаемый результат и фактический результат.
4. Текущая активная тема и плагины, которые явно связаны со страницей.
5. Включённые оптимизаторы скриптов, кеш и CDN, если они используются.
6. Номер тестовой записи, если ошибка связана с отправкой формы.

Эта простая запись нужна не для бюрократии. Когда вы начнёте по одному включать плагины в Conflict Tester, без журнала легко потерять момент, где ошибка вернулась.

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

Gravity Forms Debug устанавливается как обычный add-on WordPress. Общая схема такая же, как у других add-ons Gravity Forms: через браузер add-ons в админ-панели, через загрузку ZIP в Plugins - Add New - Upload Plugin или через файловую загрузку в папку wp-content/plugins. Конкретный способ зависит от того, как у вас организованы обновления и доступ к файлам.

После установки откройте список плагинов и активируйте add-on. Затем найдите раздел диагностики в меню Gravity Forms. В старых материалах и практических разборах путь описывается как Forms - Debug. Если такого пункта нет, не делайте вывод, что add-on сломан. Проверьте права текущего пользователя, активность основного Gravity Forms, совместимость с вашим типом установки и отсутствие ограничений со стороны панели управления ролями.

Первичная проверка должна быть короткой:

• Откройте страницу Debug и убедитесь, что видите блок Conflict Tester.
• Не включайте режим сразу, если не записали исходные симптомы.
• Проверьте, что рядом доступна ссылка отключения режима, если интерфейс её показывает.
• Откройте проблемную страницу в отдельной вкладке, чтобы быстро повторить тест.
• Если планируете проверять отправку формы, подготовьте безопасные тестовые данные.

Не начинайте диагностику с массового отключения всего в обычном разделе Plugins. Если цель - проверить проблему без влияния на посетителей, все переключения делайте внутри Conflict Tester, а не в глобальном списке плагинов.

Если пункт Debug не появился

Проверьте четыре вещи. Во-первых, активен ли основной Gravity Forms. Во-вторых, активирован ли сам add-on. В-третьих, не ограничивает ли роль пользователя доступ к системным возможностям Gravity Forms. В-четвёртых, не используется ли тип установки, для которого документация или поддержка рекомендует ручной conflict test.

Если интерфейс Gravity Forms вообще ведёт себя странно, сначала попробуйте официальный No Conflict Mode для админ-панели. Он применим именно к страницам администрирования Gravity Forms и помогает, когда сторонние скрипты и стили вмешиваются в form editor. Но важно понимать ограничение: этот режим не исправляет публичную часть сайта, где посетитель отправляет форму.

Conflict Tester: как изолировать тему, плагины и конструктор страницы

Conflict Tester - центральная часть Gravity Forms Debug. Его задача - создать для текущего администратора диагностическое окружение, где тема заменяется стандартной, а плагины отключаются или включаются по вашему выбору. Посетители при этом продолжают видеть обычный сайт. Именно поэтому add-on часто рекомендуют в обсуждениях поддержки, когда ручная проверка на live-сайте слишком рискованна.

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

Базовая последовательность

Самый надёжный способ - двигаться от чистого окружения к реальному. Порядок может выглядеть так:

1. Включите Conflict Tester на странице Forms - Debug.
2. Повторите ошибку с активными только Gravity Forms и Debug Add-On, если интерфейс режима это позволяет.
3. Если форма теперь работает, включите стандартную тему или оставьте её активной и возвращайте плагины по одному.
4. После каждого включения сохраняйте выбранный набор и повторяйте один и тот же тест.
5. Когда ошибка вернётся, зафиксируйте последний включённый элемент и проверьте его отдельно.
6. Если ошибка появляется только при сочетании двух элементов, проверьте каждую часть отдельно и затем вместе.

Не меняйте одновременно тему, кеш, конструктор и платежный add-on. Такой тест ничего не докажет. Хорошая диагностика скучна: одно изменение - один повтор - одна запись результата.

Как проверять тему

Тема часто влияет на Gravity Forms через JavaScript, собственный jQuery, стили полей, модальные окна, обработчики вкладок, lazy load, маски ввода и переписанные шаблоны. Если ошибка пропадает на стандартной теме, не спешите править код. Сначала проверьте обновления темы и дочерней темы, отключите спорные настройки оптимизации в теме, создайте чистую страницу с обычным блоком Gravity Forms без конструктора и повторите тест.

Если форма работает на чистой странице, но ломается внутри конструктора или модального окна, проблема может быть не в Gravity Forms Debug и не в основном Gravity Forms. Часто скрипт формы не инициализируется после показа скрытого блока, один и тот же HTML ID появляется дважды или оптимизатор меняет порядок загрузки файлов.

Проверка чистой страницы

Создайте временную приватную страницу, вставьте туда ту же форму обычным блоком Gravity Forms или стандартным shortcode и не добавляйте на страницу секции конструктора, pop-up, вкладки, слайдеры и пользовательские scripts. Если на такой странице проблема исчезает, Debug Add-On уже дал важный вывод: сама форма и базовые скрипты работают, а ошибка привязана к способу вывода или окружению конкретной страницы.

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

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

Как проверять плагины

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

Отдельно проверяйте оптимизаторы, кеш, безопасность, конструкторы страниц, плагины всплывающих окон, add-ons для платежей и add-ons, которые меняют поля формы. Они чаще вмешиваются в загрузку скриптов, отправку запроса, отображение CAPTCHA, расчёты и feed processing.

Порядок возврата плагинов

Начинайте с компонентов, без которых форма вообще не может повторить нужный сценарий: официальный платежный add-on, add-on регистрации, webhooks, SMTP или integration plugin. Затем возвращайте плагины, которые меняют страницу: конструктор, pop-up, кеш, оптимизатор, безопасность, аналитика. В последнюю очередь включайте плагины, которые не участвуют в форме. Такой порядок быстрее приводит к причине, чем алфавитный перебор всего списка.

Как фиксировать связку двух конфликтов

Иногда один плагин не ломает форму, второй тоже не ломает, но вместе они меняют порядок загрузки скриптов или дублируют обработчик события. В журнале проверки пишите не только последний включённый компонент, но и минимальную связку, при которой ошибка повторяется. Формулировка "ошибка появляется при активных A + B, но не появляется при A отдельно и B отдельно" гораздо полезнее для разработчика, чем длинный список всех активных расширений.

Настройка логов и System Status рядом с Debug

Gravity Forms Debug отвечает за изоляцию окружения, но логи и System Status помогают понять, что именно происходит внутри Gravity Forms. В официальной документации логирование включается через Forms - Settings, затем появляется раздел Logging. Там можно включить логи для Gravity Forms core и add-ons. Если лог пуст, ссылка просмотра может не появиться, поэтому после включения нужно повторить тестовое действие.

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

Какие логи включать первыми

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

• Если ломается отправка формы, включите Gravity Forms core и повторите отправку.
• Если не срабатывает интеграция, включите лог соответствующего add-on и проверьте feed.
• Если есть фоновые задачи, посмотрите background processing в System Status и логи core или add-on.
• Если проблема только в админ-панели, проверьте No Conflict Mode и консоль браузера.
• Если проблема с экспортом, загрузкой файлов или системным отчётом, проверьте права папок, таблицы базы и активные плагины.

Лог должен отвечать на конкретный вопрос. Например: "Запустился ли feed?", "Почему внешний сервис отклонил данные?", "Есть ли ошибка фонового процессора?", "Появилась ли запись после отправки тестовой формы?" Если вопроса нет, лог быстро превращается в шум.

System Status как карта окружения

System Status полезен перед отправкой тикета и перед глубокой проверкой. Он показывает версию Gravity Forms, активные add-ons, состояние базы данных, настройки WordPress, тему, плагины, PHP, веб-сервер, права загрузочной папки и сведения о логах. Если у пользователя нет доступа к System Status, причина может быть в версии Gravity Forms или в возможностях роли.

Для диагностики Gravity Forms Debug особенно важны четыре зоны: активная тема, активные плагины, No-Conflict Mode и Log Files. Они помогают связать результат Conflict Tester с реальным окружением. Если в чистом режиме ошибка исчезла, снимок System Status поможет понять, какие элементы нужно вернуть в тест первыми.

Что не стоит скрывать от поддержки

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

Мини-отчёт после проверки

Хороший отчёт помещается в несколько строк: "Форма ID 12 на странице заявки, в preview работает, на публичной странице зависает после выбора поля. В Conflict Tester на стандартной теме и без сторонних плагинов работает. Ошибка возвращается при включении оптимизатора скриптов с отложенной загрузкой. После исключения файлов Gravity Forms из отложенной загрузки тестовая отправка, запись и уведомление проходят". Такой отчёт сразу показывает источник, проверку и временное исправление.

Практический сценарий: форма считает total в предпросмотре, но ломается на странице

Разберём предметный пример. На сайте есть форма записи на мероприятие с пользовательским product field и total. В Preview сумма обновляется сразу после выбора опций, а на публичной странице total стоит на месте. В обсуждениях поддержки Gravity Forms похожие симптомы часто связывают с JavaScript-ошибкой, конфликтом темы, оптимизатором или способом встраивания формы.

Цель

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

Подготовка

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

Шаги проверки

1. Откройте проблемную форму в Preview и подтвердите, что total обновляется.
2. Включите Conflict Tester через Forms - Debug.
3. Откройте публичную страницу в той же админ-сессии и повторите выбор опций.
4. Если total заработал, начните возвращать плагины: сначала конструктор страницы, затем кеш, затем add-ons, связанные с формой.
5. После каждого включения нажимайте сохранение в Conflict Tester и повторяйте одинаковый тест.
6. Когда total снова перестанет обновляться, отключите последний элемент и повторите тест для подтверждения.
7. Если отдельный плагин не ломает форму, но ломает в паре с оптимизатором, проверьте исключения скриптов Gravity Forms из минификации и отложенной загрузки.

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

Правильный результат - не только работающий total. Вам нужно получить воспроизводимую цепочку: "чистое окружение работает", "после включения плагина X всё ещё работает", "после включения оптимизации Y ошибка возвращается", "после исключения скриптов формы ошибка исчезает". Только такая цепочка позволяет безопасно вносить изменения на реальном сайте.

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

Нюанс с кешем и скрытыми блоками

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

Как читать результат и возвращать сайт в нормальный режим

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

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

Когда конфликт найден, выбирайте исправление по типу причины:

• Тема: обновить тему, проверить дочернюю тему, убрать повторную загрузку jQuery, проверить пользовательские скрипты.
• Оптимизация: исключить скрипты Gravity Forms из объединения, минификации или отложенной загрузки, затем очистить кеш.
• Конструктор: создать чистую страницу с обычным блоком формы, проверить настройки модального окна или вкладки.
• Сторонний add-on: обновить компонент, проверить настройки feed, обратиться к разработчику с результатами теста.
• Сервер: проверить loopback-запросы, cron, права папок, доступность Admin Ajax URL и ограничения безопасности.

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

Диагностическая карта: симптомы, причины и быстрые проверки

Ниже - не универсальный список всех ошибок Gravity Forms, а практическая карта для случаев, где Debug Add-On особенно полезен. Она помогает решить, что проверять в первую очередь и когда переходить от Conflict Tester к логам, System Status или инструментам WordPress-разработчика.

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

Симптом	Возможная причина	Что проверить	Как исправлять осторожно
Форма работает в Preview, но не на странице	Тема, конструктор, кеш, JavaScript-ошибка или скрытый блок	Conflict Tester, консоль браузера, чистая страница с обычным embed	Исключить скрипты формы из оптимизации, изменить способ вставки, обновить тему или плагин
Total или расчёт не обновляется	Скрипт формы не загрузился или был изменён оптимизатором	Предпросмотр, публичная страница, включение оптимизатора в Conflict Tester	Отключить спорный режим минификации, вернуть порядок загрузки скриптов, очистить кеш
Не открывается часть form editor	Сторонние скрипты в админ-панели Gravity Forms	No Conflict Mode, консоль браузера, список активных admin plugins	Включить No Conflict Mode как временный обход и найти источник конфликтного скрипта
Feed не выполняется или выполняется не тот feed	Условная логика, маппинг полей, spam status, внешний сервис, фоновые задачи	Логи add-on, запись тестовой отправки, условия feed, System Status	Исправить условия, поля, подключение сервиса или фоновую обработку по логам
Форма бесконечно отправляется или зависает	Одинаковая форма встроена несколько раз, JavaScript конфликт, AJAX-проблема	Количество embed на странице, консоль, GF_DEBUG для AJAX-iframe при необходимости	Использовать отдельные копии формы или один embed, устранить конфликт скриптов

Когда лучше откатить изменение

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

Почему иногда Debug Add-On не находит виновника

Conflict Tester проверяет тему и плагины в рамках WordPress, но не всегда изолирует сетевые правила, серверный кеш, CDN, внешние API, ограничения хостинга, mu-plugins, drop-ins и настройки веб-сервера. Официальная документация Gravity Forms отдельно напоминает, что must-use и drop-in плагины могут не отключаться в обычном тесте. Поэтому отрицательный результат Conflict Tester не означает, что конфликтов нет вообще. Он означает только, что в проверенном наборе причина не проявилась.

Безопасные улучшения без правки ядра

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

Отключить постоянное предупреждение о логах только осознанно

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

define( 'GF_LOGGING_DISABLE_NOTICE', true );

Добавлять константу нужно в wp-config.php, а не в файлы Gravity Forms. После завершения расследования отключите логи и удалите константу, если она больше не нужна. Проверка простая: откройте Forms - Settings - Logging и убедитесь, что логирование не осталось включённым без задачи.

GF_DEBUG для AJAX-сценариев

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

define( 'GF_DEBUG', true );

Включайте его только на время точечной проверки и убирайте после теста. Если вы не понимаете, что именно хотите увидеть в AJAX iframe, лучше сначала включить обычные логи Gravity Forms и проверить консоль браузера.

gform.console для пользовательского кода

Если проблема вызвана вашим JavaScript, полезно использовать не случайные console.log по всему проекту, а встроенную обёртку gform.console, описанную в документации Gravity Forms. Она помогает писать диагностические сообщения в стиле экосистемы Gravity Forms. Но добавляйте такие сообщения только в свой код, дочернюю тему или отдельный безопасный сниппет. Не редактируйте файлы плагина.

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

Где Debug Add-On уступает другим инструментам

Gravity Forms Debug хорош в проверке конфликтов вокруг Gravity Forms. Но если задача шире - найти медленный SQL-запрос, понять стек PHP-ошибки, проверить HTTP-запрос, увидеть REST API, посмотреть блоки или отследить произвольные хуки WordPress - одного add-on будет мало. Здесь лучше подключать специализированные инструменты.

Подход можно разделить так:

• Gravity Forms Debug - когда нужно проверить, мешает ли тема или плагин конкретной форме.
• Логи Gravity Forms - когда нужно понять обработку отправки, feed, уведомления или фоновой задачи.
• System Status - когда нужно увидеть окружение, активные компоненты и технические условия.
• Query Monitor - когда нужен широкий разбор PHP, запросов, hooks, HTTP API, REST API и источника ошибки.
• WP Debugging или ручные константы WordPress - когда нужно включить системный debug log для разработки.

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

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

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

Перед началом сохраните исходные симптомы, включайте режим диагностики только для конкретной проверки, возвращайте элементы по одному, используйте логи Gravity Forms для feed и фоновых задач, а после завершения отключайте логирование и удаляйте лишние файлы. Такой подход превращает Debug Add-On из "кнопки надежды" в нормальный рабочий инструмент поддержки.

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