Или, как один простой вопрос неожиданно превратился в микро-расследование.

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

Опуская неинтересную предысторию, нынешнее утро застало меня на сайте Context7 — MCP-сервера, обещающего всегда актуальную документацию для огромного количества фреймворков, языков и библиотек.

Впечатляет и вдохновляет. Введенное “wordpress” в поле поиска показало вполне приемлемую картину обновлений. Обратите внимание на третью строку, где мы видим, собственно, официальный репозиторий WordPress (точнее, его зеркало с subversion).

Руки уже потянулись к клавиатуре для установки, как вдруг внимание привлек скромный пункт “Try live” в меню. Что ж, а почему бы и нет? Открываем чат и задаем простейший вопрос: “Последний известный релиз WordPress”.

ИИ последовательно просмотрел несколько пакетов документации (причем /wordpress/wordpress среди них не было) и… сообщил, что последняя известная ему версия WordPress - это 6.7 “Rollins”, вышедшая в ноябре 2024. Эй, а как же “up-to-date” и “version-specific”?! Впрочем, в чате заботливо рассказывают, как узнать версию самостоятельно, но, согласитесь, это несколько не то.

Что ж, возможно, вопрос и в самом деле был некорректен. Попробуем конкретизировать. Спросим об основных отличиях между 6.9 и 7.0, там как раз было одно маленькое, но очень важное изменение, детали которого потребовались мне в проекте. Спрашиваем.

Хм… Кажется, и этот вопрос останется без ответа. Хотя, казалось бы, именно на подобные вопросы должна отвечать “version-specific” документация. Теперь мне уже стало интересно: продолжим конкретизировать.

Что ж, ИИ прав: вопрос был с подвохом, такой функции в WordPress действительно нет, это метод класса. Ложноположительного срабатывания я не получила. Спросим сразу об интересующем нас filter.

Хорошо, мы получили информацию о filter. Единственный момент, который настораживает: доступность фильтра указана с версии 5.6. Впрочем, вернемся к этому немного позже, сначала хорошо бы уточнить информацию о методе, где применяется этот filter. Здесь начинается самое интересное, привожу конкретный код, показанный в ответе:

public function get_page_cache_headers(): array {

    $cache_hit_callback = static function ( $header_value ) {
        return 1 === preg_match( '/(^| |,)HIT(,| |$)/i', $header_value );
    };

    $cache_headers = array(
        // Standard HTTP caching headers.
        'cache-control'     => static function ( $header_value ) {
            return (bool) preg_match( '/max-age=[1-9]/', $header_value );
        },
        'expires'           => static function ( $header_value ) {
            return strtotime( $header_value ) > time();
        },
        'age'               => static function ( $header_value ) {
            return is_numeric( $header_value ) && $header_value > 0;
        },
        'last-modified'     => null,
        'etag'              => null,
        'via'               => null,

        // Vendor/custom headers (ported from AMP plugin → Performance Lab → core).
        'x-cache-enabled'   => static function ( $header_value ) {
            return ( 'true' === strtolower( $header_value ) );
        },
        'x-cache-disabled'  => static function ( $header_value ) {
            return ( 'on' !== strtolower( $header_value ) );
        },

        // Cloudflare.
        'cf-cache-status'   => $cache_hit_callback,

        // Fastly.
        'x-cache'           => $cache_hit_callback,

        // LiteSpeed.
        'x-litespeed-cache' => $cache_hit_callback,
    );

    return $cache_headers;
}

На первый взгляд, выглядит достоверно. Но только на первый. Вернемся к основному вопросу — об отличиях версий 6.9 и 7.0 и вспомним про декларируемую доступность фильтра с версии 5.6. Зайдем в релизы репозитория /wordpress/wordpress на Github и выберем сравнение двух веток: 6.9.7 и 7.0.4. Нас интересует коммит, затрагивающий метод get_page_cache_headers. Для наглядности приведем код метода целиком, включая аннотации:

