WordPress 38 termes

Méthode de la classe $wpdb pour créer des requêtes SQL paramétrées dans WordPress. Équivalent des prepared statements PDO, adapte a l'écosystème WP.

Comme un coffre-fort avec une serrure a combinaison : les données ne peuvent pas s'échapper du cadre prévu.

global $wpdb;
$results = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM {$wpdb->posts}
     WHERE post_author = %d AND post_status = %s",
    $authorId, 'publish'
  )
);

Cas d'usage : Pour toute requête SQL directe dans WordPress qui inclut des variables.

Registre standardisé, introduit dans WordPress 6.9 « Gene » (2 décembre 2025), qui décrit des unités de fonctionnalité lisibles par machine : wp_register_ability() déclare label, description, input_schema, output_schema, exécuté_callback et permission_callback, sur le hook wp_abilities_api_init. Les abilities s'exposent en REST sous wp-abilities/v1. WordPress 7.0 ajoute un client côté navigateur et un client IA, 7.1 un cycle d'exécution filtrable.

La carte d'un restaurant lisible par un robot : chaque plat, ses ingrédients et qui a le droit de le commander.

add_action('wp_abilities_api_init', function () {
  wp_register_ability('my-plugin/get-post-count', [
    'label'       => __('Nombre d\'articles', 'my-plugin'),
    'description' => __('Retourne le total d\'articles publiés.'),
    'category'    => 'content-management',
    'execute_callback'    => fn() => wp_count_posts()->publish,
    'permission_callback' => fn() => current_user_can('read'),
    'meta' => ['show_in_rest' => true],
  ]);
});
// GET  /wp-json/wp-abilities/v1/abilities
// POST /wp-json/wp-abilities/v1/abilities/my-plugin/get-post-count/run

Cas d'usage : Exposer proprement les actions d'une extension aux agents IA, aux automatisations et aux autres extensions, avec schéma et permissions.

Hook qui permet d'exécuter du code a un moment précis du cycle WordPress (init, wp_head, save_post, etc.). Ne retourne pas de valeur.

Comme une alarme programmée : quand elle sonne, tu exécutés l'action prévue.

add_action('save_post', function(int $postId): void {
  if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return;
  update_post_meta($postId, '_custom_field', 'value');
}, 10, 1);

Cas d'usage : Pour exécuter du code en réaction a un evenement WordPress : création de post, login, activation de plugin.

Piège de performance ou trop d'options avec autoload=yes sont chargées en mémoire a chaque requête. Une table wp_options volumineuse ralentit tout le site.

Comme charger TOUS tes dossiers dans ton sac chaque matin au lieu de prendre seulement ceux du jour.

// Mauvais : autoload par defaut = yes
update_option('huge_data', $bigArray);

// Bon : desactiver autoload
update_option('huge_data', $bigArray, false);

// Audit
// SELECT SUM(LENGTH(option_value)) FROM wp_options
// WHERE autoload = 'yes';

Cas d'usage : Lors de l'audit de performance d'un site WordPress lent au premier chargement.

API disponible depuis WordPress 6.5 qui lie un attribut de bloc (contenu d'un paragraphe, url d'une image, texte d'un bouton…) à une source de données, sans bloc personnalisé. La source core/post-meta lit un champ enregistré avec show_in_rest ; register_block_bindings_source() crée ses propres sources.

Un champ de publipostage : le gabarit reste le même, la valeur vient de la fiche.

// PHP : exposer la méta
register_meta('post', 'prix', [
  'show_in_rest' => true, 'single' => true, 'type' => 'string',
]);

/* Markup du bloc :
<!-- wp:paragraph {"metadata":{"bindings":{
  "content":{"source":"core/post-meta","args":{"key":"prix"}}
}}} -->
<p>Valeur de repli</p>
<!-- /wp:paragraph -->
*/

Cas d'usage : Afficher des champs personnalisés (ACF, méta natives) dans des blocs standards, dans les gabarits de l'éditeur de site.

Système de permissions WordPress ou les roles (admin, editor, author) regroupent des capabilities (édit_posts, manage_options). Contrôle l'accès aux fonctionnalités.

Comme les badges d'accès dans une entreprise : le directeur ouvre toutes les portes, le stagiaire quelques-unes.

// Verifier une capability
if (!current_user_can('edit_posts')) {
  wp_die('Acces interdit');
}

// Ajouter un role custom
add_role('moderator', 'Moderateur', [
  'read' => true, 'edit_posts' => true,
]);

Cas d'usage : Pour contrôler finement qui peut faire quoi dans l'admin et via l'API REST.

Vérification systématique des permissions utilisateur avant toute action sensible via current_user_can(). Pilier de la sécurité WordPress.

Comme un vigile qui vérifie le badge avant de laisser entrer dans une zone restreinte.

add_action('wp_ajax_delete_item', function() {
  if (!current_user_can('delete_posts')) {
    wp_send_json_error('Non autorise', 403);
  }
  check_ajax_referer('delete_item_nonce');
  // Suppression securisee
});

Cas d'usage : Avant toute action admin : CRUD, changement de settings, accès aux données sensibles.

Theme qui hérite de toutes les fonctionnalités d'un theme parent et permet de le personnaliser sans modifier ses fichiers. Les mises a jour du parent sont préservées.

Comme customiser une voiture de série : on ajoute des options sans modifier la carrosserie d'origine.

/* style.css */
/*
 * Theme Name: Mon Theme Enfant
 * Template: theme-parent
 */

// functions.php
add_action('wp_enqueue_scripts', function() {
  wp_enqueue_style('parent', get_template_directory_uri() . '/style.css');
});

Cas d'usage : Pour personnaliser un theme tiers tout en conservant la possibilité de le mettre a jour.

Chaque version de WordPress publie sa grille de compatibilité PHP. Relevé le 27/09/2026 : WordPress 7.1 et 7.0 supportent PHP 7.4 à 8.5 (7.0 a abandonné PHP 7.2 et 7.3) ; 6.9 va de 7.3 à 8.5 (8.5 en bêta) ; 6.8 de 7.3 à 8.4. Côté PHP, seules les branches 8.4 et 8.5 sont en support actif, 8.2 et 8.3 ne reçoivent que des correctifs de sécurité.

La grille de compatibilité des pneus et des jantes : tout ne se monte pas sur tout.

# Version PHP servie par le site
wp eval 'echo PHP_VERSION;'
# Version WordPress
wp core version
# Repères (27/09/2026) :
# WP 7.1 / 7.0 : PHP 7.4 → 8.5
# WP 6.9       : PHP 7.3 → 8.5 (8.5 bêta)
# PHP support actif : 8.4 (jusqu'au 31/12/2026), 8.5 (31/12/2027)

Cas d'usage : Planifier une montée de version PHP sur un parc, ou répondre en entretien à « quelle version de PHP pour un WordPress à jour ? ».

Type de contenu personnalise au-delà des posts et pages natifs. Permet de modéliser des entités métier (produits, evenements, témoignages) avec leur propre interface admin.

Comme ajouter un nouveau type de classeur dans une armoire de bureau : factures, devis, contrats.

register_post_type('product', [
  'labels' => ['name' => 'Produits'],
  'public' => true,
  'has_archive' => true,
  'supports' => ['title', 'editor', 'thumbnail'],
  'show_in_rest' => true,
]);

Cas d'usage : Quand le contenu ne correspond pas aux posts/pages natifs : portfolio, evenements, FAQ, produits.

Système de classification personnalise pour organiser les contenus au-delà des catégories et tags natifs. Peut être hiérarchique ou plate.

Comme créer un nouveau système d'étiquettes dans une bibliothèque : par couleur, par taille, par theme.

register_taxonomy('brand', ['product'], [
  'labels' => ['name' => 'Marques'],
  'hierarchical' => false,
  'show_in_rest' => true,
  'rewrite' => ['slug' => 'marque'],
]);

Cas d'usage : Pour classifier les CPT : marques de produits, lieux d'evenements, niveaux de difficulté.

Fonctions d'échappement WordPress adaptées au contexte de sortie : esc_html pour le contenu, esc_attr pour les attributs HTML, esc_url pour les URLs.

Comme des combinaisons de protection différentes selon l'environnement : labo, chantier, ou cuisine.

<a href="<?php echo esc_url($link); ?>">
  <?php echo esc_html($title); ?>
</a>
<input value="<?php echo esc_attr($value); ?>">
<?php echo wp_kses_post($html_content); ?>

Cas d'usage : A chaque affichage de données dynamiques dans les templates WordPress, selon le contexte.

Hook qui permet de modifier une valeur avant qu'elle soit utilisée. Le callback reçoit la valeur, la transforme et la retourne modifiée.

Comme un filtre Instagram : la photo passe dedans et ressort transformée.

add_filter('the_content', function(string $content): string {
  if (is_single()) {
    $content .= '<div class="cta">Abonnez-vous!</div>';
  }
  return $content;
});

Cas d'usage : Pour modifier dynamiquement les titres, contenus, requêtes, URLs sans toucher aux templates.

Paradigme, apparu avec WordPress 5.9, où tout le site (en-tête, pied de page, gabarits) s'édite par blocs dans l'éditeur de site. WordPress 7.0 « Armstrong » (20 mai 2026) a rendu cet éditeur plus extensible (routage, validation des routes) et WordPress 7.1 « Mary Lou » (19 août 2026) y ajoute des contrôles de style responsives.

Comme passer d'un papier peint fixe a un mur de LEGO : chaque élément du site est deplacable et modifiable.

<!-- templates/single.html (thème bloc) -->
<!-- wp:template-part {"slug":"header"} /-->
<!-- wp:post-content /-->
<!-- wp:template-part {"slug":"footer"} /-->

Cas d'usage : Pour les thèmes blocs modernes où les utilisateurs personnalisent la mise en page sans code.

Unité de contenu de l'éditeur. Chaque bloc est décrit par un block.json : interface d'édition React et rendu (render.php côté serveur). Depuis WordPress 6.5, un bloc peut déclarer viewScriptModule et supports.interactivity pour utiliser l'Interactivity API, et lier ses attributs à des données via Block Bindings.

Comme des briques de construction modulaires : chacune a sa forme et sa fonction, on les assemble librement.

{
  "name": "myplugin/cta",
  "title": "Call to Action",
  "category": "design",
  "editorScript": "file:./index.js",
  "render": "file:./render.php",
  "viewScriptModule": "file:./view.js",
  "supports": { "interactivity": true }
}

Cas d'usage : Pour créer des composants de contenu réutilisables avec une expérience d'édition visuelle.

Système central de WordPress base sur le pattern Observer. Les hooks permettent aux plugins et themes de modifier le comportement sans toucher au core. Il en existe deux types : Actions et Filtres.

Comme des prises électriques dans une maison : tu branches ce que tu veux, ou tu veux, sans refaire l'installation.

// Action : executer du code a un moment
add_action('wp_footer', function() {
  echo '<script>console.log("loaded")</script>';
});
// Filtre : modifier une valeur
add_filter('the_title', 'strtoupper');

Cas d'usage : Mécanisme fondamental pour toute extension WordPress : plugins, themes, customisations.

API standard, intégrée au cœur depuis WordPress 6.5, pour rendre les blocs interactifs côté front avec des directives HTML (data-wp-interactive, data-wp-context, data-wp-bind, data-wp-on, data-wp-text, data-wp-each…) et un store JavaScript (state, actions, callbacks). Le script se charge en module ES via viewScriptModule dans block.json.

Des post-it sur le HTML qui disent au navigateur quoi faire au clic, sans réécrire la page en React.

<!-- render.php -->
<div data-wp-interactive="myPlugin"
     data-wp-context='{"isOpen": false}'>
  <button data-wp-on--click="actions.toggle">Afficher</button>
  <p data-wp-bind--hidden="!context.isOpen">Contenu caché</p>
</div>

<script type="module">
// view.js
import { store, getContext } from '@wordpress/interactivity';
store('myPlugin', {
  actions: { toggle() { const c = getContext(); c.isOpen = !c.isOpen; } },
});
</script>

Cas d'usage : Accordéons, filtres, paniers, navigation instantanée entre blocs qui partagent un état, sans jQuery ni framework tiers.

Mécanisme natif depuis WordPress 5.6 (novembre 2020) pour authentifier des clients externes sur l'API REST : un mot de passe dédié par application, révocable, utilisé en Basic Auth (RFC 7617) sur HTTPS uniquement. Un flux d'autorisation (/wp-admin/authorize-application.php) laisse l'utilisateur créer le jeton depuis l'application.

Une clé de valet : elle ouvre la voiture mais pas le coffre, et on la reprend quand on veut.

# Générer : Profil > Mots de passe d'application (HTTPS requis)
curl --user "USERNAME:xxxx xxxx xxxx xxxx xxxx xxxx" \
  "https://example.com/wp-json/wp/v2/users?context=edit"

# Vérifier que le site les accepte :
curl https://example.com/wp-json/ | jq .authentication

# Flux d'autorisation depuis une appli :
# /wp-admin/authorize-application.php?app_name=MonApp&success_url=…

Cas d'usage : Scripts de déploiement, intégrations SaaS, applications mobiles ou headless qui écrivent dans WordPress sans partager le mot de passe principal.

Plugin charge automatiquement avant tous les autres, sans possibilité de désactivation via l'admin. Place dans wp-content/mu-plugins/.

Comme un système de sécurité intégré dans les murs de la maison : on ne peut pas le débrancher.

// wp-content/mu-plugins/security.php
add_action('init', function() {
  // Forcer HTTPS
  if (!is_ssl()) {
    wp_redirect('https://' . $_SERVER['HTTP_HOST']
      . $_SERVER['REQUEST_URI'], 301);
    exit;
  }
});

Cas d'usage : Pour du code critique qui ne doit jamais être désactivé : sécurité, configuration, performance.

Token de sécurité WordPress (number used once) qui protège contre les CSRF et les accès non autorises. Valide 24h, lie a l'action et a l'utilisateur.

Comme un ticket d'entrée a usage unique qui prouve que c'est bien toi qui as demande l'accès.

// Generation
$nonce = wp_create_nonce('delete_post_42');

// Verification
if (!wp_verify_nonce($_POST['_nonce'], 'delete_post_42')) {
  wp_die('Securite : requete non autorisee');
}

Cas d'usage : Sur tout formulaire et lien d'action dans l'admin et le front-end WordPress.

Cache en mémoire persistant (Redis, Memcached) qui remplace le cache objet non-persistant par défaut. Accélère drastiquement les requêtes répétées.

Comme une mémoire vive ultra-rapide a cote d'un disque dur lent : les données fréquentes y sont stockées.

// wp-config.php
define('WP_REDIS_HOST', '127.0.0.1');

// Usage dans le code
wp_cache_set('user_42', $userData, 'users', 3600);
$cached = wp_cache_get('user_42', 'users');

Cas d'usage : Sur les sites a fort trafic pour réduire les requêtes base de données de 60-80%.

Système de stockage clé-valeur dans la table wp_options. Sert pour les réglages du site, des plugins et des themes. Les options autoload=yes sont chargées a chaque requête.

Comme un fichier de configuration central ou chaque plugin note ses préférences.

// Stocker
update_option('mon_plugin_api_key', $key);

// Recuperer
$key = get_option('mon_plugin_api_key', 'default');

// Supprimer
delete_option('mon_plugin_api_key');

Cas d'usage : Pour stocker les paramètrès de configuration du site, des plugins et des themes.

Ensemble de fonctions et conventions permettant de créer des extensions WordPress. Inclut l'activation, la désactivation, les hooks, les settings et les shortcodes.

Comme le kit de développement d'une console de jeux : il fournit les outils pour créer des jeux compatibles.

/*
 * Plugin Name: Mon Plugin
 * Version: 1.0
 */
register_activation_hook(__FILE__, function() {
  // Setup: tables, options, roles
});
add_action('init', 'mon_plugin_init');

Cas d'usage : Pour étendre WordPress avec des fonctionnalités personnalisées de façon maintenable et upgradable.

Hook filter qui permet de modifier la requête principale de WordPress AVANT son exécution. Le moyen le plus performant de personnaliser les listings.

Comme modifier la commande au restaurant avant qu'elle parte en cuisine, plutôt que de renvoyer le plat.

add_action('pre_get_posts', function(WP_Query $query) {
  if (!is_admin() && $query->is_main_query()) {
    if ($query->is_home()) {
      $query->set('posts_per_page', 6);
      $query->set('post_type', ['post', 'tutorial']);
    }
  }
});

Cas d'usage : Pour modifier le nombre de posts, le tri, les types affiches sur les pages d'archive et la home.

Plugin de debugging WordPress qui affiche les requêtes SQL, hooks, erreurs PHP, requêtes HTTP et temps d'exécution en temps réel dans une barre admin.

Comme un tableau de bord médical qui affiche tous les signes vitaux du site en temps réel.

// Pas de code : c'est un plugin a installer
// Affiche dans la barre admin :
// - Nombre et temps des requetes SQL
// - Hooks executes et leur temps
// - Erreurs PHP et notices
// - Scripts/styles charges

Cas d'usage : En développement pour identifier les requêtes lentes, les plugins gourmands et les hooks problématiques.

Famille de fonctions WordPress (sanitize_text_field, sanitize_émail, sanitize_url) qui nettoient les données entrantes en supprimant les caractères dangereux.

Comme un filtre a eau qui retire les impuretés avant de boire : on ne fait jamais confiance a l'eau brute.

$name = sanitize_text_field($_POST['name']);
$email = sanitize_email($_POST['email']);
$url = sanitize_url($_POST['website']);
$html = wp_kses_post($_POST['content']);

Cas d'usage : A chaque réception de données utilisateur dans WordPress : formulaires, AJAX, REST API.

Système de résolution de templates ou WordPress cherche le fichier le plus spécifique d'abord (single-product.php) puis remonte vers le plus générique (index.php).

Comme un GPS qui cherche la route la plus précise d'abord, puis une route plus générâle si la précise n'existe pas.

// Pour un post de type 'product' :
// 1. single-product.php
// 2. single.php
// 3. singular.php
// 4. index.php

Cas d'usage : Pour comprendre quel fichier template sera utilise et ou placer ses customisations.

Boucle principale de WordPress qui itere sur les posts de la requête courante. Utilise have_posts() et the_post() pour afficher le contenu.

Comme un présentoir de magazines : on les feuillette un par un dans l'ordre prévu.

<?php if (have_posts()) : ?>
  <?php while (have_posts()) : the_post(); ?>
    <h2><?php the_title(); ?></h2>
    <div><?php the_content(); ?></div>
  <?php endwhile; ?>
<?php endif; ?>

Cas d'usage : Dans tout template WordPress pour afficher les posts correspondant a la page courante.

Système de theming WordPress gérant template hierarchy, theme supports, customizer, menus, sidebars et widgets. Sépare la présentation de la logique.

Comme les habits d'une personne : ils changent l'apparence sans changer la personnalité.

// functions.php
add_action('after_setup_theme', function() {
  add_theme_support('post-thumbnails');
  add_theme_support('title-tag');
  register_nav_menus(['primary' => 'Menu Principal']);
});

Cas d'usage : Pour créer des themes WordPress qui respectent les standards et sont compatibles avec l'écosystème.

Fichier de configuration central des themes blocs WordPress (5.8+). Définit les couleurs, typographies, espacements et styles globaux en JSON.

Comme un guide de style visuel numérique : il définit les règles de design pour tout le site.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#0073aa" }
      ]
    },
    "typography": { "fluid": true }
  }
}

Cas d'usage : Pour tout theme bloc moderne : centralise la configuration visuelle et génère le CSS automatiquement.

Système de cache temporaire natif stockant des données avec expiration. Utilise la table options par défaut, ou un object cache externe si disponible.

Comme un post-it avec une date de péremption : l'info est disponible rapidement mais disparaît après un temps.

$data = get_transient('api_data');
if ($data === false) {
  $data = wp_remote_get('https://api.example.com/data');
  set_transient('api_data', $data, HOUR_IN_SECONDS);
}

Cas d'usage : Pour cacher les résultats d'appels API externes, de requêtes coûteuses ou de calculs lourds.

Trois majeures en neuf mois. 6.9 « Gene » (2 décembre 2025) : notes sur les blocs, palette de commandes partout, Abilities API. 7.0 « Armstrong » (20 mai 2026) : refonte de l'administration, client IA dans le cœur, blocs créés côté serveur en PHP. 7.1 « Mary Lou » (19 août 2026) : contrôles de style responsives, éditeur de médias, traitement d'images dans le navigateur (WebAssembly), AVIF/HEIC. Version de sécurité 7.1.2 le 22 septembre 2026.

Les millésimes d'un vin : savoir ce que chaque année a apporté.

# Sauvegarde puis mise à jour vers la dernière branche
wp db export avant-maj.sql
wp core check-update
wp core update && wp core update-db
wp plugin update --all
# Vérifier
wp core version   # attendu : 7.1.x (7.1.2 = sécurité du 22/09/2026)
wp plugin list --update=available

