Вы добавляете форму обратной связи через Contact Form 7 в попап Elementor Pro. Пользователь заполняет поля, нажимает «Отправить», и страница целиком перезагружается.

Никаких сообщений об ошибке. Никакого подтверждения отправки. Просто перезагрузка и потерянный лид.

Это известный конфликт: CF7 рассчитан на AJAX-отправку, но внутри динамически загружаемого попапа его JavaScript не успевает привязаться к форме. В результате браузер выполняет обычный HTML-сабмит, тот самый, который и вызывает перезагрузку.

Проблеме уже несколько лет, но исправляется она двумя строчками кода. Ниже, два рабочих решения: современное (чище и надёжнее) и альтернативное с GitHub, плюс опциональные улучшения и чек-лист отладки.

💡 Быстрый обзор:

• Корень проблемы: CF7 инициализируется при загрузке страницы, а попап с формой появляется позже, скрипт не знает о его содержимом
• Решение 1: переинициализация CF7 при срабатывании события elementor/popup/show, JavaScript ждёт открытия попапа и подхватывает форму
• Решение 2: отслеживание клика по кнопке, открывающей попап, с задержкой на анимацию, метод из GitHub-обсуждения Elementor
• Опционально: сброс формы при повторном открытии и автозакрытие попапа после успешной отправки
• Чек-лист отладки: консоль браузера, конфликты jQuery, плагины кеширования

Почему CF7 ломается именно в попапе

Contact Form 7 построен на AJAX: форма отправляется без перезагрузки, валидация полей происходит на лету, сообщения об ошибках или успехе появляются мгновенно. Но весь этот механизм привязывается к DOM при загрузке страницы, вызовом wpcf7.init().

Elementor Pro загружает содержимое попапа динамически, уже после события DOMContentLoaded. Когда пользователь кликает по кнопке и попап открывается, его HTML вставляется в документ, но CF7 об этом не знает. Форма внутри попапа осталась непроинициализированной.

Что происходит дальше: без активного AJAX-обработчика браузер выполняет обычную HTML-отправку формы. Срабатывает атрибут action, и страница перезагружается. Попап закрывается естественным образом (его состояние сбрасывается при навигации). Пользователь видит перезагрузку и уходит.

Многие разработчики пытаются лечить симптомы: блокируют закрытие попапа через event.stopPropagation(), переопределяют внутренние функции Elementor, предотвращают отправку формы через e.preventDefault(). Ни один из этих методов не решает корневую причину, отсутствие инициализации CF7. А часть ломает анимации попапов или сам Elementor на всём сайте.

Надёжное решение одно: дождаться открытия попапа и явно вызвать wpcf7.init() для каждой формы внутри.

Решение 1: переинициализация при открытии попапа (современный подход)

Этот метод использует нативное событие Elementor elementor/popup/show. Код помещается в functions.php активной темы или через плагин для сниппетов вроде Code Snippets.

Создайте резервную копию файла functions.php перед редактированием.

1
/**
2
 * Переинициализация Contact Form 7 при открытии попапа Elementor.
3
 * Решает проблему перезагрузки страницы после отправки формы.
4
 */
5
function sdstudio_cf7_reinit_in_popup() {
6
    ?>
7
    <script>
8
    jQuery( document ).on( 'elementor/popup/show', function() {
9
        document.querySelectorAll( '.wpcf7 form' ).forEach( function( form ) {
10
            if ( typeof wpcf7 !== 'undefined' ) {
11
                wpcf7.init( form );
12
            }
13
        });
14
    });
15
    </script>
16
    <?php
17
}
18
add_action( 'wp_footer', 'sdstudio_cf7_reinit_in_popup' );

После сохранения откройте попап с формой и проверьте: заполните обязательные поля некорректно, нажмите «Отправить». Сообщения валидации должны появиться мгновенно, без перезагрузки. Затем отправьте форму правильно и убедитесь, что сообщение об успехе тоже отображается внутри попапа.

Код ждёт события elementor/popup/show, оно гарантированно срабатывает после рендеринга содержимого попапа. Дальше querySelectorAll находит все формы CF7 в текущем DOM, и wpcf7.init() принудительно подключает к каждой AJAX-валидацию и отправку. Проверка typeof wpcf7 !== 'undefined' страхует от ошибок, если CF7 по какой-то причине не загрузился.

Решение 2: отслеживание клика по кнопке попапа (альтернативный метод)

