wp-query – Excluir o incluir identificadores de categoría en WP_Query

Pregunta:

Tengo una configuración de wordpress que tiene más de 300 categorías.

Ahora tengo el requisito de dar cierta flexibilidad para elegir las categorías. En ese caso, inicialmente marqué previamente todas las categorías, si alguien necesita excluir una categoría, puede deseleccionarla.

Ahora, el problema al que me enfrento es cómo dar resultados precisos de acuerdo con la selección de categoría.

Mi primer enfoque fue simplemente excluir todas las categorías de anulación de selección como se muestra a continuación,

por ejemplo: excluir categorías 10,11,12

$args = array(
    'category__not_in' => array('10','11','12')
);

Digamos que tengo una publicación que se marcó en la category 12 & 13 . Del código anterior, no obtendré esa publicación como resultado, ya que excluye publicaciones en la category 12 . Pero idealmente debería estar en los resultados, ya que la category 13 no fue deseleccionada.

Como solución, podría usar 'category__in' opción 'category__in' con todos los identificadores de categoría seleccionados. Pero mi preocupación es que la lista sería muy larga, aunque viene programáticamente, no estoy seguro de la sobrecarga de wp_query ya que tengo más de 300 categorías.

Cualquiera tiene una mejor idea de cómo resolver este problema.

Respuesta:

Como probablemente lo sepa, las categorías son taxonomías. Cuando use argumentos como category__in , agregará una consulta de impuestos a su WP_Query() . Entonces, su situación sería algo como esto:

$args = array(
    'post_type' => 'post',
    'tax_query' => array(
        'relation' => 'AND',
        array(
            'taxonomy' => 'category',
            'field'    => 'term_id',
            'terms'    => array( 12 ),
            'operator' => 'IN',
        ),
        array(
            'taxonomy' => 'category',
            'field'    => 'term_id',
            'terms'    => array( 11, 12, 13 ),
            'operator' => 'NOT IN',
        ),
    ),
);
$query = new WP_Query( $args );

No pensaría en problemas de rendimiento aquí. Es muy probable que esta sea su única solución, si no desea consultar directamente las publicaciones de la base de datos mediante una consulta SQL (esto podría mejorar un poco el rendimiento).

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım