WP_HOME из заголовка Host: кэш-код видит чужой домен

В конфиге WordPress часто пишут адрес сайта из заголовка запроса: «какой хост спросили — тот и мой». Это удобно для тестовых копий и переездов. Но кэш-код, который решает «кто я» по адресу сайта, в запросе на чужое имя видит чужой домен.

Это двадцать пятая часть цикла «Кэш страниц без MISS».

// wp-config.php
define('WP_HOME',    'https://' . $_SERVER['HTTP_HOST']);
define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);

А nginx с server_name _ принимает запрос на любое имя, которое указывает на сервер: www., старые поддомены, dev..

Что случилось

Выкат первым «заметил» поисковый бот, пришедший на www. и dev.. Детектор сработал в его запросе, и get_option('home') вернул имя бота. Код прогрева искал свой сервер по имени домена — и не нашёл. Очередь не встала.

Итог: в кэше 12 файлов, следующий прогрев — только через 6 часов по расписанию.

Тихий вариант той же дыры

Даже если прогрев стартует, он может греть не те ячейки: заголовок Host прогрева тоже берётся из адреса сайта. В запросе на чужое имя прогрев заполнит кэш вариантами для www., а настоящие страницы останутся холодными. Хост входит в ключ кэша (шестая часть).

Лечение

Для своих нужд кэш-код читает канонический адрес из базы напрямую, мимо константы:

function cache_site_host(): string {
    static $host = null;
    if ($host === null) {
        global $wpdb;
        $home = $wpdb->get_var(
            "SELECT option_value FROM {$wpdb->options} WHERE option_name = 'home'"
        );
        $host = (string) parse_url((string) $home, PHP_URL_HOST);
    }
    return $host;
}

И им пользуются и поиск своего сервера, и заголовок Host прогрева.