vendredi 25 septembre 2026

À propos

Contact

FSE

Patterns synchronisés : le dossier /patterns et la fin des shortcodes maison

WordPress 6.0 formalise le dossier /patterns d'un thème de blocs. De quoi remplacer nombre de shortcodes personnalisés par des blocs éditables.

Par Clément Hadrot • 20 septembre 2022 • 5 min de lecture • Aucun commentaire
Patterns synchronisés : le dossier /patterns et la fin des shortcodes maison

Mai 2022 a marqué l’arrivée de WordPress 6.0, et avec elle une nouveauté que beaucoup d’agences attendaient sans le savoir : le dossier /patterns à la racine d’un thème de blocs. Jusque-là, enregistrer un pattern demandait un appel PHP à register_block_pattern() dans functions.php, avec un tableau d’arguments à maintenir à la main. Désormais, un simple fichier .php déposé dans /patterns suffit, avec ses métadonnées dans un en-tête de commentaire, sur le modèle des en-têtes de thème ou de plugin.

Ce changement, en apparence anecdotique, ouvre une piste concrète pour qui maintient des shortcodes personnalisés depuis des années : un encart d’appel à l’action, un bloc de témoignage stylé, une bannière promotionnelle. Ces éléments, jusqu’ici figés dans du PHP peu accessible aux rédacteurs, peuvent redevenir des blocs entièrement éditables dans l’interface, tout en restant définis proprement dans le code du thème.

L’en-tête PHP d’un pattern

Un fichier de pattern est un fichier .php classique, placé dans /patterns, dont le contenu HTML de blocs est précédé d’un en-tête de commentaire structuré :

<?php
/**
 * Title: Encart d'appel à l'action
 * Slug: mon-theme/cta-encart
 * Description: Bandeau coloré avec titre, texte court et bouton.
 * Categories: call-to-action
 * Block Types: core/group
 * Keywords: cta, bouton, promo
 * Viewport Width: 1200
 */
?>
<!-- wp:group {"backgroundColor":"contrast","layout":{"type":"constrained"}} -->
<div class="wp-block-group has-contrast-background-color has-background">
  <!-- wp:heading -->
  <h2 class="wp-block-heading">Prêt à démarrer ?</h2>
  <!-- /wp:heading -->

  <!-- wp:paragraph -->
  <p>Contactez-nous pour un audit gratuit de votre site.</p>
  <!-- /wp:paragraph -->

  <!-- wp:buttons -->
  <div class="wp-block-buttons">
    <!-- wp:button -->
    <div class="wp-block-button"><a class="wp-block-button__link">Demander un audit</a></div>
    <!-- /wp:button -->
  </div>
  <!-- /wp:buttons -->
</div>
<!-- /wp:group -->

Le champ Slug doit être préfixé par le nom du thème pour éviter les collisions avec d’autres extensions. Le champ Block Types est particulièrement utile : il permet de proposer ce pattern directement comme suggestion de remplacement au moment où l’utilisateur insère un bloc Groupe, sans avoir à fouiller dans la bibliothèque de patterns.

Patterns synchronisés ou non synchronisés

WordPress 6.0 introduit aussi une refonte de ce qu’on appelait auparavant les « blocs réutilisables » : ils deviennent des patterns synchronisés. La distinction avec un pattern classique (désormais dit « non synchronisé ») est essentielle et mérite d’être bien comprise avant de choisir l’un ou l’autre :

  • Pattern non synchronisé (celui du dossier /patterns, ou inséré depuis la bibliothèque) : sert de point de départ. Une fois inséré dans une page, il devient un groupe de blocs ordinaire, librement modifiable, sans lien avec l’original.
  • Pattern synchronisé : créé depuis l’éditeur via « Créer un motif », il reste lié à sa source. Modifier une instance modifie toutes les autres instances du même pattern sur le site, à la manière d’un ancien bloc réutilisable.
L'essentiel à retenir : Déclarer un pattern via un simple en-tête PHP dans /patterns ; Distinguer pattern synchronisé et pattern non synchronisé ; Remplacer un shortcode maison par un pattern éditable

Remplacer un shortcode maison par un pattern

Le cas d’usage le plus concret concerne les shortcodes développés au fil des années pour habiller un contenu récurrent : un shortcode [temoignage] avec des attributs pour le nom, la citation et la photo, par exemple. Ce type de shortcode a deux défauts en 2022 : il est invisible dans l’éditeur (l’utilisateur voit une balise texte, pas un aperçu), et chaque attribut modifié impose de connaître la syntaxe exacte du shortcode.

Un pattern de blocs résout les deux problèmes à la fois. Il s’affiche avec son rendu final dans l’éditeur, chaque champ (nom, citation, photo) devient un bloc modifiable directement au clic, sans syntaxe à retenir. La bascule se fait par étapes :

  1. Identifier la structure HTML actuellement générée par le shortcode PHP.
  2. La recréer dans l’éditeur avec les blocs natifs correspondants (Groupe, Image, Paragraphe, Citation).
  3. Copier le code source du bloc obtenu (via l’option « Copier » du menu du bloc) et le coller dans un nouveau fichier de /patterns, en ajoutant l’en-tête PHP.
  4. Conserver le shortcode existant en parallèle un temps, le temps de migrer le contenu déjà publié.

Où placer la logique encore dynamique

Un pattern reste un gabarit statique : il ne peut pas, par exemple, aller chercher une donnée en base au moment de l’affichage comme le ferait un shortcode avec du PHP dynamique. Pour ce type de besoin, un bloc dynamique personnalisé (avec une fonction render_callback) reste la bonne réponse. Le pattern couvre le cas très majoritaire : du contenu éditorial récurrent, saisi à la main par un rédacteur.

Avant de migrer un shortcode vers un pattern, vérifiez son usage réel dans la base avec une recherche sur wp_posts.post_content. Un shortcode oublié dans dix articles depuis 2018 ne mérite pas forcément la même énergie qu’un shortcode utilisé sur chaque page produit.

En résumé

Le dossier /patterns simplifie sérieusement la déclaration de patterns côté thème, avec un en-tête lisible et sans appel PHP à maintenir. Combiné aux patterns synchronisés, il donne une alternative crédible à des années de shortcodes maison, pour peu que le besoin reste éditorial et non strictement dynamique. La bascule ne se fait pas en un jour, mais chaque shortcode migré est un shortcode de moins à documenter pour la prochaine personne qui reprendra le thème.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi