Доработка сайта на Битрикс и кеш: как менять данные, чтобы изменения сразу были видны

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

Что именно означает «доработка сайта на Битрикс и кеш»

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

Границы задачи: работаем только с существующим проектом, не меняем архитектуру кеширования целиком, не трогаем production без копии и плана возврата. Артефакт — карта кеша участка: какие компоненты кешируются, по каким ключам, что сбрасывает кеш. На её основе принимается решение, как сделать правку видимой.

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

Важно различать уровни кеша. Кеш компонента хранит результат работы компонента. Управляемый кеш обновляется при изменении данных, если компонент его поддерживает. HTML-кеш отдаёт готовую страницу анонимному посетителю. Композитный сайт — механизм кеширования страниц, заменивший HTML-кеш в версиях 16.0.14 и выше. Каждый уровень по-разному влияет на то, увидят ли пользователи правку.

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

Карта кеша участка: что фиксируем до правок

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

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

Как собрать карту. Откройте страницу в режиме правки и посмотрите настройки кеширования у каждого компонента. Проверьте, включено ли автокеширование на сайте. Уточните, используется ли управляемый кеш. Проверьте настройки Композитного сайта (вместо устаревшего HTML-кеша). Зафиксируйте результат в таблице. Если участок меняется часто, стоит подумать о том, чтобы вынести его в отдельный компонент с управляемым кешем.

Зачем это нужно. Карта показывает, где правка «застрянет». Если компонент кешируется по ключу, который не включает изменяемый параметр, правка не появится до сброса. Если включен Композитный сайт (или устаревший HTML-кеш), страница может отдаваться из кеша даже после обновления компонента. Карта помогает выбрать решение осознанно.

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

Таблица решений: сбросить, добавить в ключ или отключить

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

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

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

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

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

Шаг 1. Зафиксируйте задачу и критерии приёмки. Что именно должно измениться, на какой странице, для каких пользователей. Без этого невозможно проверить результат.

Шаг 2. Соберите карту кеша участка. Определите компоненты, режимы, ключи, что сбрасывает кеш. Зафиксируйте в таблице.

Шаг 3. Сделайте копию. Перед изменениями на production нужна резервная копия и план возврата. На стенде — отдельная копия данных.

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

Шаг 5. Проверьте на стенде. Сначала с включённым кешем, потом с отключённым. Сравните результат. Убедитесь, что правка видна и не ломает другие участки.

Шаг 6. Выберите решение по таблице. Сбросить, добавить в ключ или отключить на время. Зафиксируйте выбор и обоснование.

Шаг 7. Выпустите на production. После релиза проверьте страницу как анонимный пользователь и как авторизованный. Убедитесь, что кеш не отдаёт старую версию.

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

Как оформить постановку задачи на доработку

Постановка задачи должна быть конкретной. Вместо «поправить вывод» — «на странице каталога в блоке новинок выводить поле «Артикул» рядом с названием товара для всех посетителей». Чем точнее формулировка, тем проще проверить результат.

Что включить в постановку. Первое — страница или раздел. Второе — конкретный блок или компонент. Третье — что должно измениться: текст, поле, порядок, условие. Четвёртое — для кого: все посетители, авторизованные, конкретная группа. Пятое — критерии приёмки: как понять, что задача выполнена.

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

Формулировка границ. В задаче стоит указать, что не входит: переписывание слоя кеширования, изменение архитектуры, оптимизация производительности. Это помогает не расширять объём работ незаметно.

Пример плохой постановки: «Сделать, чтобы новости обновлялись». Пример хорошей: «На главной странице в блоке «Последние новости» выводить заголовки за последние 7 дней вместо 30. Обновление должно быть видно анонимным посетителям сразу после публикации новости». Вторая формулировка даёт разработчику всё необходимое.

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

Учебный пример: правка в блоке новинок

