Страница архивации для таксономии пользовательского типа сообщения

Я создаю шаблон для архивной страницы таксономии пользовательского типа сообщения.

В принципе, я должен показать в зависимости от месяца, как

August 2015 July 2015 

Чтобы отобразить выше, я использовал фильтр ниже:

 add_filter( 'getarchives_where','abc_where',10,2); add_filter('getarchives_join', 'custom_archives_join', 10, 2); function custom_archives_join($x, $r) { global $wpdb; $cat_ID = $r['cat']; if (isset($cat_ID)) { return $x . " INNER JOIN $wpdb->term_relationships ON ($wpdb->posts.ID = $wpdb->term_relationships.object_id) INNER JOIN $wpdb->term_taxonomy ON ($wpdb->term_relationships.term_taxonomy_id = $wpdb->term_taxonomy.term_taxonomy_id)"; } else { return $x; } } 

И при нажатии на август 2015 года он должен отображать все сообщения, в частности, таксономии CPT. Но в настоящее время я получаю все сообщения.

Может ли кто-нибудь предложить мне эту страницу архива для таксономии пользовательского типа сообщений?

Solutions Collecting From Web of "Страница архивации для таксономии пользовательского типа сообщения"

Прежде, чем я начну, у вас есть ошибка в коде, который вы должны были бы получить, если бы вы включили debug. Вы сначала назначаете переменную $r['cat'] перед проверкой, установлен ли $r['cat'] . Поскольку cat не является значением по умолчанию, он не может быть установлен, что вызовет ошибку PHP, если cat не установлен. Вы можете реорганизовать свой код на что-то вроде этого: ( Требуется PHP5.3 +. Я также предположил, что это сработало так, как предполагалось, поэтому я ничего не изменил )

 add_filter('getarchives_join', function ( $x, $r ) { global $wpdb; // Set $cat_ID to the value of $r['cat'] if it is set, otherwise set to false $cat_ID = isset( $r['cat'] ) ? $r['cat'] : false; // If $cat_ID is false, return $x as is if ( !$cat_ID ) return $x; // We have a value in $cat_ID, lets modify and return the required sql string return $x . " INNER JOIN $wpdb->term_relationships ON ($wpdb->posts.ID = $wpdb->term_relationships.object_id) INNER JOIN $wpdb->term_taxonomy ON ($wpdb->term_relationships.term_taxonomy_id = $wpdb->term_taxonomy.term_taxonomy_id)"; }, 10, 2 ); 

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

  • знать, откуда пришел запрос

  • отфильтруйте основной запрос в зависимости от того, откуда пришло сообщение, чтобы отобразить правильные сообщения.

Чтобы решить проблему с номером 1, нам нужен какой-то реферер, чтобы мы могли узнать, откуда пришел запрос на страницу архива. Этот referrer будет нашим ключом, который позволит нам отображать правильные сообщения в соответствии с термином.

HTTP-ссылки крайне ненадежны, так как существует множество факторов клиентской стороны, которые могут изменять или контролировать значение реферера. Следующий раздел – это раздел, который я взял из одного из моих предыдущих ответов в качестве дополнительной информации для рефереров, поэтому вы можете потратить свое время и прочитать следующее

Проблема с реферерами заключается в том, что они устанавливаются и контролируются пользовательской стороной. Источники могут быть отключены или заблокированы (например, пользователи получают доступ к сайту за прокси-сервером). Просто ради интереса, вот очень интересный ответ на вопрос. В каких случаях HTTP-реферер будет пустым, взятым из этого сообщения на SO

Он будет / может быть пустым, когда конечный пользователь

  • введите URL-адрес сайта в адресную строку браузера.
  • посетил сайт с помощью браузера.
  • посетил сайт как первую страницу в окне / вкладке.
  • переключается с URL-адреса https на URL-адрес http.
  • переключился с URL-адреса https на другой URL-адрес https.
  • установлено программное обеспечение безопасности (антивирус / брандмауэр / и т. д.), который удаляет реферер из всех запросов.
  • находится за прокси-сервером, который удаляет реферер из всех запросов.
  • посетил сайт программным способом (например, curl) без установки заголовка referrer (searchbots!).

Вы бы хотели прочитать другие ответы там, чтобы получить дополнительную информацию

Я сидел с подобной проблемой и искал более надежный способ установки и передачи рефереров, и это привело к [этому вопросу] ( Получить стандартную структуру permalink из симпатичных URL-адресов ) и замечательный ответ от @gmazzap

По мере того, как я намекал на комментарии, мы передадим значение в URL-адресе, который мы будем использовать в качестве реферера, чтобы показывать правильные сообщения в соответствии с термином на странице архива. Для этого нам нужно отфильтровать get_archives_link() чтобы добавить наш реферер в URL-адрес архива, а также добавить наш query_vars в список query_vars чтобы мы могли его читать и использовать.

Во-первых, добавьте query_vars , давайте вызовите его ref , что является short для referrer. ref будет содержать пользовательское значение, которое будет равнозначно термину ID

 add_filter( 'query_vars', function ( $vars ) { $vars[] = 'ref'; return $vars; }); 

Теперь ref читаем, добавим его в нашу ссылку на архив в функции get_archives_link() через фильтр get_archives_link : (для этого требуется PHP 5.4+ из-за синтаксиса короткого массива ( [] ) )

 add_filter( 'get_archives_link', function ( $link_html ) { if( is_tax() ) { // Adjust this to target specific taxonomies or taxonomy terms if needed preg_match ( "/href='(.+?)'/", $link_html, $url ); $old_url = $url[1]; $new_url = add_query_arg( ['ref' => get_queried_object_id()], $old_url ); $link_html = str_replace( $old_url, $new_url, $link_html ); } return $link_html; }); 

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

  ?ref=1 

где один является идентификатором нашего термина

Последняя часть (вторая маркерная точка) должна соответствующим образом отфильтровать наш запрос. Здесь нам нужно

  • проверьте, установлен ли ref

  • если ref установлен, получите его значение ( не забывайте санировать, чтобы избежать инжекции данных )

  • соответственно фильтровать основной запрос

Последняя часть кода выглядит следующим образом: ( Требуется хотя бы PHP 5.4+ из-за синтаксиса короткого массива )

 add_action( 'pre_get_posts', function ( $q ) { // VERY VERY IMPORTANT: Check if `ref` is set as $_GET variable, get the value and validate as an integer $referrer = filter_var( INPUT_GET, 'ref', FILTER_VALIDATE_INT ); if ( !is_admin() // Only target front end queries && $q->is_main_query() // Only target the main query && $q->is_date() // Only targets date archive pages, adjust as needed && $referrer // Only proceed if $referrer has a value ) { // To avoid bugs in a multi custom taxonomy install, check if the term is valid if ( term_exists( $referrer, 'CUSTOM_TAXONOMY_NAME' ) ) { // IMPORTANT: Use the correct taxonomy name here // Set our taxonomy term filter, again, set the correct taxonomy name $tax_query = [ [ 'taxonomy' => 'CUSTOM_TAXONOMY_NAME', 'terms' => $referrer, 'include_children' => false, ] ]; $q->set( 'tax_query', $tax_query ); $q->set( 'post_type', ['post', 'YOUR_CUSTOM_POST_TYPE'] ); // Adds custom post type to date archives } } }, PHP_MAX_INT ); 

ЗАМЕЧАНИЕ:

Большая часть приведенного выше кода не проверена, поэтому может быть ошибкой. Кроме того, для большей части кода требуется PHP5.4 +, это должна быть минимальная версия PHP, которую вы установили, поскольку все более старые версии были EOL'ed и поэтому больше не поддерживаются. Хотя они все еще работают, они не получают обновлений безопасности, и это может нанести серьезный ущерб общей безопасности вашего сайта