My Popup не сохраняет настройки после очистки кэша: как найти причину и исправить

Автор: Ксения Алексеева | Опубликовано: 21.09.2026

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

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

Что именно ломается: база, кэш или браузер

Сначала важно разделить проблему на три уровня. Если этого не сделать, легко потратить время на очистку кэша там, где виноват PHP-код, или наоборот.

1. Настройки не записываются в WordPress

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

2. Настройки записались, но фронтенд показывает старую версию

Это типичный случай при полном кэшировании страниц, агрессивной минификации JS/CSS или CDN. Админка показывает новое значение, а посетитель видит старое, потому что HTML страницы или скрипт инициализации попапа берётся из кэша.

3. Настройки сохранены, но браузер помнит старое состояние

Если My Popup использует cookie или localStorage для контроля повторного показа, старое состояние может маскировать обновление. Например, вы изменили текст и логику показа, но в браузере уже лежит флаг, который скрывает окно.

Диагностика проблемы: что проверить в первую очередь

Начните с простых проверок. Они занимают несколько минут и сразу отсекают половину ложных гипотез.

Откройте страницу в режиме инкогнито и проверьте, меняется ли поведение попапа.
Сравните отображение на обычной странице и на странице после полной очистки кэша плагина, сервера и CDN.
Проверьте, сохраняются ли изменения в админке после перезагрузки страницы настроек.
Посмотрите консоль браузера на наличие ошибок JavaScript в админке и на фронтенде.
Временно отключите минификацию и объединение JS, если они включены.

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

Пошаговое решение

Шаг 1. Убедитесь, что проблема не в кэше страницы

Если сайт использует page cache, после сохранения настроек My Popup может продолжать отдавать старый HTML. Это особенно заметно, когда попап вставляется в шаблон страницы или выводится через скрипт, который инициализируется вместе с HTML.

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

Шаг 2. Проверьте, не мешает ли localStorage или cookie

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

// В консоли браузера можно временно очистить localStorage для проверки
localStorage.clear();

// Если попап использует cookie, удалите их для домена через DevTools
// Application -> Cookies -> ваш домен

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

Шаг 3. Исключите конфликт минификации и отложенной загрузки

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

На время диагностики отключите:

объединение JS-файлов;
defer/async для скриптов плагина;
delay JavaScript execution;
оптимизацию inline-скриптов, если она затрагивает код инициализации.

Шаг 4. Проверьте сохранение через REST или AJAX-запрос

Если настройки сохраняются через AJAX, ошибка может быть не в кэше, а в том, что запрос не доходит до сервера или получает 403/500. Откройте DevTools, вкладку Network, и сохраните настройки ещё раз. Важно увидеть статус ответа и тело ответа.

Если ответ содержит ошибку nonce, права или PHP warning, это уже не проблема кэша. Тогда надо смотреть логи сервера и конфликт плагинов.

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

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

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

<?php
// Пример для темы или небольшого mu-plugin: вывод версии в body class
add_filter('body_class', function ($classes) {
    if (is_singular()) {
        $classes[] = 'popup-debug-' . get_the_ID();
    }
    return $classes;
});

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

Если проблема в кэширующем плагине: как настроить исключения

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

Подход	Когда подходит	Минус
Исключить страницу из кэша	Если попап зависит от часто меняющегося контента	Страница загружается без кэширования
Оставить кэш, но не кэшировать скрипт инициализации	Если проблема только в JS	Нужно аккуратно настроить исключения
Использовать cookie/localStorage для контроля показа	Если важно не показывать попап повторно	Нужно следить за логикой сброса состояния

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

Пример: как сбросить старое состояние попапа на стороне браузера

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

// Очистка только ключей, связанных с popup, если вы знаете их имена
Object.keys(localStorage).forEach(function (key) {
    if (key.indexOf('popup') !== -1 || key.indexOf('mypopup') !== -1) {
        localStorage.removeItem(key);
    }
});

// Аналогично можно удалить отдельные cookie через браузерные инструменты

Если после этого попап начинает вести себя правильно, значит серверная часть работает, а проблема была в клиентском состоянии.

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

Очистили только один уровень кэша

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

Смотрят только в админку

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

Не проверяют консоль и Network

Ошибки JavaScript и 403/500 в запросах сохранения — частая причина ложного ощущения, что виноват кэш. Без DevTools вы просто не увидите реальную ошибку.

Слишком агрессивно включают оптимизацию JS

Delay JS, defer и объединение файлов часто ломают плагины, которые рассчитывают на раннюю инициализацию. Если после отключения оптимизации всё заработало, добавляйте исключения точечно, а не выключайте весь механизм на сайте.

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

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

Если вы правите код темы или подключаете небольшой mu-plugin для диагностики, не вставляйте тестовые фрагменты в functions.php надолго. После проверки уберите временный код, чтобы не оставить лишние фильтры и не усложнить поддержку.

Если проблема повторяется после обновлений, проверьте, не меняет ли плагин кэширования правила для inline-скриптов и не удаляет ли он nonce из AJAX-запросов. Это особенно важно на сайтах с жесткой оптимизацией фронтенда.

Когда стоит идти не в кэш, а в логи и код

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

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

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