Cas d'usage : Situer un site client dans le cycle, justifier une mise à jour de sécurité, citer les nouveautés utiles en entretien.

WordPress complet exécuté dans le navigateur : PHP compilé en WebAssembly et SQLite à la place de MySQL, sans serveur ni compte. Un Blueprint (fichier JSON) décrit l'instance : versions de PHP et WordPress, extensions à installer, connexion, page d'arrivée. Instance publique : playground.wordpress.net.

Une maquette de cuisine dans un salon : on essaie tout, rien n'est branché chez soi.

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [
    { "step": "login", "username": "admin", "password": "password" }
  ]
}
// Chargement : playground.wordpress.net/#<json>
//           ou ?blueprint-url=https://…/blueprint.json

Cas d'usage : Démo d'extension reproductible, test d'une mise à jour sur plusieurs versions de PHP, formation, prototypage sans installation locale.

API REST native de WordPress exposant les contenus en JSON. Elle permet le headless, les SPA et les intégrations externes. Authentification : cookie + nonce (X-WP-Nonce) côté navigateur, mots de passe d'application (Basic Auth sur HTTPS, WordPress 5.6) pour les clients externes.

Comme un guichet de service qui fournit les informations dans un format standard que tout le monde peut lire.

register_rest_route('myplugin/v1', '/items', [
  'methods'  => 'GET',
  'callback' => fn(WP_REST_Request $req) =>
    new WP_REST_Response($data, 200),
  // public ? sinon : fn() => current_user_can('edit_posts')
  'permission_callback' => '__return_true',
]);

