Если форма WPForms на сайте выглядит нормально, но после отправки ничего не происходит, а проблема появляется только на страницах с кешем, сначала проверяйте не сам плагин форм, а слой оптимизации. Чаще всего ломается не HTML-разметка, а загрузка JavaScript, nonce, AJAX-запрос или конфликт с объединением скриптов.
Ниже разберем рабочий сценарий: как локализовать источник ошибки, что отключать в первую очередь и как безопасно оставить кеш включенным, не ломая отправку формы.
Как выглядит проблема на практике
Типичные симптомы довольно узнаваемы:
- кнопка отправки нажимается, но форма не уходит;
- после клика нет сообщения об успехе и нет ошибки;
- на одной странице форма работает, на другой — нет;
- после включения кеш-плагина, минификации или объединения файлов проблема появляется сразу;
- в консоли браузера видны ошибки JavaScript или 403/400 в запросах к
admin-ajax.phpили REST API.
Если форма ломается только у гостей, а у администратора работает, это тоже важная подсказка: кеш часто отдает разный HTML и разные версии скриптов для авторизованных и неавторизованных пользователей.
Диагностика: что проверить до правок
1. Откройте консоль браузера
На странице с формой нажмите F12 и посмотрите вкладку Console. Ищите:
Uncaught TypeError;wpforms is not defined;jQuery is not defined;- ошибки, связанные с defer/delay/async;
- ошибки CORS или blocked by client.
Если в консоли уже есть ошибка до отправки формы, сначала исправляйте ее. WPForms часто просто не может инициализировать скрипт на странице.
2. Проверьте сетевые запросы
Во вкладке Network отправьте форму еще раз и посмотрите, уходит ли запрос. Нормально, если вы видите запрос к WordPress AJAX или REST-эндпоинту и ответ без 4xx/5xx. Если запрос не уходит вообще, проблема почти всегда в JS. Если уходит, но возвращается ошибка, смотрите ответ сервера и логи безопасности.
3. Временно отключите оптимизацию только для теста
Не выключайте весь кеш сразу на продакшене. Для проверки достаточно временно отключить:
- объединение JS;
- отложенную загрузку JavaScript;
- delay JS execution;
- минификацию, если она затрагивает скрипты формы;
- lazy load для встроенных скриптов, если плагин это делает.
Если после этого форма начинает отправляться, вы нашли не WPForms, а конфликт с оптимизатором.
Пошаговое решение без полного отключения кеша
Шаг 1. Исключите страницу с формой из агрессивной оптимизации
Самый надежный путь — оставить кеш для сайта, но убрать для страницы с формой самые рискованные оптимизации. В большинстве кеш-плагинов есть исключения по URL, шаблону или конкретным скриптам. Исключайте не только саму страницу, но и файлы, если плагин позволяет.
Если форма встроена в несколько страниц, лучше исключить именно скрипты WPForms, а не весь сайт. Названия файлов зависят от версии плагина, поэтому ориентируйтесь по фактическим URL в исходном коде страницы.
Шаг 2. Не объединяйте все скрипты в один файл
Объединение JS часто ломает порядок загрузки. Для форм это критично: сначала должен загрузиться jQuery и зависимости, потом инициализация WPForms. Если кеш-плагин склеивает все в один бандл, а один из файлов откладывается, форма может перестать работать без явной ошибки.
Практика простая: если нужно выбирать между минификацией и стабильной отправкой формы, сначала отключайте именно объединение. Минификация обычно безопаснее, чем агрессивный bundle.
Шаг 3. Исключите скрипты формы из defer/delay
Многие оптимизаторы переносят загрузку JS до первого взаимодействия пользователя. Для обычного контента это нормально, но для формы — рискованно. Если скрипт инициализации WPForms отложен, пользователь может нажать кнопку раньше, чем форма станет интерактивной.
Если в плагине есть список исключений, добавьте туда скрипты, связанные с WPForms, а также jQuery, если тема или другие плагины завязаны на него.
Шаг 4. Проверьте nonce и кеш HTML
Иногда проблема не в JS, а в том, что кеш хранит HTML слишком долго и отдает устаревший nonce. Это особенно заметно на формах, где отправка идет через AJAX. Если ответ сервера содержит сообщение о недействительном токене или запрос отклоняется, уменьшайте время кеша для страницы или исключайте ее из полной HTML-кешировки.
Для динамических форм, форм с логикой показа полей и форм с защитой от спама лучше быть осторожнее с полным кешем страницы.
Если нужен точечный фикс в коде
Иногда удобнее отключить лишнюю оптимизацию программно для конкретной страницы. Это полезно, если кеш-плагин не дает тонких исключений в интерфейсе. Ниже пример, который можно адаптировать под ваш плагин оптимизации: он не отключает кеш целиком, а только снимает агрессивную обработку скриптов на странице с формой.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
return;
}
// Пример: на странице с формой не даем теме или кастомному коду
// добавлять отложенную загрузку для критичных скриптов.
wp_dequeue_script( 'some-delay-script-handle' );
}, 20 );Это не универсальный рецепт: some-delay-script-handle нужно заменить на реальный handle вашего скрипта. Узнать его можно в исходниках темы, в коде плагина или через инструменты разработчика.
Если вы используете собственную тему или child theme, можно точечно отключить лишний JS только на странице с формой:
<?php
add_action( 'wp_print_scripts', function () {
if ( ! is_page( 'contact' ) ) {
return;
}
// Пример для локального кастомного скрипта, который конфликтует с формой.
wp_dequeue_script( 'theme-frontend' );
}, 100 );Такой подход имеет смысл только если вы точно знаете, какой скрипт ломает инициализацию. Если не уверены, сначала решайте проблему через настройки кеш-плагина.
Сравнение подходов: что выбрать быстрее
| Подход | Когда подходит | Минус |
|---|---|---|
| Исключить страницу из кеша | Форма одна, страница важная, нужна стабильность | Страница теряет часть выигрыша по скорости |
| Исключить JS WPForms из delay/defer | Форма ломается только из-за отложенной загрузки | Нужно аккуратно найти нужные файлы |
| Отключить объединение JS | Есть ошибки порядка загрузки | Может остаться больше отдельных запросов |
Как проверить, что решение сработало
После правок не ограничивайтесь одним кликом по кнопке. Проверьте несколько сценариев:
- отправка формы в обычном окне браузера;
- отправка в режиме инкогнито;
- отправка после полной перезагрузки страницы;
- отправка на мобильном размере экрана;
- отправка после очистки кеша браузера и кеша плагина.
В идеале вы должны увидеть:
- корректный AJAX-запрос без ошибок;
- сообщение об успешной отправке;
- письмо или запись в CRM, если они подключены;
- отсутствие новых ошибок в консоли.
Если форма работает только после очистки кеша, значит проблема не решена до конца: где-то остается устаревшая версия HTML или JS.
Частые ошибки и как их исправить
Отключили весь кеш вместо точечного исключения
Это рабочая, но грубая мера. На живом сайте лучше сначала исключить только проблемную страницу или только скрипты формы. Иначе вы теряете смысл кеширования на всем проекте.
Добавили в исключения не тот файл
У WPForms и у темы могут быть похожие названия скриптов. Проверяйте фактический путь в исходном коде страницы, а не ориентируйтесь на догадки. Ошибка здесь выглядит так: исключение есть, а форма все равно не отправляется.
Оставили delay JS включенным для критичных скриптов
Это частая причина, когда форма визуально загружается, но не реагирует на отправку. Если плагин умеет исключать отдельные скрипты из delay, используйте именно это, а не полное отключение оптимизации.
Не проверили конфликт с минификацией
Иногда ломает не кеш, а именно минификатор, который меняет порядок или объединяет код. Если отключение кеша не помогло, тестируйте минификацию отдельно.
Смотрят только на фронтенд, игнорируя логи
Если запросы получают 403, 400 или 500, ищите причину в серверных логах, правилах безопасности, WAF или в настройках защиты от спама. На стороне браузера это выглядит как «форма не работает», но источник ошибки может быть на сервере.
Что учесть по безопасности и производительности
Не стоит держать страницу формы полностью без кеша, если можно обойтись исключением только для JS или только для одного URL. Но и агрессивная оптимизация ради скорости не должна ломать отправку. Для форм это плохой компромисс.
Если на сайте много форм, имеет смысл отдельно проверить:
- не конфликтует ли кеш с защитой от спама;
- не ломает ли оптимизация валидацию полей;
- не отдается ли старый HTML после обновления формы;
- не мешают ли сторонние скрипты аналитики и виджетов.
Для сайтов, где часто приходится чистить дубли, отключать лишнее и наводить порядок в технических настройках, полезно держать под рукой инструменты вроде Clearfy Pro: он помогает убрать часть лишней нагрузки и уменьшить число конфликтов между оптимизацией и фронтендом. Но даже с таким набором все равно нужно проверять конкретную страницу с формой вручную.
Если после всех исключений форма по-прежнему не отправляется, следующий шаг — отключить все плагины кроме WPForms и временно переключиться на стандартную тему. Это самый быстрый способ понять, проблема в кешировании или в другом слое сайта.