Вопрос или проблема
Я определил пользовательский тип записи. На экране списка в админке я фильтрую его на основе аргумента querystring. Поэтому, если мой querystring включает ‘filter=abc’, я показываю подмножество моих пользовательских записей, если в querystring не включен параметр фильтра, я показываю другое подмножество.
Кнопки навигации по страницам учитывают мой параметр querystring, поэтому, если я нахожусь на ‘filter=abc’ и перехожу на следующую страницу, мой аргумент querystring остается присутствующим.
Однако, если я использую поле поиска или напрямую перехожу на другой номер страницы, параметр теряется. Это, очевидно, потому что он отсутствует в форме с id ‘posts-filter’.
Я мог бы использовать манипуляции с DOM, чтобы добавить скрытое поле формы, но это кажется неуклюжим. Есть ли лучший способ заставить WordPress включить мой параметр querystring в форму?
Обратите внимание, что я не спрашиваю о pre_get_posts, я знаю, как добавить этот параметр к WP_Query, после того как он передан на страницу. Вопрос в том, как убедиться, что мой параметр передается при навигации по странице списка админки.
Спасибо
Форма поиска в списке пользовательских типов записей (в админке) использует $_GET, но также выполняет перенаправление.
Необходимо отметить, что происходит какая-то очистка $_GET до перенаправления. Я точно не знаю, где именно это происходит в ядре, но это происходит (потому что многие параметры удаляются, включая пользовательские).
К счастью для нас, параметр _wp_http_referer
содержит полный URL до очистки, так что мы можем использовать его, чтобы наши пользовательские параметры сохранялись.
Также к нашему счастью, $location
в wp_redirect можно фильтровать! Мы добавим наши отсутствующие параметры перед тем, как произойдет перенаправление. per: https://github.com/WordPress/WordPress/blob/5b8a20d13408a9cd540e63a7bfefd4a366ff2f11/wp-includes/pluggable.php#L1402
Вот наилучшее решение, которое я смог придумать…
//Сделать переменную URL сохраненной после wp_redirect в поиске пользовательского типа записи
//Разместите это в файле /functions.php вашей дочерней темы:
add_filter('wp_redirect', 'make_filter_var_persist_redirect', 10, 2);
function make_filter_var_persist_redirect($location, $status) {
if (is_admin() && $_GET['post_type'] == "your-post-type-here") {
parse_str($_GET['_wp_http_referer'], $referer_args);
//Массив аргументов, которые вы хотите сохранить (например: filter)
$keep_args = [
'filter',
//'all_posts',
];
foreach($referer_args as $key => $value) {
if (in_array($key, $keep_args)) {
$location = add_query_arg( $key, $value, $location );
}
}
}
return $location;
}
Ответ или решение
Для решения вашей задачи по добавлению дополнительного параметра к запросам на экране администрирования для вашего пользовательского типа записи в WordPress, необходимо глубже изучить взаимодействие между серверными запросами и интерфейсом администратора.
Теория
При работе с пользовательскими типами записей в WordPress добавление параметров запроса на экран администрирования может быть вызовом. Это связано с тем, что стандартное поведение WordPress при обработке URL-адресов и форм может не учитывать пользовательские пожелания, такие как сохранение параметров запроса. Это происходит из-за санитизации данных и редиректа, что приводит к потере таких параметров.
Как было замечено, форма поиска и другие навигационные элементы могут обрабатывать $_GET
параметры, но некоторые из них могут быть удалены во время промежуточного редиректа. Параметр _wp_http_referer
содержит полный URL-адрес до этой санитизации, что открывает возможность использовать его для сохранения необходимых параметров.
Пример
Для этого мы можем использовать фильтр wp_redirect
для модификации конечного URL-адреса после получения данных из _wp_http_referer
. Ниже приведен пример того, как это можно реализовать:
// Добиваемся сохранения параметра URL после выполнения wp_redirect на странице поиска пользовательского типа записи
// Разместите этот код в файле /functions.php вашей дочерней темы
add_filter('wp_redirect', 'make_filter_var_persist_redirect', 10, 2);
function make_filter_var_persist_redirect($location, $status) {
if (is_admin() && $_GET['post_type'] == "your-post-type-here") {
parse_str($_GET['_wp_http_referer'], $referer_args);
//Массив аргументов, которые вы хотите сохранить (например, filter)
$keep_args = [
'filter',
//'all_posts',
];
foreach($referer_args as $key => $value) {
if (in_array($key, $keep_args)) {
$location = add_query_arg($key, $value, $location);
}
}
}
return $location;
}
Применение
-
Использование фильтра: Здесь мы используем фильтр
wp_redirect
, чтобы перехватить URL-редирект, происходящий в админ-панели. Проверка наis_admin()
гарантирует, что модификация происходит только в контексте админки. -
Анализировать
_wp_http_referer
: Мы извлекаем параметры из_wp_http_referer
, которые были доступны до редиректа и санитизации. -
Определение параметров для сохранения: Массив
$keep_args
определяется для указания параметров, которые должны быть сохранены и добавлены обратно в URL. -
Возвращение модифицированного URL: Цикл проходит через параметры в
$referer_args
, и, если ключ встречается в$keep_args
, он добавляется кlocation
с помощьюadd_query_arg
.
Такой метод позволяет сохранять ваши специфические параметры через все редиректы и навигации по страницам в интерфейсе администратора WordPress без необходимости прибегать к манипуляциям на уровне DOM или JavaScript, что делает решение более устойчивым и интегрированным в экосистему WordPress.
Интеграция и тестирование
После добавления этого кода в functions.php
, важно проверить вашу систему на наличие ошибок и убедиться в корректной работе всех других функций админ-панели WordPress. Тестирование включает все возможные сценарии переходов, навигации пунктов поиска и фильтрации, чтобы гарантировать устойчивость решения.
Позаботьтесь, чтобы настройка правил перезаписи URL-адресов в вашей теме или плагинах не конфликтовала с добавленной логикой, и всегда делайте резервные копии перед внесением изменений в функционал сайта.
Следуя предложенным рекомендациям, вы сможете обеспечить сохранность дополнительных параметров запроса, что улучшит управление и гибкость взаимодействия с пользовательскими типами записей в админской части WordPress.