order_ meta_value quebra arquivos de termos de taxonomia

Eu tenho um tipo de postagem de pessoas com uma taxonomia de tipo de pessoa (por exemplo, “Staff”). Nas páginas de Arquivo de termos de pessoas, eu quero ordenar por um campo personalizado “Nome de sorting”. Para fazer isso, estou usando uma chamada pre_get_posts :

 is_main_query() ) return; // order people by sortname if( is_post_type_archive( 'ciswa_people' ) || is_tax( 'ciswa_person_type' ) ) { $query->set( 'meta_key', 'cis_sort_name' ); $query->set( 'orderby', 'meta_value' ); $query->set( 'order', 'ASC' ); } } add_action( 'pre_get_posts', 'my_query_tweaks' ); 

No entanto, quando faço isso, as páginas de arquivo de termos não retornam resultados! Comentar a linha meta_key traz as mensagens corretas, mas, claro, não ordenadas.

Quando eu olho para a consulta que o WordPress está gerando, acho que o problema é que o WordPress está tentando também consultar postagens com base na meta_key, em vez de apenas fazer pedidos por ela. De $wp_query na página de arquivo de termos de taxonomia vazia relevante:

 ["tax_query"]=> object(WP_Tax_Query)#343 (2) { ["queries"]=> array(1) { [0]=> array(5) { ["taxonomy"]=> string(17) "ciswa_person_type" ["terms"]=> array(1) { [0]=> string(5) "staff" } ["include_children"]=> bool(true) ["field"]=> string(4) "slug" ["operator"]=> string(2) "IN" } } ["relation"]=> string(3) "AND" } ["meta_query"]=> object(WP_Meta_Query)#344 (2) { ["queries"]=> array(1) { [0]=> array(1) { ["key"]=> string(13) "cis_sort_name" } } ["relation"]=> string(3) "AND" } 

…e…

 ["request"]=> string(498) "SELECT SQL_CALC_FOUND_ROWS fi_posts.ID FROM fi_posts INNER JOIN fi_term_relationships ON (fi_posts.ID = fi_term_relationships.object_id) INNER JOIN fi_postmeta ON (fi_posts.ID = fi_postmeta.post_id) WHERE 1=1 AND ( fi_term_relationships.term_taxonomy_id IN (6,10) ) AND fi_posts.post_type = 'ciswa_people' AND (fi_posts.post_status = 'publish' OR fi_posts.post_status = 'private') AND (fi_postmeta.meta_key = 'cis_sort_name' ) GROUP BY fi_posts.ID ORDER BY fi_postmeta.meta_value ASC LIMIT 0, 10" 

Solutions Collecting From Web of "order_ meta_value quebra arquivos de termos de taxonomia"

'meta_key' => 'keyname' deve fazer parte da consulta para poder classificar por seu valor.
Infelizmente, isso resultará imediatamente na consulta sendo limitada a postagens onde a chave está definida (seu valor pode estar vazio, mas deve existir).

Portanto, considere o método s_ha_dum vinculado aos comentários da pergunta , ou escolha fazer a sorting após a consulta.

Permita-me oferecer uma abordagem para isso (não testado, apenas um conceito):

 function wpse105899_sort_posts_by_cis_sort_name( $a, $b ) { $a_cis_sort_name = get_post_meta( $a->ID, 'cis_sort_name', true ); $b_cis_sort_name = get_post_meta( $b->ID, 'cis_sort_name', true ); if ( $a_cis_sort_name === $b_cis_sort_name ) { return 0; } else if ( $a_cis_sort_name > $b_cis_sort_name ) { return 1; } else { return -1; } } usort( $query->posts, 'wpse105899_sort_posts_by_cis_sort_name' ); 

Nota: O formato acima do condicional no retorno de chamada usort serve o propósito da legibilidade. Na produção, pode ser um one-liner:

 function wpse105899_sort_posts_by_cis_sort_name( $a, $b ) { $a_cis_sort_name = get_post_meta( $a->ID, 'cis_sort_name', true ); $b_cis_sort_name = get_post_meta( $b->ID, 'cis_sort_name', true ); return $a_cis_sort_name === $b_cis_sort_name ? 0 : ( $a_cis_sort_name > $b_cis_sort_name ) ? 1 : -1; } 

Mesa principal

Eu tinha a meta_key errado. A resposta de @Johannes Pille foi a chave em que me apontou para o fato de que, se a chave estivesse lá, isso não deveria ser um problema. Estava lá, mas não estava usando.