Créer un bloc Gutenberg en PHP pur avec autoRegister (WordPress 7.0)

Pourquoi les devs PHP étaient exclus de Gutenberg ?

Gutenberg est arrivé fin 2018 avec une promesse magnifique : un éditeur moderne, extensible, basé sur des blocs. Le problème ? Pour créer un bloc custom, il fallait maîtriser React, JSX, Node.js, npm, webpack… et parfois Babel en bonus. Pour un développeur PHP qui écrit des plugins WordPress depuis des années, ça ressemblait plus à un mur qu’à une porte ouverte.

Après plus de 15 ans à développer des plugins WordPress en PHP, j’ai vu des dizaines de développeurs en formation décrocher au moment du npm install. Pas parce qu’ils manquaient de compétences, mais parce que l’écosystème JavaScript leur était étranger. Ils savaient écrire un plugin en 20 minutes… mais créer un bloc, c’était une autre planète.

Des solutions de contournement existaient. ACF Blocks, Carbon Fields, ou encore les blocs dynamiques avec register_block_type_from_metadata() qui nécessitaient quand même un block.json et souvent un fichier JS minimal. Aucune de ces approches n’était du "PHP pur" au sens strict. Et toutes dépendaient d’un plugin tiers ou d’une chaîne de build. Si vous avez galéré avec ça, le guide complet Gutenberg donne le contexte historique.

La communauté le demandait depuis longtemps. L’issue #71792 sur GitHub cristallisait cette frustration : pouvoir enregistrer un bloc uniquement en PHP, comme on enregistre un shortcode ou un widget. Bref. Il a fallu attendre 2026 pour que ça arrive.

Qu’est-ce que le flag autoRegister ?

Le flag autoRegister est une nouvelle option du tableau supports de la fonction register_block_type(). Quand vous l’activez, WordPress prend en charge toute la partie JavaScript à votre place : inscription du bloc dans l’éditeur, génération des contrôles dans la sidebar, prévisualisation via le rendu serveur. Vous n’écrivez que du PHP.

Concrètement, une seule ligne change tout :

'supports' => array(
    'autoRegister' => true,
),

Pas de block.json. Pas de fichier edit.js. Pas de npm run build. Le PHP devient la "source of truth" pour les métadonnées du bloc (titre, catégorie, attributs, icône, mots-clés). Et WordPress s’occupe du reste.

Qui est derrière cette feature ? Le développeur @priethor a créé l’implémentation initiale, @wildworks l’a reviewée, et @t-hamano l’a stabilisée dans la PR #75543, mergée le 17 février 2026. La dev note officielle a été publiée le 3 mars 2026 par Miguel Fonseca.

Quid de la disponibilité ? Le feature est accessible depuis le plugin Gutenberg version 21.8, stabilisé en version 21.9. Il sera intégré nativement à WordPress 7.0, dont la sortie est fixée au 20 mai 2026 (initialement prévue le 9 avril 2026, le calendrier a été étendu en cours de cycle). Le décalage ne concerne pas autoRegister, qui est prêt.

Créer un bloc d’alerte en PHP pur, pas à pas

Passons à la pratique. On va créer un bloc d’alerte configurable (info, attention, danger) en PHP pur, sans toucher à JavaScript. Si vous savez écrire un plugin WordPress classique… vous savez déjà faire ça.

Prérequis : WordPress 6.9+ avec le plugin Gutenberg 21.8+ installé, ou WordPress 7.0 quand il sera disponible.

Créez un fichier wpf-alert-block.php dans wp-content/plugins/. Si vous n’êtes pas à l’aise avec la structure des fichiers WordPress, relisez d’abord le guide wp-config.php et functions.php :

