Как отладить проблемы с отображением WPForms в Gutenberg и кэшированием страниц

Автор: Алексей Борисов | Опубликовано: 13.08.2026

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

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

Как понять, где именно ломается отображение

Начинать лучше не с кода, а с диагностики. У WPForms и Gutenberg есть несколько типовых точек отказа: блок не рендерится в редакторе, shortcode выводится как текст, на странице нет CSS/JS формы или кэш отдает старую сборку страницы.

Проверка в редакторе и на фронтенде

Сначала откройте страницу в редакторе Gutenberg и убедитесь, что блок WPForms действительно вставлен, а не заменен на обычный HTML-блок или текстовый шорткод. Затем проверьте страницу в режиме инкогнито и с отключенными расширениями браузера. Если в редакторе форма есть, а на сайте нет, проблема почти наверняка на стороне темы, кэша или оптимизации.

форма видна в редакторе, но не видна на сайте — смотрим кэш, минификацию и шаблон;
форма видна только после очистки кэша — конфликт с кеширующим плагином или CDN;
вместо формы отображается shortcode — блок не распознан или отключен плагин WPForms;
форма есть, но стили сломаны — не подгрузились CSS/JS или их отложила оптимизация.

Что смотреть в консоли браузера

Откройте DevTools и проверьте вкладки Console и Network. Если в консоли есть ошибки JavaScript, особенно связанные с wpforms, jquery или wp-block-library, сначала исправляйте их. Если в Network не грузятся файлы формы или они получают 404/403, проблема уже не в Gutenberg, а в путях, правах или фильтрах оптимизации.

Пошаговое решение: от простого к точному

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

1. Очистите все уровни кэша

Очистите кэш плагина, серверный кэш, CDN и браузерный кэш. Если используется Cloudflare или аналогичный сервис, проверьте, не включено ли агрессивное кеширование HTML. Для теста полезно временно отключить оптимизацию на странице с формой и сравнить результат.

2. Проверьте, не ломает ли страницу оптимизатор скриптов

Плагины для ускорения сайта часто откладывают или объединяют скрипты, а форма WPForms может из-за этого терять инициализацию. Если у вас включены defer, delay JavaScript, объединение файлов или удаление неиспользуемого CSS, добавьте исключения для скриптов и стилей WPForms.

Ниже пример, как можно исключить скрипты WPForms из отложенной загрузки в плагинах, которые поддерживают фильтрацию по URL. Конкретный фильтр зависит от плагина, поэтому это скорее ориентир для настройки, а не универсальный код для вставки в functions.php.

// Пример: исключаем файлы WPForms из отложенной загрузки на уровне логики темы/плагина оптимизации.
$exclude = array(
    'wpforms',
    'wpforms-lite',
    'wpforms.min.js',
    'wpforms-full.min.js',
);

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

3. Убедитесь, что блок Gutenberg не заменяется на устаревший шорткод

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

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

4. Проверьте шаблон темы и область контента

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

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

Когда нужен код: безопасная точечная проверка

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

add_filter( 'the_content', function( $content ) {
    if ( is_page( 123 ) ) {
        error_log( 'Content length: ' . strlen( $content ) );
        if ( strpos( $content, 'wpforms' ) !== false ) {
            error_log( 'WPForms markup found in content.' );
        }
    }

    return $content;
}, 20 );

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

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

add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {
    if ( strpos( $src, 'wpforms' ) !== false ) {
        return str_replace( ' src=', ' data-no-optimize="1" src=', $tag );
    }

    return $tag;
}, 10, 3 );

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

Как проверить, что решение сработало

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

откройте страницу в инкогнито и проверьте, что форма видна;
посмотрите исходный код страницы и убедитесь, что разметка WPForms присутствует;
в консоли браузера нет ошибок JavaScript, связанных с формой;
в Network загружаются CSS и JS WPForms без 404/403;
после очистки кэша изменения в форме сразу видны на фронтенде.

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

Частые ошибки и как их исправить

Форма есть в редакторе, но не видна на сайте

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

После обновления формы на сайте ничего не меняется

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

Вместо формы выводится текст шорткода

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

Форма отображается, но не отправляется

Это уже не проблема Gutenberg, а конфликт JavaScript. Смотрите консоль, исключайте скрипты WPForms из defer/delay и проверяйте, не блокирует ли отправку другой плагин безопасности или оптимизации.

Практика по безопасности и производительности

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

Что обычно помогает без лишнего риска:

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

Если нужен более системный контроль над дублями, кэшем и технической чисткой сайта, для WordPress часто используют Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае исключения для форм лучше проверять вручную, а не полагаться на общие пресеты.

Короткий чек-лист перед публикацией

форма вставлена именно блоком WPForms, а не старым шорткодом;
кэш плагина, сервера и CDN очищен;
скрипты WPForms не попадают под defer/delay без исключений;
в консоли браузера нет ошибок;
страница проверена в инкогнито;
после правок форма отправляется и отображается без визуальных сбоев.

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