/**
	 * Returns a list of headers and its verification callback to verify if page cache is enabled or not.
	 *
	 * Note: key is header name and value could be callable function to verify header value.
	 * Empty value mean existence of header detect page cache is enabled.
	 *
	 * @since 6.1.0
	 *
	 * @return array List of client caching headers and their (optional) verification callbacks.
	 */
	public function get_page_cache_headers() {

		$cache_hit_callback = static function ( $header_value ) {
			return str_contains( strtolower( $header_value ), 'hit' );
		};

		$cache_headers = array(
			'cache-control'          => static function ( $header_value ) {
				return (bool) preg_match( '/max-age=[1-9]/', $header_value );
			},
			'expires'                => static function ( $header_value ) {
				return strtotime( $header_value ) > time();
			},
			'age'                    => static function ( $header_value ) {
				return is_numeric( $header_value ) && $header_value > 0;
			},
			'last-modified'          => '',
			'etag'                   => '',
			'x-cache-enabled'        => static function ( $header_value ) {
				return 'true' === strtolower( $header_value );
			},
			'x-cache-disabled'       => static function ( $header_value ) {
				return ( 'on' !== strtolower( $header_value ) );
			},
			'x-srcache-store-status' => $cache_hit_callback,
			'x-srcache-fetch-status' => $cache_hit_callback,

			// Generic caching proxies (Nginx, Varnish, etc.)
			'x-cache'           => $cache_hit_callback,
			'x-cache-status'    => $cache_hit_callback,
			'x-litespeed-cache' => $cache_hit_callback,
			'x-proxy-cache'     => $cache_hit_callback,
			'via'               => '',

			// Cloudflare
			'cf-cache-status' => $cache_hit_callback,
		);

		/**
		 * Filters the list of cache headers supported by core.
		 *
		 * @since 6.1.0
		 *
		 * @param array $cache_headers Array of supported cache headers.
		 */
		return apply_filters( 'site_status_page_cache_supported_cache_headers', $cache_headers );
	}

Кое-что удивляет, не правда ли? @since в аннотациях указывают на доступность и фильтра, и функции с версии 6.1.0, а вовсе не 5.6. Также определение $cache_hit_callback выглядит намного проще показанного в Context7 и массив $cache_headers отличается как по группировке, так и по составу. Давайте-ка скачаем архив релиза 5.6.19!

Поиск по содержимому файлов релиза 5.6.19 показывает отсутствие и метода get_page_cache_headers, и фильтра site_status_page_cache_supported_cache_headers где бы то ни было в коде. Идем в репозиторий, находим файл wp-admin/includes/class-wp-health.php и смотрим его историю редактирования. Находим коммит, добавивший функцию get_page_cache_headers. Убеждаемся, что никакого preg_match( '/(^| |,)HIT(,| |$)/i', $header_value ) там нет.

Немного позже находим и коммит, где false !== strpos( ... ) заменяется на str_contains() и далее никаких изменений с этим блоком кода не происходит.

Проделав аналогичные манипуляции с кодом, можно также убедиться, что и написание массива заголовков в любой версии реального файла отличается от показанного в чате Context7. Более того, ИИ не знает о наличии в этом массиве таких заголовков как x-srcache-store-status, x-srcache-fetch-status и x-proxy-cache, а вместо заголовка x-cache-status предлагает использовать x-cache-enabled и x-cache-disabled.

Можно возвразить, что это очень узкоспециализированный вопрос, крайне редко используемые данные и так далее. Однако люди создают не только темы, но и плагины для экосистемы WordPress, в том числе расширяющие штатный функционал. И кэш-решения занимают отнюдь не последнее место по популярности.

Не оспариваю полезность Context7, для этого у меня слишком мало опыта работы с ИИ. Но, надеюсь, получилось подсветить в статье потенциальные проблемные места этого решения, как минимум для WordPress-разработчиков.

Context7: свежайшая документация оказалась… устаревшей?