Этот способ размещён в GitHub-обсуждении Elementor #7798 пользователем @drinkmaker. Он отслеживает не открытие попапа, а клик по кнопке или ссылке с атрибутом href='#elementor-action', именно такие ссылки Elementor использует для вызова попапов.

Задержка setTimeout(..., 800) даёт время на анимацию появления попапа перед тем, как код найдёт и проинициализирует форму. Маркер .elementor предотвращает повторную инициализацию той же формы.

1
/**
2
 * Альтернативная инициализация CF7 в попапах Elementor.
3
 * Источник: https://github.com/elementor/elementor/issues/7798 (drinkmaker)
4
 */
5
function sdstudio_elementor_cf7_alt_init() {
6
    ?>
7
    <script type='text/javascript'>
8
        jQuery( document ).ready( function() {
9
 
10
            jQuery( document ).on( 'click', "a[href='#elementor-action']", function() {
11
 
12
                setTimeout( function() {
13
 
14
                    jQuery( '.elementor-popup-modal form.wpcf7-form:not(.elementor)' ).each( function( index ) {
15
                        wpcf7.initForm( jQuery( this ) );
16
                        jQuery( this ).addClass( 'elementor' );
17
                    });
18
 
19
                }, 800 );
20
 
21
            });
22
 
23
        });
24
    </script>
25
    <?php
26
}
27
add_action( 'wp_footer', 'sdstudio_elementor_cf7_alt_init' );

Какой метод выбрать: первый (по событию elementor/popup/show) предпочтительнее, он опирается на документированное API Elementor, чище и не зависит от таймаутов. Второй проверен годами в продакшене и служит надёжным планом Б, если первый по какой-то причине не сработал.

Дополнительно: сброс формы при повторном открытии

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

1
/**
2
 * Сброс формы CF7 при каждом открытии попапа Elementor.
3
 */
4
function sdstudio_cf7_reset_on_popup_open() {
5
    ?>
6
    <script>
7
    jQuery( document ).on( 'elementor/popup/show', function() {
8
        jQuery( '.wpcf7 form' ).each( function() {
9
            this.reset();
10
            jQuery( this ).find( '.wpcf7-not-valid' ).removeClass( 'wpcf7-not-valid' );
11
            jQuery( this ).find( '.wpcf7-response-output' ).hide();
12
            jQuery( this ).find( '.wpcf7-not-valid-tip' ).remove();
13
        });
14
    });
15
    </script>
16
    <?php
17
}
18
add_action( 'wp_footer', 'sdstudio_cf7_reset_on_popup_open' );

Функция сбрасывает значения полей методом reset(), убирает CSS-классы невалидных полей, скрывает сообщения об отправке и удаляет подсказки валидации. Пользователь всегда видит чистую форму.

Дополнительно: закрытие попапа после успешной отправки

После успешного сабмита разумно автоматически закрыть попап через 1,5 секунды, пользователь успевает прочитать подтверждение и не ищет крестик вручную:

1
/**
2
 * Автозакрытие попапа Elementor после успешной отправки CF7.
3
 */
4
function sdstudio_close_popup_on_cf7_success() {
5
    ?>
6
    <script>
7
    document.addEventListener( 'wpcf7mailsent', function() {
8
        setTimeout( function() {
9
            jQuery( '.dialog-close-button' ).trigger( 'click' );
10
        }, 1500 );
11
    }, false );
12
    </script>
13
    <?php
14
}
15
add_action( 'wp_footer', 'sdstudio_close_popup_on_cf7_success' );

Событие wpcf7mailsent срабатывает, когда сервер подтвердил отправку письма. Задержка в 1500 мс даёт пользователю прочитать сообщение об успехе. Клик по .dialog-close-button использует стандартную кнопку закрытия Elementor, в отличие от попыток дёрнуть API попапа напрямую, этот метод стабилен на всех версиях.

Чек-лист отладки

Если после добавления кода форма всё равно перезагружает страницу, пройдите по пунктам:

• Консоль браузера. Откройте DevTools (F12 → Console) и проверьте наличие красных ошибок JavaScript. Частая причина, jQuery не загружен или конфликтует с другим плагином.

• Кеширование. Плагины вроде WP Rocket, Autoptimize или хостинговый кеш могут минифицировать и объединять скрипты. Временно отключите агрессивную оптимизацию JS и проверьте заново.

