CPT-архив 404ing при использовании пользовательского имени таксономии в качестве переменной

Итак, я использую специальный архив типа post и создаю интерфейс фильтрации на основе JavaScript для сортировки результатов.

Вот пример: http://www.inverity.org/sermons/

Теперь, что я хотел бы сделать, это передать переменные моему сценарию, чтобы разрешить фильтрацию на основе параметров URL.

Это работает: http://www.inverity.org/sermons/?presenters=4

Проблема в том, что это не так: http://www.inverity.org/sermons/?speakers=4

«Динамики» – это имя используемой таксономии, которую я использую, и значение, которое я хочу фильтровать.

Есть идеи, почему это происходит? Есть ли что-нибудь, что я могу сделать, чтобы обойти это и предотвратить 404-го?

Solutions Collecting From Web of "CPT-архив 404ing при использовании пользовательского имени таксономии в качестве переменной"

У меня была такая же проблема в моем большом проекте, над которым я сейчас работаю. Это случай, когда у вас есть столкновение между таксономией и пост-типами слизней. Проблема в том, что вы можете фильтровать по таксономии с добавлением ?taxonomy_name=term_slug а также вы можете увидеть пользовательский пост, добавив ?post_type=custom_post_slug . Итак, это тот же синтаксис, и WP не знает, хотите ли вы «term archive» или «single custom post».

Единственный и правильный способ (на мой взгляд) решить это – изменить либо таксономию-slug, либо post_type-slug (возможно, проще исправить и обработать побочные эффекты переименования таксономии, я думаю).

2-е решение

Кроме того, я нашел одно решение EXACT, здесь вы можете найти подробности. Другими словами, вы можете установить для своего аргумента register_taxonomy() $args['query_var'] = false с помощью которого вы отключите speakers параметров запроса, чтобы действовать в качестве таксономии. Поэтому, если вы хотите фильтровать по таксономическим терминам непосредственно в URL / $_GET var, вам нужно будет сделать еще одну магию. Но, по крайней мере, вы удалите столкновение между именами post_type и таксономии.

При желании вам придется flush_rewrite_rules после этого любым способом:

  1. Добавьте flush_rewrite_rules(); в functions.php , перейдите на сайт, обновите его несколько раз, удалите эту строку и снова сохраните functions.php .
  2. Перейдите в WordPress admin -> Options -> Permalink и нажмите «Сохранить».

Обычно я делаю это. На всякий случай.

3-е решение

Пользовательская функция Hook для pre_get_posts() . С помощью этого метода вы должны быть осторожны, и в этом случае вы отредактируете аргументы запроса. Поместите это в functions.php .

 function preQueryAction( $query ) { // classic approach to avoid messing queries in Admin and custom queries. if(is_admin() or !$query->is_main_query()) return; // selectively filter only if you are on CPT arhive if(is_post_type_archive()){ $query->set( 'speakers', false ); } return; } add_action( 'pre_get_posts', 'preQueryAction', 1 ); 

Здесь я делаю снимки в темноте.

Первое, что я хотел бы посмотреть, это ваш вызов register_taxonomy. Вы должны убедиться, что параметр query_var не установлен на false.

 register_taxonomy( 'speakers', array('post'), array( 'rewrite' => array( 'slug' => 'media-channel' ), 'public' => true, 'query_var' => 'speakers', ) ) 

При этом вы можете быть уверены, что можете проверить запрос, используя get_posts. Этот тест будет выглядеть так:

 $test_results = get_posts( array( 'post_type' => 'post', 'numberposts' => -1, 'speakers' => 4, ) ); 

Получили ли вы результаты? При взгляде на ваш пример у меня есть сильное подозрение, что ваша таксономия может быть связана с вложениями. Если это так, мне пришлось добавить «post_status» => «inherit».

 $test_results = get_posts( array( 'post_status' => 'inherit', 'post_type' => 'attachment', 'numberposts' => -1, 'speakers' => 4, ) ); 

Как это выглядит для вас? Если вы получаете результаты здесь, возможно, что-то происходит с параметрами запроса или переписывает правила.

Codex register_taxonomy ссылается на необходимость сбросить правила перезаписи, если вы используете параметр 'rewrite'.

  global $wp_rewrite; $wp_rewrite->flush_rules(); 

Теперь, когда вы уверены, что получаете результаты этого запроса, вы можете проверить запрос, который WordPress создает внутри. Это можно сделать с помощью превосходного подключаемого модуля «Debug This» или с помощью:

 global $wp_query; print_r($wp_query->query_vars); 

Это покажет запрос, который WordPress построил с помощью «? Speakers = 4».