Как скрыть вопросы квиза в WordPress до запуска и показывать их по условию

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

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

Когда проблема действительно в логике показа

Сначала стоит отделить баг верстки от ошибки сценария. Если вопросы видны сразу после загрузки страницы, а потом исчезают — это почти всегда CSS/JS-конфликт. Если блок квиза не открывается по кнопке, но разметка есть в HTML, проблема обычно в обработчике события или в том, что скрипт не дождался загрузки DOM.

Что проверить в первую очередь

• есть ли у блока квиза класс или атрибут, который скрывает его до старта;
• не перезаписывает ли тема стиль display или visibility;
• не ломает ли оптимизатор JS порядок загрузки скриптов;
• не рендерится ли квиз внутри кешируемого шаблона без учёта условий показа;
• не дублируется ли один и тот же блок квиза на странице дважды.

Если вы используете плагин квизов, сначала посмотрите, есть ли у него штатная настройка «показывать после клика», «start screen», «intro step» или аналогичный режим. Если такой опции нет, проще и надёжнее добавить тонкий слой своей логики, чем пытаться править шаблон плагина напрямую.

Пошаговое решение: скрываем квиз до запуска

Самый предсказуемый вариант — скрыть контейнер квиза через CSS и открывать его только после события. Это работает и для встроенного квиза, и для блока, который вставлен через шорткод.

1. Добавьте класс для скрытого состояния

Допустим, квиз выводится в контейнере .quiz-shell. Тогда базовое скрытие можно сделать так:

.quiz-shell.is-hidden {
  display: none;
}

.quiz-shell.is-ready {
  display: block;
}

Если вам нужно избежать скачка верстки, вместо display: none можно использовать visibility: hidden и фиксированную высоту, но для квиза чаще удобнее именно полное скрытие до старта.

2. Показывайте блок по клику или по условию

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

<button type="button" class="quiz-start">Начать квиз</button>
<div class="quiz-shell is-hidden" id="quiz-1">
  <!-- разметка квиза -->
</div>

document.addEventListener('DOMContentLoaded', function () {
  const startButton = document.querySelector('.quiz-start');
  const quizShell = document.querySelector('#quiz-1');

  if (!startButton || !quizShell) return;

  startButton.addEventListener('click', function () {
    const canShowQuiz = true; // сюда подставляется ваша логика

    if (!canShowQuiz) {
      return;
    }

    quizShell.classList.remove('is-hidden');
    quizShell.classList.add('is-ready');
  });
});

Если квиз должен открываться только после выбора, например после клика по кнопке «Подобрать результат», проверку можно заменить на чтение атрибута, cookie или значения поля формы.

3. Если нужен серверный контроль, используйте shortcode-логику

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

add_shortcode('quiz_gate', function ($atts, $content = '') {
    $atts = shortcode_atts([
        'show' => 'no',
    ], $atts);

    if ($atts['show'] !== 'yes') {
        return '<p>Квиз будет доступен после выбора сценария.</p>';
    }

    return do_shortcode($content);
});

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

Сравнение подходов: CSS, JS или серверная проверка

Подход	Когда подходит	Минус
CSS + JS	Нужно быстро скрыть блок и открыть по клику	HTML квиза уже есть в странице
Серверная проверка	Нельзя отдавать квиз до выполнения условия	Нужно аккуратно работать с кэшем
Штатный режим плагина	Плагин уже умеет стартовый экран или триггер	Не всегда хватает гибкости

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

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

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

• квиз не виден до действия пользователя;
• после клика контейнер получает класс is-ready и теряет is-hidden;
• в консоли браузера нет ошибок JavaScript;
• при отключённом CSS квиз не ломает остальную верстку;
• при включённом кэше отображается тот же сценарий, что и без кэша;
• если есть условие показа, оно отрабатывает одинаково для разных ролей и устройств.

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

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

Квиз скрыт, но место под него остаётся

Это обычно происходит, когда вместо display: none используется только opacity: 0. Блок невидим, но продолжает занимать место в потоке. Если это мешает, переключайтесь на полное скрытие или оборачивайте квиз в отдельный контейнер.

Скрипт запускается до загрузки DOM

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

Оптимизатор JS ломает порядок выполнения

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

Кэш показывает старую версию сценария

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

Чек-лист перед публикацией

• контейнер квиза скрывается до запуска;
• есть понятный триггер открытия;
• обработчик не зависит от случайного порядка загрузки;
• квиз не дублируется в шаблоне и в шорткоде одновременно;
• кэш очищен после изменения логики;
• проверено поведение на мобильном экране;
• в консоли нет ошибок;
• условие показа не ломает доступность страницы.

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

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

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

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

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

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