Страницы белые, изменения не видно - первая мысль: сбросить кеш. Разбираем порядок сброса и случаи, когда кеш вообще не виноват.
Симптом
Правки не появляются на сайте
Вы правите шаблон или текст, обновляете страницу - а там всё по-старому. Или одна страница обновилась, а соседняя нет. Первый инстинкт - гасить весь кеш. Сначала разберём, что вы чистите и что это может сломать.
Причина
Кешей несколько, и они живут в разных местах
Кеш - собранная копия страницы или данных, которую Битрикс хранит и отдаёт без пересчёта, пока та не устареет.
Перечислю четыре вида кешей, с которыми вы работаете девять раз из десяти:
- файловый кеш компонентов и страниц - готовые куски HTML и результаты выборок,
/bitrix/cache/; - управляемый кеш - копии настроек: инфоблоки, свойства, меню, шаблоны (.
.top.menu.php- как раз «меню»),/bitrix/managed_cache/; - opcache PHP - компилированный байт-код .php-файлов, его держит сам PHP, Битрикс тут не при чём;
- браузер - ваша собственная копия страницы, отдаёт её пока не истечёт Cache-Control;
Оттого и симптом, что «пол-страницы обновилось»: кусок отдаётся из старого кеша, кусок пересчитался заново.
Решение
Порядок чистки: от лёгких к тяжёлым
Шаг 1. Сброс файлового кеша в админке
Админка: Настройки -> Настройки продукта -> Автокеш. Кнопка очистки файлов кеша - основной инструмент. Один полный сброс чистит оба вида: файловый и управляемый.
После полного сброса первые хиты сайта идут медленнее обычного: Битрикс пересобирает всё с нуля. Это нормально. Если правок было много, подождите минуту и продолжайте.
Шаг 2. Сброс из командной строки
Когда правки идут скриптом (миграция, выкладка на сервер), кеш чистят те же руки, что меняли данные. В PHP-сценарии достаточно одной функции:
<?php
require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
// true - полный сброс (файловый + управляемый)
BXClearCache(true);Этот же вызов удобно дать после обновления статей скриптом - чтобы читатель сразу увидел то, что вы опубликовали.
Шаг 3. Если кеш не виноват
Если правки всё ещё не видны, идём дальше по цепочке:
- откройте страницу в режиме инкогнито - нет ли кеша браузера;
- если правился .php файл, а opcache на сервере держит время жизни - нужен restart php (проверьте
opcache.validate_timestamps); - если стоит CDN - сбросьте кеш по URL у CDN.
✓ Делайте так
- чистите кеш сразу после правок шаблона - пока вы там, ничего не забудете;
- первая загрузка после сброса идёт медленнее - кеш собирается с нуля;
- при больших правках начинайте с файлового кеша; управляемый трогайте, только если правки касаются структуры - инфоблоки, свойства, меню;
✗ Так не делайте
- не чистите кеш «на каждый чих» - вы съедите производительность и приучите себя не понимать, что происходило;
- не ставьте у компонентов
"CACHE_TYPE" => "N"«чтобы кеш не мешал» - найдите, кто его держит; - не сбрасывайте полный кеш на пике нагрузки - пересборка всё съест на первых хитах.
Частые вопросы
Опасно ли чистить кеш на проде?
Сами по себе данные не теряются: кеш - копия, которую легко собрать заново. Платите временем: первые запросы идут медленнее. На слабом сервере (у нас - 1 ГБ RAM) подождите пару минут перед следующим большим изменением.
Как узнать, что кеш вдруг «не виноват»?
Три быстрых признака: страница работает стабильно - это кеш; в другом браузере правка уже на месте, в вашем нет - это кеш браузера; сброс из админки устранил всё разом - это был файловый кеш Битрикса.