Примените pre_get_posts к конкретному пользовательскому типу записи в админской зоне.

Содержание

Вопрос или проблема
Ответ или решение
Шаг 1: Определите текущий экран
Шаг 2: Модификация кода
Подробное объяснение кода:
Заключение

Вопрос или проблема

Я создал несколько типа записей (CPT) и хочу, чтобы один из пользовательских типов записей запрашивал данные из других типов записей.

Итак, что я сделал, так это использовал коды ниже, чтобы изменить запрос:

add_filter('pre_get_posts', 'code_to_alter_query', 10);

function code_to_alter_query($query) {
  // Если не в админке, выходим
  if( !is_admin() ) return $query;

  $cpts = array('custom_job', 'custom_us_job');
  $query->set( 'post_type', $cpts );

  return $query;
}

Теперь он будет показывать вакансии как из custom_job, так и из custom_us_job. Но это будет применяться ко всем CPT, а что если я хочу, чтобы только custom_job имел обе вакансии, а custom_us_job имел стандартный запрос?

Я попробовал использовать

global $pagenow;

Но это может получить только edit.php, который будет одинаковым для всех CPT. Как я могу определить, на какой (админ) странице я сейчас нахожусь?

Функция, которую вы ищете, это get_current_screen(). Чтобы проверить, находитесь ли вы на странице определенного пользовательского типа записи, сделайте следующее:

$screen = get_current_screen();
if ( $screen->post_type == 'custom_job' ) {
    // Мы на странице типа записи custom_job, можно продолжать
}

Теперь, если вы посетите edit.php?post_type=custom_job, это условие вернет true, в которое вы можете вставить свой запрос.

Существует также другой подход к этому. Используя is_post_type_archive('custom_job'), вы можете нацелиться на edit.php?post_type=custom_job. Убедитесь, что вы используете это в сочетании с is_admin(), чтобы не нацеливаться на фронтэнд.

Ответ или решение

Чтобы изменить запрос к конкретному типу записи (CPT) в административной панели WordPress, необходимо использовать хук pre_get_posts. Вы уже сделали первый шаг, добавив фильтр и установив массив типов записей. Однако, чтобы конкретный CPT, например custom_job, получал записи из обоих типов, в то время как custom_us_job продолжал показывать только свои записи, нужно сделать несколько доработок.

Шаг 1: Определите текущий экран

Первый момент, который нужно учитывать, это определение, на каком экране мы находимся в админке. Вы правильно указали на необходимость использования функции get_current_screen(). Это позволит вам выявить, какой именно CPT вы редактируете в данный момент.

Шаг 2: Модификация кода

Ниже приведён корректный пример кода, который осуществляет необходимую логику:

add_filter('pre_get_posts', 'code_to_alter_query');

function code_to_alter_query($query) {
    // Проверяем, находимся ли мы в админ панели и является ли запрос основным
    if (is_admin() && $query->is_main_query()) {
        // Получаем текущий экран
        $screen = get_current_screen();

        // Проверяем, что это именно тип записи 'custom_job'
        if ($screen->post_type == 'custom_job') {
            // Устанавливаем массив типов записей
            $cpts = array('custom_job', 'custom_us_job');
            $query->set('post_type', $cpts);
        }

        // Если это 'custom_us_job', просто оставляем стандартный запрос
    }

    return $query;
}

Подробное объяснение кода:

Функция is_admin(): Проверяет, находимся ли мы в административной панели WordPress.
$query->is_main_query(): Гарантирует, что мы изменяем только основной запрос на странице, а не дополнительные запросы, которые могут быть вызваны другими плагинами или функциями.
get_current_screen(): Получает информацию о текущем экране, что позволяет нам определить, какой тип записи редактируется.
Проверка на custom_job: Если мы находимся на странице редактирования custom_job, то меняем тип записей для выборки. В противном случае, для custom_us_job запрос останется стандартным.

Заключение

Эти изменения в коде позволят вам управлять выборкой записей на административной странице в зависимости от типа записи. Это оптимальное решение для вашей задачи, сохраняя при этом гибкость и производительность WordPress.

Настоятельно рекомендуем протестировать данный код на демо-сайте или в среде разработки перед применением на рабочем сайте, чтобы избежать возможных конфликтов и недочётов.