<?php
/**
 * Plugin Name: WPF Alert Block
 * Description: Bloc d'alerte personnalisé, 100% PHP, zéro JavaScript.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 7.4
 * Author: Fabrice Ducarme
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'wpf_register_alert_block' );

function wpf_register_alert_block() {
    // Enregistrer le style du bloc
    wp_register_style(
        'wpf-alert-block-style',
        plugin_dir_url( __FILE__ ) . 'style.css',
        array(),
        '1.0.0'
    );

    register_block_type(
        'wpf/alert',
        array(
            'title'       => __( 'Alerte WPF', 'wpf-alert' ),
            'icon'        => 'warning',
            'category'    => 'widgets',
            'description' => __( 'Bloc d\'alerte configurable', 'wpf-alert' ),
            'keywords'    => array( 'alerte', 'notice', 'avertissement' ),
            'attributes'  => array(
                'message' => array(
                    'type'    => 'string',
                    'label'   => __( 'Message', 'wpf-alert' ),
                    'default' => 'Votre message ici',
                ),
                'level'   => array(
                    'type'    => 'string',
                    'label'   => __( 'Type d\'alerte', 'wpf-alert' ),
                    'enum'    => array( 'info', 'warning', 'danger' ),
                    'default' => 'info',
                ),
                'dismissible' => array(
                    'type'    => 'boolean',
                    'label'   => __( 'Masquable ?', 'wpf-alert' ),
                    'default' => false,
                ),
            ),
            'render_callback' => 'wpf_render_alert_block',
            'supports'    => array(
                'autoRegister' => true,
                'color'        => array(
                    'background' => true,
                    'text'       => true,
                ),
                'spacing'      => array(
                    'margin'  => true,
                    'padding' => true,
                ),
            ),
            'style_handles' => array( 'wpf-alert-block-style' ),
        )
    );
}

function wpf_render_alert_block( $attributes ) {
    $message     = esc_html( $attributes['message'] );
    $level       = $attributes['level'];
    $dismissible = $attributes['dismissible'];

    $wrapper = get_block_wrapper_attributes(
        array( 'class' => 'wpf-alert wpf-alert--' . $level )
    );

    $close_btn = $dismissible
        ? '<button class="wpf-alert__close" aria-label="Fermer">&times;</button>'
        : '';

    return sprintf(
        '<div %s>%s<p>%s</p>%s</div>',
        $wrapper,
        $close_btn,
        $message,
        $dismissible ? '<script>document.querySelector(".wpf-alert__close")?.addEventListener("click",e=>e.target.closest(".wpf-alert").remove())</script>' : ''
    );
}

50 lignes de PHP. Pas de npm install. Pas de webpack.config.js. Pas de package.json. Activez le plugin, et le bloc "Alerte WPF" apparaît dans l’inserter de l’éditeur. Vous configurez le message, le type d’alerte et l’option "masquable" directement dans la sidebar… Si vous cherchez d’autres exemples de code PHP pour WordPress, la collection de 100 snippets WordPress vous donnera des idées.

Quelques points à retenir sur ce code :

• get_block_wrapper_attributes() est obligatoire. C’est cette fonction qui applique les classes CSS et les styles inline générés par les supports (couleur, espacement). Sans elle, vos réglages de couleur et de marge ne s’affichent pas
• L’attribut level utilise enum : WordPress génère automatiquement un menu déroulant (SelectControl) avec les 3 options
• Le style est enregistré séparément via wp_register_style() et référencé dans style_handles. WordPress le charge automatiquement quand le bloc est utilisé

Et le CSS correspondant ? Un fichier style.css à côté du plugin :

.wpf-alert {
    padding: 1rem 1.5rem;
    border-left: 4px solid;
    border-radius: 4px;
    margin: 1.5rem 0;
    position: relative;
}
.wpf-alert--info    { border-color: #2196F3; background: #E3F2FD; }
.wpf-alert--warning { border-color: #FF9800; background: #FFF3E0; }
.wpf-alert--danger  { border-color: #F44336; background: #FFEBEE; }
.wpf-alert__close {
    position: absolute;
    top: 0.5rem;
    right: 0.75rem;
    background: none;
    border: none;
    font-size: 1.2rem;
    cursor: pointer;
}

Et concrètement, ça donne quoi ? J’ai installé ce plugin sur un WordPress 7.0 RC2 de test pour voir le résultat réel. Voici les trois variantes (info, warning, danger) rendues sur le front-end :

Le render_callback PHP produit un bandeau avec une bordure colorée à gauche, un fond teinté, et (si activé) un bouton de fermeture. C’est exactement ce que fait le CSS des 15 lignes du fichier style.css. Rien de magique, du HTML/CSS classique.

Avec 8 plugins publiés sur WordPress.org (dont OGEEAT récemment), je peux vous confirmer que cette approche couvre la majorité des besoins en blocs custom. Pour un bloc d’affichage, de listing ou de mise en forme, vous n’avez tout simplement plus besoin de JavaScript.

Comment le bloc s’affiche dans l’éditeur ?

Quand vous activez autoRegister, WordPress expose votre bloc à l’éditeur via les réglages de l’éditeur de blocs. L’éditeur Gutenberg lit cette liste au chargement, inscrit le bloc dans l’inserter, et utilise le composant ServerSideRender pour afficher la prévisualisation. Aucun fichier JavaScript de votre côté : tout est géré en interne.

Comment ça fonctionne concrètement quand vous modifiez un attribut ? Le cycle est simple : vous changez une valeur dans la sidebar (le message, le type d’alerte…), l’éditeur envoie une requête REST API au serveur, WordPress exécute votre render_callback PHP avec les nouveaux attributs, et le HTML résultant remplace la prévisualisation dans l’éditeur. C’est du rendu côté serveur, comme un shortcode visuel en temps réel.

Les contrôles dans l’Inspector (la sidebar droite) sont générés automatiquement selon le type de vos attributs. Pas besoin de coder des composants React :

• string génère un champ texte (TextControl)
• integer ou number génère un champ numérique (NumberControl)
• boolean génère un interrupteur on/off (ToggleControl)
• string + enum génère un menu déroulant (SelectControl)

Le bloc apparaît dans l’inserter exactement comme un bloc natif, avec son icône, sa catégorie et ses mots-clés. Vos utilisateurs ne verront aucune différence avec un bloc codé en React.

Quels attributs sont supportés par autoRegister ?

Pas de panique, la liste est courte et elle couvre les cas les plus courants. Voici ce que WordPress sait transformer en contrôle d’éditeur automatiquement :

Les 5 types supportés :

• string : champ texte libre. Pour un titre, un message, une URL
• integer : champ numérique (entier). Nombre d’éléments, colonnes
• number : champ numérique (décimal). Largeur, opacité
• boolean : interrupteur on/off. Activer/désactiver une option
• string + enum : menu déroulant. Taille, couleur, variante

Chaque attribut accepte une propriété label (texte affiché dans la sidebar, traduisible via __()) et une propriété default pour la valeur initiale. Les valeurs par défaut sont automatiquement fusionnées avec les attributs fournis, pas besoin de logique de fallback dans votre render_callback.

Et les types non supportés ? Les attributs de type object ou array ne génèrent pas de contrôle. Idem pour les champs textarea, les sélecteurs de média/image, les color pickers custom, les champs de lien, les date pickers et les éditeurs rich text. Si vous avez besoin de l’un de ces types… il faudra passer au JavaScript (on en parle plus bas).

Comment ajouter des styles et des supports natifs à votre bloc ?

Le système de supports de WordPress fonctionne intégralement avec les blocs PHP-only. Vous pouvez activer les contrôles de couleur, d’espacement, de typographie et de bordure, exactement comme pour un bloc React. La fonction get_block_wrapper_attributes() applique automatiquement les classes CSS et les styles inline correspondants.

Reprenons notre bloc d’alerte. On a déjà activé color.background, color.text et spacing.margin/padding. On peut aller plus loin :

'supports' => array(
    'autoRegister' => true,
    'color'        => array(
        'background' => true,
        'text'       => true,
        'gradient'   => true,
    ),
    'spacing'      => array(
        'margin'   => true,
        'padding'  => true,
    ),
    'typography'   => array(
        'fontSize'   => true,
        'lineHeight' => true,
    ),
    'border'       => array(
        'color'  => true,
        'radius' => true,
        'width'  => true,
    ),
),

Chaque option activée ajoute un panneau dans la sidebar de l’éditeur. L’utilisateur final peut personnaliser l’apparence du bloc sans toucher au CSS. Et tout ça, toujours sans écrire une seule ligne de JavaScript.

Quelles sont les limites concrètes des blocs PHP-only ?

Bon. Soyons honnêtes. autoRegister ne remplace pas tout, et il serait malhonnête de le présenter comme la solution universelle. Voici ce que vous ne pouvez PAS faire avec un bloc PHP-only :

• Pas de InnerBlocks : impossible d’imbriquer des blocs enfants dans votre bloc. Si vous avez besoin d’un conteneur avec des blocs à l’intérieur, il vous faut du JavaScript
• Pas d’upload média : aucun sélecteur d’image ou de fichier dans l’éditeur. Les attributs de type image/fichier ne sont pas supportés
• Pas de fonction save : le contenu n’est pas stocké en HTML dans post_content. Tout est dynamique, rendu à chaque affichage par votre callback PHP
• Pas d’interactivité côté client : onglets, carrousels, formulaires interactifs, live search… tout ce qui nécessite du JavaScript dans le navigateur reste hors de portée
• Pas de textarea dans l’Inspector Controls. Uniquement des champs texte simples (une ligne)
• Pas de Block Bindings : la prise en charge des Block Bindings avec les blocs PHP-only n’est pas encore disponible. Elle fait partie des évolutions envisagées pour une version ultérieure

Il y a aussi la question de la latence. Chaque modification d’attribut déclenche un appel REST API vers le serveur. Sur un hébergeur performant, c’est quasi-imperceptible. Sur un mutualisé chargé… ça peut se ressentir à chaque changement d’attribut. Pas dramatique pour de la configuration de bloc, mais c’est un aller-retour réseau là où un bloc React réagit instantanément côté client.

On l’oublie trop souvent, mais un bloc PHP-only ne stocke rien dans le HTML du post_content. Seuls les attributs sont enregistrés dans un commentaire Gutenberg. Le rendu est recalculé à chaque affichage (front et éditeur). C’est un avantage pour les contenus dynamiques (derniers articles, données BDD), mais ça signifie aussi que le bloc dépend du serveur pour fonctionner. Si votre plugin est désactivé, le bloc disparaît du front sans laisser de trace HTML.

Mon conseil : pour 80% des blocs custom que je vois en formation, autoRegister suffit largement. Ciprian Popescu (getbutterfly) a mis 4 blocs en production avec uniquement du PHP : Marquee, CTA, Author Box et Advanced Heading. Autant dire que si vos besoins sont un bloc d’affichage, un listing dynamique, une bio auteur, un bandeau CTA, un tableau de pricing, ou la migration d’un vieux shortcode… vous n’avez plus d’excuse pour ne pas créer de blocs.

Et pour les 20% restants ? C’est là que @wordpress/build entre en jeu…

@wordpress/build : quand faut-il passer au JavaScript ?

En avril 2026, le WordPress Developer Blog a annoncé @wordpress/build, un nouvel outil qui remplace webpack et Babel par esbuild, un bundler écrit en Go. L’outil est déjà utilisé en interne pour compiler les 100+ packages du projet Gutenberg, avec des temps de build passés de plusieurs minutes à quelques secondes.

Qu’est-ce que ça change pour vous ? Si vous avez besoin de JavaScript pour votre bloc (inner blocks, interactivité, uploads média), @wordpress/build simplifie considérablement le workflow. Plus de webpack.config.js de 50 lignes. Plus de configuration Babel. Le principe : des conventions plutôt que de la configuration.

L’installation tient en quelques commandes. Ajoutez wpScript: true dans votre package.json pour un bundle IIFE (le format classique WordPress), et @wordpress/build génère automatiquement les fichiers PHP d’enregistrement :

// Dans votre plugin principal, une seule ligne :
require_once plugin_dir_path( __FILE__ ) . 'build/build.php';

Ce fichier auto-généré hook dans wp_default_scripts et wp_default_styles pour enregistrer chaque script, module et style. Plus de wp_register_script() manuels avec des tableaux de dépendances à rallonge.

PHP pur ou build chain : comment choisir ?

Ça vous parle, cette hésitation ? "J’ai un bloc à créer, je fais comment ?" Voici un comparatif direct pour trancher :

Tableau comparatif PHP pur (autoRegister) vs @wordpress/build :

Critère	PHP pur (autoRegister)	@wordpress/build
Prérequis	PHP uniquement	Node.js + npm
Temps de setup	5 minutes	15-30 minutes
Fichiers nécessaires	1 fichier PHP (+CSS optionnel)	block.json + edit.js + PHP template
Rendu dans l’éditeur	ServerSideRender (appel REST)	React natif (instantané)
Inner blocks	Non	Oui
Interactivité client	Non	Oui
Upload média	Non	Oui
Save HTML dans post_content	Non (rendu dynamique)	Oui
Performance éditeur	Appel REST par attribut	Instantané
Cas d’usage idéal	Blocs d’affichage, widgets, shortcodes migrés	Blocs complexes, éditoriaux, interactifs

Le verdict est simple : commencez TOUJOURS par PHP pur. Si vous butez sur une limite (inner blocks, interactivité, uploads), passez à @wordpress/build. Pas avant. Autant éviter de sortir l’artillerie lourde quand un couteau suisse suffit. De facto, la majorité des blocs custom dans un projet WordPress standard (affichage d’une bio, bandeau promo, listing filtré, migration de shortcode) relèvent du cas PHP pur.

En tant que formateur WordPress certifié Qualiopi, je recommande systématiquement de démarrer par autoRegister à mes stagiaires développeurs PHP. La courbe d’apprentissage est quasi nulle pour quelqu’un qui connaît register_block_type(). Et si le besoin évolue vers plus de complexité, la migration vers un bloc JavaScript complet reste toujours possible.

ACF Blocks, Lazy Blocks : quelles alternatives à autoRegister ?

autoRegister n’est pas la seule voie pour créer des blocs en PHP. Avant son arrivée, plusieurs plugins comblaient déjà le vide. Faut-il les abandonner maintenant ? Pas forcément, ça dépend de votre contexte.

ACF Blocks (ACF PRO) reste la solution la plus répandue. Advanced Custom Fields compte plus de 2 millions d’installations actives sur WordPress.org (version gratuite). La version PRO ajoute ACF Blocks : vous définissez vos champs dans l’interface ACF, puis vous codez un template PHP pour le rendu. C’est plus visuel qu’autoRegister pour la configuration des champs, et ça gère les champs image, fichier, galerie, wysiwyg… tout ce qu’autoRegister ne supporte pas. Le compromis : c’est payant (49 $/an minimum) et ça crée une dépendance à un plugin tiers.

Lazy Blocks (gratuit, v4.3.0, testé jusqu’à WP 7.0) propose un constructeur visuel de blocs directement dans l’admin WordPress. Vous créez vos attributs par drag-and-drop, vous écrivez votre template en PHP ou en HTML, et le bloc apparaît dans l’éditeur. C’est la solution la plus accessible pour quelqu’un qui ne veut pas toucher au code PHP du tout. L’inconvénient : les performances sont moindres sur des sites avec beaucoup de blocs custom, et la maintenance du plugin reste entre les mains d’un développeur indépendant.

Genesis Custom Blocks (StudioPress / WP Engine, gratuit, v1.7.3, testé WP 7.0) suit une approche intermédiaire : vous créez les champs dans l’admin, puis vous codez un fichier PHP template dans votre thème. Propre, pas de dépendance payante, mais moins flexible qu’ACF Blocks sur les types de champs.

Alors, autoRegister ou plugin ? Voici comment je vois les choses :

• Vous êtes développeur PHP et vous voulez zéro dépendance ? autoRegister
• Vous avez besoin de champs image, fichier ou wysiwyg ? ACF Blocks (PRO)
• Vous ne codez pas du tout et vous voulez un constructeur visuel ? Lazy Blocks
• Vous voulez un entre-deux gratuit avec templates PHP ? Genesis Custom Blocks

L’avantage décisif d’autoRegister, c’est qu’il est natif. Pas de plugin à maintenir, pas de licence à renouveler, pas de risque d’abandon. Et si WordPress 7.1 ou 7.2 étend les types d’attributs supportés (textarea, image…), l’écart avec les plugins se réduira encore.

Questions fréquentes

Peut-on utiliser autoRegister dès maintenant sans WordPress 7.0 ?

Oui. Le flag autoRegister est disponible depuis le plugin Gutenberg version 21.8 (stabilisé en 21.9). Installez le plugin Gutenberg sur votre WordPress 6.9.x et vous pouvez commencer à créer des blocs PHP-only immédiatement. Quand WordPress 7.0 sortira, le feature sera intégré au core et vous pourrez désactiver le plugin Gutenberg.

autoRegister fonctionne-t-il avec les thèmes classiques ?

Oui, et c’est même l’un des cas d’usage ciblés. La dev note officielle mentionne explicitement les "classic themes or server-driven workflows". Si votre thème utilise encore les templates PHP traditionnels, autoRegister s’intègre naturellement.

Peut-on utiliser autoRegister dans un mu-plugin ?

Oui. Le hook init fonctionne identiquement dans un mu-plugin. C’est même une bonne pratique pour les blocs structurels (breadcrumbs, bio auteur) qui doivent être actifs en permanence, indépendamment du thème.

Les blocs PHP-only sont-ils compatibles avec le Full Site Editor ?

Oui. Les blocs enregistrés avec autoRegister apparaissent dans l’inserter du Full Site Editor (FSE) exactement comme n’importe quel bloc natif. Vous pouvez les utiliser dans vos templates, vos parts de template et vos patterns.

Sources et références

1. PHP-only block registration, Make WordPress Core, 3 mars 2026. Dev note officielle par Miguel Fonseca sur le flag autoRegister
2. PHP-only block registration in WordPress 7.0, Ryan Welcher, 4 mars 2026. Tutoriel détaillé avec code complet et bonnes pratiques
3. @wordpress/build, the next generation of WordPress plugin build tooling, WordPress Developer Blog, avril 2026. Présentation officielle du remplacement de webpack par esbuild
4. PHP-Only Block Registration: The Feature I’ve Been Waiting For, Ciprian Popescu (getbutterfly), 2026. Deep dive technique avec gotchas et 4 blocs en production
5. Stabilize PHP-Only Block Registration (PR #75543), @t-hamano, 17 février 2026. PR de stabilisation renommant les API expérimentales
6. Extending the 7.0 Cycle, Make WordPress Core, 31 mars 2026. Annonce du report de WordPress 7.0

L’écosystème des blocs s’ouvre enfin aux développeurs PHP

Huit ans après le lancement de Gutenberg, WordPress comble enfin le fossé entre les développeurs PHP et l’éditeur de blocs. Le flag autoRegister transforme register_block_type() en un outil complet de création de blocs, là où il fallait auparavant trois fichiers et une chaîne de build. Et c’est pas fini… @wordpress/build va encore simplifier le workflow JavaScript quand le besoin de complexité se fait sentir.

Pour aller plus loin dans le développement WordPress sans écrire de JavaScript, j’ai documenté comment créer un plugin WordPress complet avec l’IA. Et si vous voulez comprendre l’ensemble des changements de WordPress 7.0, l’article dédié couvre tout ce qui arrive.

Le prochain réflexe à avoir ? Prenez un vieux shortcode qui traîne dans votre functions.php, wrappez-le dans un register_block_type() avec autoRegister, et regardez-le apparaître dans l’éditeur. Ça prend 10 minutes… et ça change tout.

Article original sur WPFormation