Что обязано входить в ключ ajax-блока

Ключ ячейки блока — это ответ на вопрос «при каких условиях разметка будет одинаковой». Забыли что-то положить в ключ — один вариант разметки получают все. Три случая, когда это ударило по живым посетителям.

Это третья часть цикла «Кэш фрагментов и Redis».

1. Хост: отравление поддоменов

У каталога с региональными поддоменами блоки содержат ссылки и телефоны региона. Фоновый воркер работает в контексте основного домена — и если он рендерит ячейку поддомена, то пишет под её ключ ссылки и телефоны основного сайта. Посетитель поддомена получает чужие контакты.

Лечение двойное: хост в ключе и «канонический шлюз» — на поддомене устаревшая ячейка считается MISS и пересобирается в запросе посетителя, в правильном контексте, а не фоном.

2. Мобильность — из User-Agent, а не из запроса

Фронт присылал признак мобильного устройства параметром: mob=false. Сервер проверял его через isset. Но строка «false» существует — isset всегда давал true. Одна ячейка на всех, и десктоп получал мобильную сетку.

Признак этой ошибки в реестре — странная ячейка, где в ключе одновременно «десктоп» и мобильный параметр. Лечение — определять устройство на сервере по User-Agent, так же, как это делает ключ кэша страниц.

3. Параметры формы

Всплывающая форма «узнать цену» строилась под товар: название, картинка, цена. Параметры товара в ключ не входили. Первый, кто открыл форму, запёк в кэш свой товар — и все остальные видели его. Кнопка «Заказать» на другой странице открывала форму с ценой 0 ₽ и без картинки.

Вдобавок имена параметров расходились: фронт слал id, сервер ждал post_id.

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

Правило при смене ключа