Cas d'usage : Pour les architectures headless, les apps mobiles ou les intégrations tierces avec WordPress.

Interface en ligne de commande officielle de WordPress. Elle permet de gérer extensions, thèmes, base de données, utilisateurs et plus sans navigateur. Chaque commande destructrice (search-replace) se teste d'abord avec --dry-run.

Comme un tableau de bord textuel pour piloter WordPress a la vitesse de la lumière.

# Mise à jour
wp core update && wp plugin update --all
# Rechercher/remplacer (dry-run d'abord)
wp search-replace 'http://old.com' 'https://new.com' --dry-run
wp search-replace 'http://old.com' 'https://new.com'
# Export base
wp db export backup.sql

Cas d'usage : Pour l'automatisation, les déploiements, la maintenance et les migrations WordPress.

Système de taches planifiées de WordPress, déclenché par les visites des utilisateurs (pseudo-cron). Peut être remplace par un vrai cron système pour plus de fiabilité.

Comme un réveil qui ne sonne que quand quelqu'un passe devant : il n'est pas fiable si personne ne vient.

// Planifier
if (!wp_next_scheduled('daily_cleanup')) {
  wp_schedule_event(time(), 'daily', 'daily_cleanup');
}
add_action('daily_cleanup', function() {
  // Nettoyage quotidien
});

