Как сбрасывать кэш WP Super Cache при изменении меню и виджетов WordPress

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

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

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

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

Быстрая диагностика

• Откройте страницу в режиме инкогнито и сравните с обычным окном.
• Проверьте ответ заголовков через curl -I https://example.com/ и посмотрите, есть ли признаки кэширования на уровне сервера или CDN.
• Временно отключите CDN, если он есть, и обновите страницу с принудительной перезагрузкой.
• Измените текст в виджете или пункт меню, затем проверьте не только главную, но и несколько внутренних страниц.

Если на части страниц изменения видны, а на части нет, чаще всего проблема в том, что кэш сбрасывается не по тем событиям. Если же не обновляется вообще ничего, сначала проверьте, не включён ли отдельный серверный кэш поверх WP Super Cache.

Какой подход выбрать: через хуки темы, через плагин или вручную

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

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

Пошаговое решение: сброс кэша при изменении меню

WordPress сохраняет меню как набор объектов, и при обновлении навигации можно зацепиться за событие wp_update_nav_menu. Внутри него удобно вызвать очистку кэша WP Super Cache. Важно не делать это на каждом рендере страницы, а только при фактическом сохранении меню.

<?php
/**
 * Plugin Name: Menu cache flush for WP Super Cache
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'wp_update_nav_menu', 'wpsc_flush_cache_on_menu_update', 10, 1 );

function wpsc_flush_cache_on_menu_update( $menu_id ) {
    if ( function_exists( 'wp_cache_clear_cache' ) ) {
        wp_cache_clear_cache();
    }
}

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

<?php
add_action( 'wp_update_nav_menu', 'wpsc_flush_cache_on_menu_update', 10, 1 );

function wpsc_flush_cache_on_menu_update( $menu_id ) {
    $last_flush = get_transient( 'wpsc_last_menu_flush' );

    if ( $last_flush ) {
        return;
    }

    if ( function_exists( 'wp_cache_clear_cache' ) ) {
        wp_cache_clear_cache();
        set_transient( 'wpsc_last_menu_flush', 1, 60 );
    }
}

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

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

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

<?php
add_action( 'update_option_sidebars_widgets', 'wpsc_flush_cache_on_widgets_update', 10, 2 );

function wpsc_flush_cache_on_widgets_update( $old_value, $value ) {
    if ( function_exists( 'wp_cache_clear_cache' ) ) {
        wp_cache_clear_cache();
    }
}

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

Когда лучше добавить ещё один триггер

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

<?php
add_action( 'customize_save_after', 'wpsc_flush_cache_on_customizer_save' );

function wpsc_flush_cache_on_customizer_save() {
    if ( function_exists( 'wp_cache_clear_cache' ) ) {
        wp_cache_clear_cache();
    }
}

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

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

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

• Измените пункт меню и сохраните его.
• Откройте главную и несколько внутренних страниц в инкогнито.
• Проверьте, что новый пункт или изменённый текст появился без ручной очистки кэша.
• Измените виджет и повторите проверку на страницах, где этот виджет выводится.
• Посмотрите логи, если у вас включён debug, и убедитесь, что очистка не вызывается на каждом запросе.

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

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

Кэш очищается, но старая версия всё равно видна

Обычно это не WP Super Cache, а ещё один слой кэширования: CDN, серверный reverse proxy или браузерный кэш. Проверяйте цепочку целиком. Если используется Cloudflare или другой CDN, очистка только в WordPress не обновит внешний слой.

Очистка вызывается слишком часто

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

Код добавили в functions.php, а он не работает

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

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

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

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

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

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

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