Фоновый рендер наследует не то окружение

Фоновый воркер рендерит блоки из крона — в командной строке, без веб-запроса. Функция рендера та же, что у посетителя. А результат — другой: ссылки на картинки по http вместо https, и на сайте по https браузер их блокирует.

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

Карточки без картинок

Жалоба: «в каталоге иногда карточки без картинок». Иногда — потому что часть ячеек собирал посетитель (правильно), а часть — воркер. В командной строке нет $_SERVER['HTTPS'], is_ssl() возвращает false, и WordPress собирает все ссылки по http. Страница по https, картинка по http — смешанное содержимое, браузер её не загружает.

Лечение — перед рендером в воркере выставить окружение так, как его видит веб-запрос:

function frag_cli_env(): void {
    $_SERVER['HTTPS']       = 'on';
    $_SERVER['SERVER_PORT'] = 443;
    $_SERVER['HTTP_HOST']   = cache_site_host();
    $_SERVER['HTTP_USER_AGENT'] = $_SERVER['HTTP_USER_AGENT'] ?? UA_DESKTOP;
}

То же — в генераторе миниатюр

Та же ошибка нашлась в нашем плагине миниатюр ACH Thumbnail: адрес каталога кэша строился через is_ssl(). Миниатюры, нарезанные фоном, получали адрес по http — у 47 постеров видео он был таким. Исправили в самом плагине: вне веб-запроса схема берётся из адреса сайта.

Чек-лист окружения для фонового рендера

Что	Почему важно
схема (HTTPS)	иначе http-ссылки и смешанное содержимое
хост (HTTP_HOST)	входит в ключ, от него зависят абсолютные ссылки
User-Agent	от него зависит мобильная разметка и ключ

Почему не просто HTTP-запрос к себе

Можно было бы рендерить блок обычным запросом к своему сайту — окружение было бы правильным. Но из контейнера запрос на собственный внешний адрес часто не проходит: он уходит на внешний адрес сервера и не возвращается обратно внутрь. Поэтому воркер вызывает PHP-функцию напрямую и окружение выставляет сам.