Учебный пример. Компания «Условный магазин» просит изменить вывод в блоке новинок на странице каталога. Сейчас блок показывает товары, добавленные за последние 30 дней. Нужно — за последние 14 дней. Данные о компании и количестве товаров условны.

Входные условия. Страница каталога, компонент вывода новинок, кеширование включено в режиме «Авто + Управляемое». Управляемый кеш включён на сайте. HTML-кеш не используется. Опция учёта прав доступа не включена. Стенд с копией данных есть.

Действия. Разработчик собирает карту кеша: компонент новинок, режим «Авто + Управляемое», ключ включает параметр периода. Меняет значение периода с 30 на 14 в настройках компонента. Проверяет на стенде: с включённым кешем и после сброса. Убеждается, что блок показывает товары за 14 дней.

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

Проверка. Тестировщик открывает страницу каталога как анонимный пользователь, затем как авторизованный. Сравнивает список товаров с ожидаемым. Проверяет, что другие блоки не изменились. Убеждается, что при добавлении нового товара он появляется в блоке.

Ограничение примера. В реальном проекте компонент может не поддерживать управляемый кеш, или может быть включён HTML-кеш. Тогда решение будет другим. Пример показывает логику, а не готовый рецепт.

Матрица проверок после доработки

После внесения правки нужно проверить несколько сценариев. Матрица проверок помогает не пропустить важное.

Как пользоваться матрицей. Пройдите по строкам последовательно. Если какой-то пункт не выполняется, зафиксируйте это и вернитесь к карте кеша. Возможно, решение выбрано неверно.

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

Проверка на стенде не гарантирует поведение на production. Разные данные, разные настройки, разный объём кеша. Поэтому после релиза нужна отдельная проверка.

Чек-лист приёмки доработки

• Задача сформулирована конкретно: страница, блок, что меняется, для кого.
• Критерии приёмки зафиксированы до начала работ.
• Карта кеша участка собрана и обновлена.
• Резервная копия сделана перед изменениями на production.
• План возврата описан.
• Правка проверена на стенде с включённым кешем.
• Правка проверена на стенде с отключённым кешем.
• Решение по кешу выбрано осознанно и обосновано.
• После релиза проверено поведение для анонимного пользователя.
• После релиза проверено поведение для авторизованного пользователя.
• Соседние блоки проверены на регресс.
• Карта кеша обновлена по итогам доработки.

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

Типичные ошибки и ограничения

Ошибка первая: сбросить кеш компонента, но забыть про HTML-кеш. Страница остаётся старой, хотя компонент обновился. Решение — проверить все уровни кеша.

Ошибка вторая: не учитывать привязку кеша к группам пользователей. Администратор видит правку, анонимный посетитель — нет. Решение — проверить настройку учёта прав доступа.

Ошибка третья: отключить кеш на production и забыть включить обратно. Нагрузка на базу растёт, сайт может работать медленнее. Решение — отключать кеш только на стенде или на время с чётким планом возврата.

Ошибка четвёртая: ожидать, что компонент без поддержки управляемого кеша будет обновляться автоматически. Это не так. Решение — проверить поддержку или выбрать другое решение.

Ошибка пятая: не обновить карту кеша после доработки. При следующей правке придётся собирать заново. Решение — фиксировать изменения.

Ограничения. Не все компоненты поддерживают управляемый кеш. HTML-кеш имеет свои маски включения и исключения. Композитный сайт — отдельный механизм. Кеш может храниться в файлах или в Memcached. Эти факторы влияют на выбор решения.

Если доработка затрагивает релиз, полезно свериться с Релизы сайта Битрикс: как безопасно выпускать доработки — это поможет безопасно выпустить изменения. Не превращайте лонгрид в конспект.

Что делать дальше

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

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

Если доработок много, полезно свериться с Как проверить смету доработки сайта: разбор оценки по задачам — это поможет понять объём работ.

Для комплексных задач, связанных с изменением существующего проекта, можно обратиться к доработке сайтов на 1С-Битрикс — это профильная услуга.