Depuis WordPress 5.5, l’éditeur de blocs propose un onglet Patterns dans l’inserter, à côté des blocs classiques et des blocs réutilisables. L’idée est simple mais puissante : au lieu d’assembler bloc par bloc une mise en page complexe, on insère une composition entière déjà prête, qu’on peut ensuite modifier librement.
Les patterns natifs fournis par WordPress (bannières, grilles de texte, appels à l’action) donnent un aperçu du potentiel, mais l’intérêt réel apparaît quand on enregistre les siens, adaptés à l’identité visuelle et aux besoins récurrents d’un projet. C’est ce qu’on va détailler ici, avec l’API PHP disponible aujourd’hui.
Pattern ou bloc réutilisable : bien choisir
Il existe deux mécanismes qui se ressemblent à l’usage mais fonctionnent très différemment. Les blocs réutilisables sont stockés en base de données sous forme de contenu partagé : modifier un bloc réutilisable le modifie partout où il est utilisé. Les patterns, eux, sont de simples modèles de départ : une fois insérés, ils deviennent des blocs classiques totalement indépendants, sans aucune synchronisation.
- Choisissez un bloc réutilisable pour un contenu qui doit rester identique partout (un bloc d’alerte, une signature) ;
- Choisissez un pattern pour une structure de départ que chaque page doit pouvoir personnaliser librement ensuite (une section « à propos », une grille de témoignages).
Cette distinction oriente directement le choix technique : un pattern s’enregistre en PHP, côté thème ou extension, alors qu’un bloc réutilisable se crée depuis l’interface et vit en base de données.
Enregistrer un pattern avec register_block_pattern
La fonction register_block_pattern() s’utilise dans le hook init, généralement depuis functions.php ou un fichier dédié inclus par le thème. Elle attend deux paramètres : un identifiant unique préfixé par le nom du thème ou de l’extension, et un tableau d’arguments décrivant le pattern.
function monthème_enregistrer_patterns() {
register_block_pattern(
'montheme/section-temoignage',
array(
'title' => __( 'Section témoignage', 'montheme' ),
'description' => _x(
'Une citation mise en avant avec le nom et la fonction de la personne.',
'Description du pattern témoignage',
'montheme'
),
'categories' => array( 'montheme-sections' ),
'keywords' => array( 'citation', 'avis', 'client' ),
'content' => '<!-- wp:group {"className":"temoignage-section"} -->
<div class="wp-block-group temoignage-section">
<!-- wp:quote -->
<blockquote class="wp-block-quote">
<p>Un accompagnement rapide et des explications toujours claires.</p>
</blockquote>
<!-- /wp:quote -->
<!-- wp:paragraph {"className":"temoignage-auteur"} -->
<p class="temoignage-auteur"><strong>Camille Dupont</strong>, cliente</p>
<!-- /wp:paragraph -->
</div>
<!-- /wp:group -->',
)
);
}
add_action( 'init', 'monthème_enregistrer_patterns' );
La clé content attend exactement la même syntaxe que celle générée par l’éditeur de blocs : des commentaires HTML délimitant chaque bloc. La méthode la plus fiable pour obtenir ce contenu reste de composer la mise en page directement dans l’éditeur, puis de copier le code via l’option Édition en code du menu des options, avant de le coller dans la chaîne PHP.
Créer ses propres catégories avec register_block_pattern_category
Par défaut, un pattern sans catégorie déclarée atterrit dans l’inserter sans regroupement clair. Pour offrir une expérience cohérente, il est recommandé de créer une catégorie dédiée avec register_block_pattern_category(), appelée elle aussi sur le hook init, avant l’enregistrement des patterns qui l’utilisent :
function montheme_enregistrer_categories_patterns() {
register_block_pattern_category(
'montheme-sections',
array( 'label' => __( 'Sections Mon Thème', 'montheme' ) )
);
}
add_action( 'init', 'montheme_enregistrer_categories_patterns', 9 );
Notez la priorité 9 passée à add_action() : il faut que la catégorie existe avant que les patterns qui la référencent soient enregistrés, sans quoi WordPress les classe silencieusement dans une catégorie par défaut.
Organiser une bibliothèque de patterns dans un thème
Sur un projet avec plusieurs dizaines de patterns, tout entasser dans functions.php devient vite illisible. Une organisation courante consiste à isoler chaque pattern dans son propre fichier, puis à les charger en boucle :
- Un dossier
inc/patterns/à la racine du thème ; - Un fichier PHP par pattern, retournant un tableau d’arguments ;
- Une fonction de chargement qui parcourt le dossier et appelle
register_block_pattern()pour chaque fichier trouvé.
Cette organisation manuelle préfigure d’ailleurs ce que WordPress proposera plus tard de façon native, mais pour l’instant aucune convention de dossier n’est reconnue automatiquement par le cœur : tout passe par du code explicite dans le thème.
Retirer les patterns natifs indésirables
Un thème avec une identité visuelle forte n’a pas toujours intérêt à conserver les patterns génériques fournis par WordPress ou par certaines extensions. La fonction unregister_block_pattern() permet de les retirer proprement :
function montheme_retirer_patterns_core() {
unregister_block_pattern( 'core/social-links-shared-background-color' );
}
add_action( 'init', 'montheme_retirer_patterns_core' );
Il est également possible de retirer une catégorie entière de patterns fournis par le cœur avec remove_theme_support( 'core-block-patterns' ), une option utile quand un thème préfère proposer exclusivement ses propres compositions plutôt que de mélanger les styles.
Testez toujours vos patterns avec un compte éditeur, pas seulement en administrateur : certains blocs insérés dans un pattern peuvent nécessiter des droits spécifiques (blocs HTML personnalisé, par exemple) qui bloquent silencieusement l’insertion pour un profil moins privilégié.
Pour aller plus loin
Les patterns de blocs sont aujourd’hui l’un des leviers les plus concrets pour accélérer la production de pages sans sacrifier la liberté de personnalisation propre à l’éditeur de blocs. Contrairement à un constructeur de pages tiers, tout reste dans l’écosystème natif de Gutenberg, sans dépendance externe ni format propriétaire.
À mesure que le Full Site Editing progresse dans le plugin Gutenberg, les patterns prennent une place de plus en plus centrale : ils deviennent le vocabulaire de base pour construire des templates entiers, pas seulement des sections de contenu. Investir du temps aujourd’hui dans une bibliothèque de patterns bien pensée, c’est préparer le terrain pour les évolutions à venir de l’édition de site.
