WP_Query en WordPress: qué es y cómo se usa (Parte 2)

En esta segunda parte de WP_Query en WordPress veremos algunos de los parámetros más utilizados para realizar consultas personalizadas, comenzando por los parámetros de búsqueda.

Gracias a este parámetro, combinado con otros que estudiaremos más adelante, podemos construir sistemas de búsqueda mucho más avanzados que el que WordPress ofrece por defecto. Esto nos permitirá, por ejemplo, excluir determinadas palabras o taxonomías, filtrar resultados por categorías, limitar búsquedas a ciertos tipos de contenido y aplicar múltiples condiciones personalizadas.

El parámetro encargado de realizar búsquedas es s.

Su funcionamiento es bastante sencillo: WordPress buscará el término indicado tanto en el título de las publicaciones como en su contenido. En este caso hablamos de entradas porque es el tipo de contenido que estamos utilizando durante el curso, pero si trabajáramos con otro post_type, la búsqueda se realizaría sobre ese nuevo tipo de contenido.

Para nuestras pruebas modificaremos la entrada Hola mundo. Eliminaremos la contraseña y añadiremos la palabra resuelto al título y la palabra misterio dentro del contenido para comprobar cómo actúa este parámetro en diferentes situaciones de búsqueda.


   $args = [
      'post_type' => 'post',
      'posts_per_page' => 5,
      'paged' => $paged,
      's' => 'resuelto',
   ];

Si hacemos:

‘s’ => ‘misterio’, → mismo resultado que con resuelto.

‘s’ => ‘misterio resuelto’, → mismo resultado que con resuelto.

‘s’ => ‘misterio -resuelto’, → que contengan misterio menos resuelto no aparece ninguna publicación.

Sobre el parámetro s se pueden comentar bastantes cosas interesantes e importantes:

  • No distingue entre mayúsculas y minúsculas.
  • WordPress divide automáticamente las búsquedas por palabras.

Podemos combinar s con otros parámetros de WP_Query para crear búsquedas mucho más precisas.

  • buscar solo en una categoría concreta
  • limitar resultados a un post_type
  • excluir entradas
  • mostrar únicamente publicaciones destacadas
  • combinar búsquedas con meta_query o tax_query.
  • y un largo excetera.

Puedes ampliar conocimientos visitando:

Parámetros de post y páginas

Hasta ahora hemos trabajado principalmente con parámetros relacionados con búsquedas, filtros y consultas generales. Sin embargo, WP_Quey también incorpora una serie de argumentos específicos para trabajar directamente con entradas y páginas concretas.

Gracias a estos parámetros podremos obtener publicaciones mediante su ID, slug o nombre, limitar consultas a determinadas páginas, excluir contenido específico o incluso recuperar varios elementos concretos en un orden determinado.

Aunque muchos de estos argumentos parecen simples a primera vista, conocerlos bien es fundamental para construir consultas más precisas, optimizar el rendimiento y tener un mayor control sobre la información que WordPress devuelve en cada petición.

El parámetro p se utiliza para obtener una única entrada mediante su ID, por lo que realmente no tiene sentido usarlo junto con paginación, ya que la consulta solo devolverá un resultado.


   $args = [
      'post_type' => 'post',
      'p' => 15,
   ];

La id 1787 corresponde a la entrada Block: Gallery, cuyo identificador podemos ver colocando el ratón encima de la entrada estando en el listado de entradas.

Si queremos ver el contenido de la entrada, bastará con añadir dentro del li una llamada a the_content().

Hemos mejorado el código incorporando las funciones esc_url() y esc_html() para hacerlo más seguro.

Este parámetro funciona exactamente igual si en lugar de utilizar post indicamos page dentro del array de argumentos.

Pongamos, por ejemplo, el identificador de la página donde visualizamos los resultados de nuestras consultas, es decir, la página Curso Wp Query, cuyo identificador es 1832.

Además, añádale cualquier imagen destacada para comprobar que la consulta funciona correctamente sobre páginas y no únicamente sobre entradas.


   $args = [
      'page_id' => 2,
   ];


   $args = [
      'name' => 'hola-mundo',
   ];


   $args = [
      'pagename' => 'level-1',
   ];


   $args = [
      'post__in' => [1, 150, 163],
   ];


   $args = [
      'paged' => $paged,
      'post__not_in' => [3, 7],
   ];


   $args = [
      'post_type'   => 'page',
      'paged' => $paged,
      'post_parent' => 12,
   ];

   $args = [
      'post_type'   => 'page',
      'paged' => $paged,
      'post_parent__in' => [1809, 1725, 174],
   ];


   $args = [
      'post_type'   => 'page',
      'paged' => $paged,
      'post_parent__not_in' => [174, 1809],
   ];

Puedes ampliar conocimientos visitando:

Parámetros de estado de un post

Gracias a estos parámetros podremos decidir si queremos obtener únicamente entradas publicadas, incluir borradores, mostrar contenido privado, recuperar elementos enviados a la papelera o incluso trabajar con publicaciones programadas.

El estado predeterminado de una publicación es publish, es decir, publicado. Este es el estado que WordPress aplica automáticamente cuando no indicamos ningún valor en el parámetro post_status.


   $args = [
      'post_type' => 'post',
      'paged' => $paged,
      'post_status' => 'publish'
   ];

Estos argumentos nos mostrarán una lista con todas las entradas publicadas. Recordad que el número de publicaciones que aparecen por página viene definido en los Ajustes del panel de administración de WordPress.

Añadamos este código después de comprobar que hay publicaciones:
Total de publicaciones: <?php echo $the_query->found_posts; ?>

Gracias a la propiedad found_posts podremos mostrar el número total de resultados obtenidos por nuestra consulta, independientemente de la paginación.


   $args = [
      'post_type' => 'post',
      'paged' => $paged,
      'post_status' => 'draft',
   ];


   $args = [
      'post_type' => 'post',
      'paged' => $paged,
      'post_status' => 'future',
   ];

Hagamos privada a la entrada Block category: Formatting


   $args = [
      'post_type' => 'post',
      'paged' => $paged,
      'post_status' => 'private',
   ];


   $args = [
      'post_type' => 'post',
      'paged' => $paged,
      'post_status' => 'trash',
   ];


   $args = [
      'post_type' => 'attachment',
      'paged' => $paged,
      'post_status' => 'inherit',
      'post_mime_type' => 'image',
   ];


   $args = [
      'post_type' => 'post',
      'paged' => $paged,
      'post_status'    => 'any',
   ];


  $args = [
     'post_type' => 'post',
     'paged' => $paged,
     'post_status' => ['trash', 'draft', 'private'],
  ];

Hay que tener en cuenta que post_parent solo obtiene imágenes subidas desde la propia entrada.

Podemos comprobar si las imágenes tienen padre:


   $args = [
      'post_type' => 'attachment',
      'post_status' => 'inherit',
      'paged' => $paged,
      'post_mime_type' => 'image',
      //'post_parent' => 1787,
   ];

Si ahora aparecen imágenes, el problema es de post_parent.

Podemos subir una imagen desde nuestro ordenador a la entrada con ID 703 para realizar la comprobación.

Una vez subida, la imagen aparecerá en el listado de resultados, aunque dicho listado contenga únicamente una sola imagen.

Puedes ampliar conocimientos visitando:

El estado inherit (heredado) es un estado especial que WordPress utiliza principalmente para los adjuntos (attachment), como imágenes, PDFs, vídeos o documentos subidos a la biblioteca multimedia.

Cuando un archivo se sube desde una entrada o página, WordPress crea internamente un post de tipo: attachment. Y normalmente le asigna de inherit.

Se llama heredado porque el adjunto hereda parte del comportamiento y visibilidad del contenido padre al que pertenece.

Ejemplo:

  • si la entrada padre es privada
  • el adjunto también puede comportarse como privado.
  • WordPress le asigna el post_parent de la entrada.

Puede ocurrir, como se ha visto anteriormente que el post_parent de una imagen sea 0, entonces el archivo existe en la biblioteca multimedia, pero no pertenece oficialmente a ninguna entrada.

Además podemos decir que los elementos inherit son dependientes de otros contenidos.

Importante:

Aunque veamos una imagen dentro de una entrada, eso NO significa necesariamente que:

  • tenga post_parent
  • o que esté realmente asociada a esa entrada.

Seguramente estaremos pensando que ya conocemos todo lo necesario sobre este parámetro, ya que lo hemos utilizado prácticamente desde el inicio del curso. Y en parte es cierto. Sin embargo, post_type es uno de los parámetros más importantes de WP_Query, porque modifica por completo el tipo de contenido que WordPress va a consultar.

Hasta ahora hemos trabajado principalmente con entradas, páginas y distintos estados de publicación. Pero WP_Query también nos permite decidir exactamente sobre qué tipo de contenido queremos realizar nuestras consultas.