• jQuery в noConflict-режиме. Если тема или плагин оборачивают jQuery в noConflict, замените jQuery на $ с соответствующей обёрткой или используйте полную форму jQuery.

• ID попапа. Убедитесь, что форма находится именно в том попапе, который вызывается кнопкой с href='#elementor-action'. Для попапов, открываемых через триггеры другого типа (например, по таймеру), первый метод с elementor/popup/show надёжнее.

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

• Версия CF7. Решения проверены на Contact Form 7 версии 5.7+ и Elementor Pro 3.5+. Если версия CF7 ниже 5.7, функция wpcf7.init() может называться иначе, обновите плагин.

⁉️🤔 Частые вопросы

Почему CF7 работает на обычной странице, но ломается в попапе?

При загрузке обычной страницы DOM уже построен, и CF7 успевает проинициализировать все формы. Попап Elementor загружает содержимое асинхронно, после того, как CF7 завершил свою работу. Форма оказывается в DOM, но без привязанного JavaScript-обработчика. Именно поэтому проверка «на отдельной странице всё работает» не помогает: условия загрузки принципиально разные. Решение, всегда принудительная реинициализация при открытии попапа, независимо от того, работает ли форма где-то ещё.

Можно ли обойтись без кода, плагином или настройкой?

Готового плагина «нажми галочку, и всё заработает» для этого бага нет. Проблема на стыке двух независимых продуктов (Elementor и CF7), и каждый из них работает корректно по отдельности. Сторонние надстройки вроде WPB Popup for Contact Form 7 решают задачу иначе, создают собственные попапы, а не чинят Elementor. Приведённый выше код, минимально необходимый объём вмешательства. Он добавляется один раз в functions.php и не требует обновлений при выходе новых версий CF7 или Elementor.

Первый метод не сработал. Что проверить до перехода ко второму?

Проверьте три вещи. Первое: событие elementor/popup/show доступно начиная с Elementor Pro 2.7, если версия ниже, используйте сразу второй метод. Второе: откройте консоль и введите typeof wpcf7, если undefined, плагин CF7 не загрузил свой JavaScript (ищите ошибки или конфликты). Третье: убедитесь, что форма внутри попапа имеет класс .wpcf7, без него селектор querySelectorAll('.wpcf7 form') ничего не найдёт. В подавляющем большинстве случаев первый метод работает сразу. Если нет, используйте второй, он проверен годами на сотнях сайтов.

Нужно ли добавлять все три сниппета или достаточно одного?

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

После исправления форма отправляется, но письма не приходят. Это связано?

Нет, проблема доставки писем, отдельная тема, не имеющая отношения к работе CF7 в попапе. Если после применения исправления форма показывает сообщение об успехе (зелёная рамка), значит AJAX-отправка работает корректно. Письма не доходят, проверьте настройки SMTP, спам-фильтры хостинга и корректность адреса получателя в настройках формы CF7. Для надёжной доставки используйте SMTP-плагин вроде Post SMTP или FluentSMTP, а не стандартную функцию wp_mail(), хостинги часто блокируют исходящие письма с PHP.

Влияет ли это решение на другие формы CF7 на сайте?

Нет. Оба метода изолированы: первый ждёт открытия попапа Elementor, второй отслеживает только ссылки с href='#elementor-action'. Обычные формы CF7, размещённые на страницах и в виджетах, продолжают работать штатно, их инициализация происходит при загрузке страницы и не затрагивается. Единственный нюанс: если на сайте используется агрессивное кеширование с объединением скриптов, добавьте код попапов в исключения минификации, чтобы избежать двойного выполнения.

Стоит ли заморачиваться с самописным кодом в 2026 году

Оба плагина, и Contact Form 7, и Elementor Pro, активно развиваются и обновляются. CF7 держит планку самого популярного форменного плагина WordPress с более чем 5 миллионами активных установок. Elementor Pro используют на каждом четвёртом сайте под управлением WordPress.

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

Хорошая новость: исправление тривиально, код добавляется один раз и не требует поддержки. Выберите первый метод (событие elementor/popup/show), он самый чистый, и забудьте о проблеме. Если форма в попапе используется для критичных лидогенерирующих сценариев, добавьте ещё сброс полей и автозакрытие: пользовательский опыт станет заметно лучше.

Посмотрите видео выше, в нём показан полный процесс настройки попапа с Contact Form 7 в Elementor. Визуальное пошаговое руководство дополняет приведённые здесь сниппеты и помогает избежать ошибок на этапе сборки.