Если после правок в functions.php, плагине или шаблоне WordPress вы видите старый код, а очистка кеша сайта не помогает, часто виноват не сам WordPress, а OPcache на стороне PHP. Это нормальная серверная оптимизация, но во время отладки она мешает понять, что именно вы изменили и почему результат не обновляется.
Ниже — практический сценарий: как диагностировать проблему, временно отключить OPcache, проверить, что изменения действительно подхватились, и не сломать продакшен лишними экспериментами.
Когда проблема действительно в OPcache
Сначала стоит отделить кеш PHP от кеша страницы и браузера. Если вы меняете PHP-файл, а сайт продолжает отдавать старую логику, но при этом:
- очистка кеша плагина не помогает;
- в браузере открывается актуальная HTML-страница, но PHP-логика ведёт себя по-старому;
- после перезапуска PHP-FPM или Apache всё начинает работать;
— это уже похоже на OPcache или на слишком агрессивную настройку opcache.validate_timestamps.
Быстрая диагностика
Самый надёжный способ — посмотреть параметры OPcache через отдельный PHP-скрипт. Не через админку WordPress, а напрямую на сервере или в тестовом файле.
<?php
header('Content-Type: text/plain; charset=utf-8');
if (!function_exists('opcache_get_status')) {
echo "OPcache недоступен\n";
exit;
}
$status = opcache_get_status(false);
$cfg = opcache_get_configuration();
echo "Enabled: " . (!empty($status['opcache_enabled']) ? 'yes' : 'no') . "\n";
echo "Validate timestamps: " . ($cfg['directives']['opcache.validate_timestamps'] ? '1' : '0') . "\n";
echo "Revalidate freq: " . (int) $cfg['directives']['opcache.revalidate_freq'] . "\n";
echo "Memory usage: " . json_encode($status['memory_usage'], JSON_UNESCAPED_UNICODE) . "\n";Если opcache.validate_timestamps выключен, PHP не будет регулярно проверять, изменился ли файл. Для продакшена это иногда делают осознанно, но для отладки такой режим неудобен: правки могут не подхватываться до ручной очистки кеша или перезапуска PHP.
Как временно отключить OPcache для отладки
Полностью отключать OPcache на боевом сайте обычно не нужно. Практичнее временно изменить настройки на уровне PHP-конфига или через панель хостинга, а после проверки вернуть прежние значения.
Вариант 1: через php.ini или pool PHP-FPM
Если у вас есть доступ к конфигу PHP, найдите секцию OPcache и временно измените параметры:
opcache.enable=0
opcache.enable_cli=0Если отключить модуль нельзя или не хочется, можно оставить его включённым, но заставить PHP чаще проверять изменения файлов:
opcache.enable=1
opcache.validate_timestamps=1
opcache.revalidate_freq=0Для отладки это обычно удобнее, чем полное отключение. PHP будет проверять изменения при каждом запросе, и вы быстрее увидите результат.
Вариант 2: очистить OPcache без выключения
Иногда достаточно сбросить кеш, не трогая настройки. В WordPress это можно сделать только если у вас есть доступ к серверу и включено расширение OPcache. Пример для CLI:
<?php
if (function_exists('opcache_reset')) {
opcache_reset();
echo "OPcache сброшен\n";
} else {
echo "OPcache reset недоступен\n";
}Этот способ полезен после деплоя, когда вы уже загрузили новые файлы, но сервер ещё держит старые байткоды в памяти.
Вариант 3: через панель хостинга
У многих хостеров OPcache можно управлять из панели PHP-настроек. Важный момент: после изменения параметров часто нужен не только сохранённый конфиг, но и перезапуск PHP-FPM или переключение версии PHP. Иначе вы будете смотреть на старые значения и думать, что настройка не сработала.
Пошаговое решение для типового случая
Если задача — быстро проверить правки в теме или плагине, действуйте так:
- Сделайте резервную копию изменяемого файла.
- Проверьте текущие параметры OPcache через
opcache_get_configuration(). - Временно включите
opcache.validate_timestamps=1иopcache.revalidate_freq=0либо сбросьте кеш черезopcache_reset(). - Обновите проблемный PHP-файл.
- Откройте страницу в режиме инкогнито и проверьте результат.
- После отладки верните исходные настройки, если они были изменены только ради проверки.
Если вы работаете на локальной машине, можно вообще отключить OPcache на время разработки. На продакшене лучше не делать это без причины: OPcache снижает нагрузку на PHP, и его отключение может заметно ухудшить отклик сайта.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а по признакам, которые можно повторить.
- Измените в тестовом файле очевидную строку, например заголовок или текст комментария.
- Обновите страницу с жёсткой перезагрузкой браузера.
- Если используется PHP-FPM, посмотрите, не помогает ли перезапуск сервиса.
- Снова проверьте значения OPcache через отдельный PHP-скрипт.
Если после этого изменения видны сразу, значит проблема была именно в кеше PHP. Если нет — ищите другой слой: кеш страницы, CDN, reverse proxy, объектный кеш или автозагрузку классов из другого файла.
| Подход | Когда использовать | Минус |
|---|---|---|
| Полное отключение OPcache | Короткая локальная отладка | Падает производительность PHP |
validate_timestamps=1 и revalidate_freq=0 | Частые правки кода на тестовом стенде | Чуть больше проверок файлов |
opcache_reset() | После деплоя или разовой очистки | Нужно иметь доступ к серверу |
Частые ошибки и как их исправить
Путают OPcache с кешем WordPress
Если вы очистили кеш в плагине, а код не обновился, это не значит, что плагин не работает. Возможно, PHP продолжает исполнять старую версию файла. В таком случае смотрите именно на OPcache и на настройки PHP-FPM.
Меняют файл, который не используется
Иногда правят не тот шаблон или не тот файл плагина. Особенно часто это происходит в дочерней теме, когда активен другой шаблонный файл с тем же именем. Перед поиском кеша проверьте, какой файл реально подключается.
Отключают OPcache на боевом сайте без плана возврата
Так делать не стоит. Если вы временно отключили кеш ради диагностики, сразу зафиксируйте, где именно меняли настройку и как вернуть её обратно. Иначе после завершения работ сайт останется без важной оптимизации.
Не перезапускают PHP после правки конфигурации
На части серверов изменения в php.ini или pool-конфиге вступают в силу только после перезапуска PHP-FPM. Если этого не сделать, вы будете проверять старые значения и искать несуществующую ошибку.
Безопасность и производительность: что важно не забыть
OPcache — это не проблема, а нормальный слой ускорения. Поэтому рабочая схема обычно такая: на локальной машине и тестовом стенде можно ослабить кеширование для удобства отладки, а на продакшене вернуть стабильные настройки и не держать validate_timestamps=0 без понимания последствий.
Если у вас в проекте много ручных правок PHP-файлов, полезно дисциплинировать деплой: сначала загрузка файлов, потом очистка OPcache, потом проверка страницы. Это проще, чем ловить случайные расхождения между кодом на диске и кодом в памяти PHP.
Для сайтов с регулярными изменениями кода иногда удобнее использовать staging-окружение. Там можно спокойно менять настройки OPcache, не рискуя продакшеном и не путая кеши разных уровней.
Если вам нужно дальше разбирать техническую чистку WordPress — дубли, лишние запросы, индексацию и другие серверные мелочи — такие задачи лучше решать по отдельности, а не одной «магической» настройкой. Именно так проще понять, что реально влияет на сайт, а что только создаёт иллюзию ускорения.