Вопрос или проблема
При рефакторинге моей кодовой базы я заметил, что есть два хука, которые используются для изменения основного запроса.
parse_query
pre_get_posts
Согласно справочнику API плагинов, кажется, эти хуки выполняются один за другим и оба имеют доступ к основному объекту WP_Query. Мне нужно понять, чем они различаются, чтобы определить, какой из них подходит для моих нужд. Документация для разработчиков по parse_query и pre_get_posts не предоставляет достаточной информации, чтобы ответить на этот вопрос.
Код, использующий parse_query
, основан на статье о фильтрации админских списков на основе пользовательских полей.
Я внимательно изучаю код, вокруг обоих хуков, и они выполняются один за другим с одинаковыми аргументами, и я просто не вижу никакого существенного различия.
Теоретически, только parse_query
будет выполняться, а не pre_get_posts
, если WP_Query::parse_query()
будет выполняться напрямую отдельно, но сам WordPress этого никогда не делает. Может, некоторые плагины делают, но я не знаю, зачем бы им это делать. Насколько я могу судить, нет технической причины использовать какой-то один, но pre_get_posts
является более новым, более широко используемым и гораздо лучше документированным, как официально, так и третьими сторонами. Я предполагаю, что parse_query
является несколько устаревшим.
Я бы порекомендовал использовать pre_get_posts
. Любой код, который вы видите, использующий parse_query
, должен работать как есть с pre_get_posts
.
Ответ или решение
При выборе между хуками pre_get_posts
и parse_query
важно учитывать их предназначение, технические различия и контекст их использования. Каждая из этих структур имеет свои особенности, которые влияют на работу с главным объектом WP_Query
, что может оказаться ключевым фактором в зависимости от ваших конкретных нужд в проекте.
Теория
Начнем с того, как эти хуки используются в WordPress. Первый, parse_query
, срабатывает, когда объект WP_Query
завершает анализ массива запросов. Это происходит вскоре после того, как массив параметров был преобразован в объект и перед тем, как запрос был запущен. Данный хук дает возможность вмешаться и модифицировать запрос до его исполнения.
Второй, pre_get_posts
, активируется сразу после parse_query
, но до фактического запуска запроса и выборки данных из базы. Это делает его удобным для изменения запроса на более высоком уровне, а также добавляет возможность настройки параметров запроса, которые потенциально могут повлиять на выбранные записи.
Основное различие заключается в том, что pre_get_posts
предлагает более богатую функциональность и является более интуитивным для разработчиков, поскольку позволяет внести изменения в объект WP_Query
непосредственно перед его выполнением, что обеспечивает больший контроль над запросами WordPress.
Пример
Рассмотрим практический пример. У вас есть задача — модифицировать главный запрос, чтобы включить в вывод странички записи определенной категории. Теоретически, вы можете использовать для этого оба хука, но целесообразнее использовать pre_get_posts
, так как он лучше документирован и применим для решения задач в широком спектре контекстов.
function my_custom_query_modification($query) {
if ($query->is_main_query() && !is_admin()) {
$query->set('cat', '10'); // Устанавливаем ID категории
}
}
add_action('pre_get_posts', 'my_custom_query_modification');
Применение
В реальном применении то, какой хук выбрать, зависит от нескольких факторов:
-
Документация и поддержка: Как вы отметили,
pre_get_posts
намного лучше документирован и широко используется. Это означает, что проще будет найти примеры, руководства и сообщества, готовые помочь. -
Обратная совместимость и стабильность: Появившись позже и пройдя через больше обновлений,
pre_get_posts
более устоявшийся в экосистеме WordPress, что делает его более надежным выбором с точки зрения долгосрочной совместимости. -
Кодовая база и удобство использования: Если ваш проект разрабатывается с нуля или значительная его часть подлежит рефакторингу, использовать
pre_get_posts
будет более логично, так как он проще в использовании и предоставляет больше возможностей для изменения запроса.
Итак, учитывая вышеупомянутое, ваш выбор становится очевидным. Pre_get_posts
— более современный, интуитивно понятный и поддерживаемый вариант для модификации главного запроса в WordPress. С ним у вас будет больше гарантированной поддержки и ресурсов для решения возможных проблем, которые могут возникнуть в процессе разработки. Выдержав испытание временем, он доказал свою эффективность и надежность, и может быть рекомендован как предпочтительный вариант для большинства задач, связанных с изменением запросов в WordPress.