Cas d'usage : Pour les taches récurrentes : nettoyage, envoi d'emails, synchronisation de données.

Méthode standard pour charger CSS et JS dans WordPress. Gère les dépendances, le versioning, le placement header/footer et évite les doublons.

Comme un chef d'orchestre qui décide quels musiciens jouent, dans quel ordre et a quel moment.

add_action('wp_enqueue_scripts', function() {
  wp_enqueue_style('main', get_stylesheet_uri(), [], '1.0');
  wp_enqueue_script(
    'app', get_theme_file_uri('js/app.js'),
    ['jquery'], '1.0', true
  );
});

Cas d'usage : Pour tout chargement de CSS/JS dans un theme ou plugin WordPress.

Classe PHP pour construire des requêtes de posts personnalisées. Permet de filtrer par type, taxonomie, meta, date, avec pagination et cache.

Comme un moteur de recherche interne ultra précis : tu définis tes critères, il trouve les contenus.

$query = new WP_Query([
  'post_type' => 'product',
  'posts_per_page' => 12,
  'tax_query' => [[
    'taxonomy' => 'category',
    'terms' => 'featured',
  ]],
]);
wp_reset_postdata();

Cas d'usage : Pour afficher des listes de contenus personnalisées (produits vedettes, articles récents d'une catégorie).