Gracias a este parámetro podremos trabajar no solo con entradas y páginas, sino también con:

  • imágenes y adjuntos
  • revisiones
  • menús de navegación
  • productos de WooCommerce
  • portfolios
  • cursos
  • o cualquier Custom Post Type creado en WordPress.

Comprender correctamente cómo funciona post_type es fundamental, ya que gran parte de la potencia de WP_Query depende precisamente de nuestra capacidad para consultar distintos tipos de contenido.

Concretando podemos decir que WordPress maneja seis tipos de datos:

  • Entradas → post
    Páginas → page
    Adjuntos → attachment
    Revisiones → revisión
    Menús de navegación → nav_menu_item
    Bloques reutilizables → wp_block

Además de estos tipos nativos, WordPress permite crear tipos personalizados mediante: register_post_type().


   $args = [
      'post_type' => 'post',
      'posts_per_page' => 10,
      'paged' => $paged,
   ];


   $args = [
      'post_type' => 'page',
      'posts_per_page' => 10,
      'paged' => $paged,
   ];


   $args = [
      'post_type' => 'attachment',
      'post_status' => 'inherit',
      'paged' => $paged,
      'posts_per_page' => 10,
   ];


   $args = [
      'post_type' => 'revision',
      'post_status' => 'inherit',
      'posts_per_page' => 10,
      'paged' => $paged,
   ];

Es posible que una misma entrada aparezca repetida varias veces. Esto ocurre porque WordPress mostrará una entrada por cada revisión que tenga almacenada, normalmente ordenadas por fecha, desde las más recientes hasta las más antiguas.


   $args = [
      'post_type' => 'nav_menu_item',
      'posts_per_page' => 5,
      'paged' => $paged,
   ];

Para ver algo parecido a la imagen debemos de colocar dentro del loop:


   <?php
   echo 'ID item menú: ' . get_the_ID();
   $object_id = get_post_meta(   get_the_ID(), '_menu_item_object_id', true );
   echo 'Texto menú: ' . get_the_title( $object_id );
   ?>

Probablemente nunca utilicemos este tipo de consultas en proyectos reales, ya que WordPress gestiona los menús mediante funciones específicas como wp_nav_menu(). Sin embargo, este ejemplo resulta muy interesante para comprender cómo WordPress almacena internamente los elementos de navegación dentro de la tabla wp_posts.

Con la llegada de Gutenberg y la edición completa del sitio (Full Site Editing), WordPress comenzó a incorporar nuevos tipos de contenido internos. Uno de los más importantes es wp_block.

Este tipo de dato se utiliza principalmente para almacenar bloques reutilizables creados desde el editor de bloques. Gracias a ello, WordPress puede guardar, reutilizar y gestionar bloques completos como si fueran publicaciones independientes dentro de la base de datos.

Aunque normalmente no trabajaremos directamente con este tipo de consultas en proyectos habituales, resulta muy interesante explorarlo para comprender mejor cómo Gutenberg organiza internamente gran parte de su contenido.

Es decir, WordPress guarda ciertos bloques como contenido independiente dentro de la base de datos y luego puede reutilizarlos en distintas entradas, páginas o plantillas.

Evidentemente en el fichero .xml que importamos al principio no existe ningún bloque reutilizable, así que tendremos que crear uno manualmente para poder realizar las pruebas.

En la entrada a Blog page vamos a construir un bloque reutilizable:

  • insertamos un bloque de columas
  • elegimos una estructura de tres columnas iguales
  • primera columna incluimos un bloque de imagen
  • segunda columna incluimos un bloque de párrafo
  • tercera columna incluimos un bloque de encabezado

Dentro del bloque de Columnas padre seleccionamos la opción Crear patrón y le asignamos el nombre de Bloque tres columnas asignándole la categoría de Columnas.


   $args = [
      'post_type' => 'wp_block',
      'post_status' => 'publish',
      'posts_per_page' => 5,
      'paged' => $paged,
   ];

Si queremos visualizar el contenido del bloque exactamente igual que aparecería en el navegador, podemos incluir dentro del <li> del loop el siguiente código:

<?php echo apply_filters( ‘the_content’, get_the_content() ); ?>

Gracias a apply_fliters( ‘the_content’ ), WordPress procesará correctamente los bloques de Gutenberg, renderizando imágenes, columnas, audios, calendarios y cualquier otro bloque tal y como se mostraría en el frontend del sitio.

Puedes ampliar conocimientos visitando:

Salir del blog