Как отключить кэш WP Super Cache для администраторов и редакторов в WordPress

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

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

Когда это нужно и как проявляется проблема

Сценарий обычно выглядит так:

• администратор входит на сайт и видит старую версию страницы после правок;
• редактор меняет запись, но на фронтенде изменения не появляются сразу;
• часть блоков зависит от авторизации, но страница отдаётся как статическая копия;
• после выхода из учётной записи всё отображается нормально.

Это особенно заметно, если на странице есть динамические элементы: приветствие по роли, кнопки редактирования, персональные блоки, данные из произвольных полей, которые обновляются нечасто, но должны быть точными для авторизованных пользователей.

Что проверить до изменения настроек

Прежде чем править конфигурацию, убедитесь, что проблема именно в кэше:

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

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

Пошаговое решение: отключаем кэш для авторизованных пользователей

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

Шаг 1. Включите режим без кэша для авторизованных

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

Если у вас есть кастомные правки в wp-config.php или mu-плагинах, убедитесь, что они не переопределяют поведение плагина.

Шаг 2. Добавьте проверку по роли, если нужно отключить кэш только для части пользователей

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

<?php
/**
 * Plugin Name: Disable cache for editors and admins
 */
add_action('init', function () {
    if (is_admin()) {
        return;
    }

    if (!is_user_logged_in()) {
        return;
    }

    $user = wp_get_current_user();
    $roles = (array) $user->roles;

    if (array_intersect($roles, array('administrator', 'editor'))) {
        if (!defined('DONOTCACHEPAGE')) {
            define('DONOTCACHEPAGE', true);
        }
    }
});

Этот код лучше положить в небольшой mu-плагин, а не в functions.php темы. Так он не потеряется при смене темы и не зависит от шаблона.

Шаг 3. Если нужен более жёсткий запрет, отключите кэш по cookie

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

<?php
add_action('init', function () {
    foreach ($_COOKIE as $name => $value) {
        if (strpos($name, 'wordpress_logged_in_') === 0) {
            if (!defined('DONOTCACHEPAGE')) {
                define('DONOTCACHEPAGE', true);
            }
            break;
        }
    }
});

Этот вариант полезен, если на сайте есть отдельные роли, кастомная авторизация или нестандартные сценарии входа через SSO.

Сравнение подходов: что выбрать на практике

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

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

После настройки важно не ограничиваться визуальной проверкой в одной вкладке. Кэш может вести себя по-разному в зависимости от cookie, CDN и браузера.

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

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

Мини-проверка через заголовки

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

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

Кэш отключили в плагине, но страница всё равно старая

Значит, проблема не в WP Super Cache. Проверьте:

• CDN;
• серверный кэш Nginx/Apache;
• object cache Redis/Memcached;
• другой плагин оптимизации, который пишет свои правила в .htaccess или конфигурацию сервера.

Кэш отключился для всех пользователей

Обычно это происходит, когда код с DONOTCACHEPAGE срабатывает слишком рано и без проверки роли. Не ставьте глобальный запрет на кэш в init без условий. Сначала проверьте is_user_logged_in(), потом роль или capability.

Редактор видит актуальный контент, но медленно открывает сайт

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

Настройка ломает предпросмотр записей

Предпросмотр в WordPress и так работает по отдельному сценарию. Если вы добавили жёсткий запрет на кэш по cookie, проверьте, не задевает ли он preview-запросы и не конфликтует ли с плагинами редактора.

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

Не храните такой код в теме, если сайт живёт долго и над ним работают несколько разработчиков. Лучше оформить маленький mu-плагин или отдельный must-use файл. Так вы не потеряете настройку при обновлении темы.

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

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

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

• Проверили, что проблема воспроизводится только у авторизованных пользователей.
• Убедились, что внешний CDN и серверный кэш не перебивают WP Super Cache.
• Добавили отключение кэша по роли или по cookie.
• Протестировали гостя, администратора и редактора отдельно.
• Проверили, что после обновления записи изменения видны сразу.

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