Как отключить OPcache для отдельных файлов в WordPress и не сломать кэширование

Автор: Дмитрий Громов | Опубликовано: 27.09.2026

OPcache ускоряет PHP, но в WordPress он иногда мешает там, где нужен предсказуемый результат: при отладке темы, правке mu-plugin, тестировании хуков или проверке срочного фикса после деплоя. Типичный симптом — файл уже изменён, а сайт продолжает работать по старой версии кода. Полностью отключать OPcache ради одного сценария обычно не нужно: безопаснее понять, где именно возникает рассинхрон, и точечно убрать проблему.

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

Сначала проверьте, что вы не путаете OPcache с другими уровнями кэширования. В WordPress старый код может держаться из-за CDN, page cache, object cache, PHP-FPM opcache.validate_timestamps, а иногда и из-за того, что редактируется не тот файл на сервере.

Признаки, которые стоит проверить в первую очередь

изменения в functions.php или плагине не видны сразу после сохранения;
после перезапуска PHP-FPM проблема исчезает;
на одном сервере правка видна, на другом — нет;
в логах нет ошибок, но поведение кода остаётся старым;
после очистки кэша браузера ничего не меняется.

Если у вас включён page cache, сначала очистите его. Если используется Redis/Memcached, проверьте, не кэшируется ли результат функции на уровне объекта. Только после этого имеет смысл смотреть на OPcache.

Диагностика: что именно кэшируется

Для начала посмотрите настройки OPcache на сервере. Если есть доступ к phpinfo() или отдельному диагностическому скрипту, проверьте параметры opcache.enable, opcache.validate_timestamps и opcache.revalidate_freq. Именно они чаще всего объясняют, почему PHP продолжает исполнять старую версию файла.

<?php
// временный файл для диагностики, не оставляйте его в продакшене
phpinfo();

Если доступ к phpinfo() нежелателен, можно вывести только нужные параметры через ini_get():

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'opcache.enable: ' . ini_get('opcache.enable') . PHP_EOL;
echo 'opcache.validate_timestamps: ' . ini_get('opcache.validate_timestamps') . PHP_EOL;
echo 'opcache.revalidate_freq: ' . ini_get('opcache.revalidate_freq') . PHP_EOL;

Если opcache.validate_timestamps=0, PHP не проверяет изменения файлов сам. Это нормально для продакшена с управляемыми деплоями, но неудобно, если вы правите код вручную через FTP или файловый менеджер.

Что делать: рабочие варианты без полного отключения OPcache

У задачи есть несколько реалистичных сценариев. Выбор зависит от того, где вы работаете: на локальной машине, на staging или на боевом сайте.

Подход	Когда подходит	Минус
Очистка OPcache через PHP-FPM/CLI	После деплоя или срочной правки	Нужен доступ к серверу
Настройка `validate_timestamps`	Если код меняется вручную и часто	Может добавить задержку проверки файлов
Точечный сброс в админке/скрипте	Для staging и отладки	Нельзя оставлять без защиты в продакшене

Вариант 1. Очистить OPcache после деплоя

Если у вас есть доступ к серверу, самый надёжный путь — сбрасывать OPcache после выкладки. Для PHP-FPM это обычно делается через перезапуск сервиса или через отдельный скрипт, который вызывает opcache_reset(). Но такой скрипт нельзя держать открытым без ограничений.

<?php
// запускать только вручную и только на защищённом окружении
if (function_exists('opcache_reset')) {
    opcache_reset();
    echo 'OPcache cleared';
} else {
    echo 'OPcache is not available';
}

Если вы используете деплой по SSH, практичнее очищать кэш после обновления файлов, а не пытаться «обойти» его на уровне WordPress.

Вариант 2. Настроить проверку изменений файлов

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

; php.ini или pool-конфиг PHP-FPM
opcache.enable=1
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Здесь важно не переборщить с частотой. Слишком частая проверка уменьшает выигрыш от OPcache, слишком редкая — создаёт ощущение, что сайт «не видит» изменения. Для продакшена лучше менять код через нормальный деплой, а не вручную.

Вариант 3. Точечно отключить кэш для проблемного файла

Если нужно проверить конкретный файл темы или плагина, можно временно обойти кэш через изменение имени подключаемого файла или через версионирование ассета. Для PHP-файлов это не универсальное решение, но для CSS/JS в WordPress оно работает предсказуемо: меняется URL, и браузер получает новый файл.

<?php
wp_enqueue_style(
    'theme-main',
    get_stylesheet_directory_uri() . '/assets/css/main.css',
    array(),
    filemtime(get_stylesheet_directory() . '/assets/css/main.css')
);

wp_enqueue_script(
    'theme-main',
    get_stylesheet_directory_uri() . '/assets/js/main.js',
    array(),
    filemtime(get_stylesheet_directory() . '/assets/js/main.js'),
    true
);

Это не отключает OPcache для PHP, но убирает частую путаницу: разработчик меняет код, а в браузере видит старый CSS/JS и думает, что виноват серверный кэш.

Пошаговое решение для WordPress-сайта

Очистите page cache в плагине кэширования и CDN, если он есть.
Проверьте, не используется ли object cache, который держит старые данные.
Уточните параметры OPcache на сервере: validate_timestamps и revalidate_freq.
Если вы правите код вручную, включите проверку изменений файлов или используйте нормальный деплой.
После правок сбросьте OPcache через серверный инструмент или перезапуск PHP-FPM.
Проверьте результат в приватном окне и на уровне исходного HTML, а не только в админке.

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

Проверка должна быть не «страница открылась», а «исполняется новый код». Для этого добавьте временный маркер в файл, который точно загружается, например в functions.php дочерней темы или в тестовый mu-plugin.

<?php
add_action('wp_footer', function () {
    echo "<!-- build: 2026-09-27-1 -->";
});

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

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

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

Отключают OPcache целиком на боевом сайте

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

Путают OPcache с кэшем плагина

Если после очистки OPcache ничего не меняется, проверьте page cache, CDN и object cache. В WordPress старый результат часто хранится не в PHP, а выше по цепочке.

Оставляют открытый скрипт для `opcache_reset()`

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

Меняют файл через FTP, но смотрят на старую сборку

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

Безопасность и производительность

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

Если у вас часто возникают проблемы с дублями, кэшем и технической чисткой сайта, часть задач можно закрывать плагином вроде Clearfy Pro, но он не заменяет серверную настройку OPcache. Он помогает на уровне WordPress, а не PHP-движка.

Когда стоит идти не в код, а в инфраструктуру

Если изменения в WordPress регулярно «теряются», это обычно не проблема одной функции. Чаще всего нужно смотреть на связку: способ деплоя, PHP-FPM, OPcache, CDN и плагин кэширования. Пока эта цепочка не выстроена, точечные правки будут давать нестабильный результат.

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