---
title: "WordPress 7.0 vous laisse enfin créer un bloc sans écrire de JavaScript"
locale: "fr"
url: "https://irz.fr/fr/articles/wordpress-php-only-block-registration-fr"
markdown_url: "https://irz.fr/fr/articles/wordpress-php-only-block-registration-fr.md"
category: "tech"
tags: ["WordPress", "Gutenberg", "PHP", "JavaScript", "blocs", "WordPress 7.0"]
published_at: "2026-08-31T11:25:00.000Z"
author: "Camille Morel"
translation: "https://irz.fr/en/articles/wordpress-php-only-block-registration-en.md"
---

# WordPress 7.0 vous laisse enfin créer un bloc sans écrire de JavaScript

Avec autoRegister, WordPress 7.0 peut exposer automatiquement un bloc rendu en PHP dans l’éditeur. Le développeur supprime son enregistrement JavaScript, pas le JavaScript de Gutenberg.

Un bloc WordPress pouvait être minuscule côté produit et franchement disproportionné côté outillage.

Prenons trois lignes calculées en PHP. Le serveur sait déjà produire le HTML. Pourtant Gutenberg demandait encore une présence client : enregistrer le bloc dans le navigateur, charger `@wordpress/blocks`, fournir `edit`, puis souvent construire le JavaScript. Beaucoup de mécanique pour dire une seconde fois que le bloc existe.[2](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/)[6](https://css-tricks.com/getting-started-with-wordpress-block-development/)

Depuis WordPress 7.0, ce détour n’est plus obligatoire dans le cas le plus simple.

Déclarez `supports.autoRegister`, fournissez un `render_callback`, et le bloc rendu côté serveur **apparaît dans l’éditeur sans votre propre enregistrement JavaScript**.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)[2](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/)

La nouvelle option tient presque dans une ligne. Pour certains blocs, elle suffit à garder réellement la définition utile côté PHP.

```php
register_block_type(
    'irz/server-note',
    [
        'title' => 'Server note',
        'attributes' => [
            'text' => [
                'type'    => 'string',
                'default' => 'Hello',
            ],
        ],
        'render_callback' => function ( $attributes ) {
            return '<p>' . esc_html( $attributes['text'] ) . '</p>';
        },
        'supports' => [
            'autoRegister' => true,
        ],
    ]
);
```

Cette déclaration suffit pour le cas minimal documenté par WordPress.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)

Elle ne signifie pas que Gutenberg est devenu une application PHP.

## Ce qui disparaît vraiment

Avant WordPress 7.0, la documentation recommandait normalement d’enregistrer les blocs **sur le serveur et côté client**. L’enregistrement serveur donne accès au rendu dynamique, aux Block Supports, aux Block Hooks, aux variations de styles et à d’autres fonctions qui dépendent du registre PHP. L’enregistrement client, via `registerBlockType()`, donne au Block Editor sa définition du bloc et de son interface d’édition.[2](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/)

Un bloc dynamique finissait ainsi avec deux points d’entrée :

```php
register_block_type(
    'irz/server-note',
    [
        'render_callback' => 'irz_render_note',
    ]
);
```

puis, côté navigateur :

```js
import { registerBlockType } from '@wordpress/blocks';

registerBlockType('irz/server-note', {
    edit: Edit,
});
```

Autour de ces deux appels venaient souvent `block.json`, imports, `@wordpress/scripts`, dépendances et fichiers compilés. Le tutoriel CSS-Tricks de l’époque matérialise très bien le moment où un bloc banal entre soudain dans « React et JSX ».[6](https://css-tricks.com/getting-started-with-wordpress-block-development/)

Pour une vraie interface d’édition, rien de choquant. Pour une valeur calculée côté serveur et deux réglages dans l’Inspector, la plomberie devenait parfois plus grosse que le bloc.

> **WordPress 7.0 retire un doublon, pas Gutenberg**
> Comparaison entre ancien bloc dynamique avec enregistrement PHP et JavaScript, et nouveau bloc PHP auto-enregistré
> - AVANT : DEUX ENREGISTREMENTS · WP 7.0 : UNE SOURCE SERVEUR
> - AVANT
> - PHP : register_block_type
+
JS : registerBlockType
> - WORDPRESS 7.0
> - PHP : register_block_type
+ autoRegister
+ render_callback
> - Le navigateur existe toujours. Ce qui disparaît, c’est votre code d’enregistrement client pour ce cas simple.
> autoRegister supprime le second point d’enregistrement pour les blocs simples rendus côté serveur. Il ne réécrit pas Gutenberg en PHP.

## PHP-only veut dire « votre PHP »

La nuance la plus importante tient dans le nom de la fonction.

WordPress parle de **PHP-only block registration**, pas d’un éditeur sans JavaScript.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)

Quand `autoRegister` vaut `true`, Core transmet la définition du bloc au côté client. Le Field Guide de WordPress 7.0 précise que ces blocs sont exposés au navigateur via une variable JavaScript globale.[4](https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/) La documentation des Block Supports indique de son côté que l’éditeur les enregistre automatiquement et utilise `ServerSideRender` pour afficher leur rendu.[3](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/)

Concrètement, le développeur peut enlever plusieurs pièces :

- vous n’écrivez plus `registerBlockType()` ;
- vous n’avez pas besoin d’un fichier `edit.js` pour le cas minimal ;
- vous pouvez éviter une chaîne de build JavaScript si votre plugin n’en a pas d’autre besoin ;
- **WordPress, lui, continue évidemment d’exécuter du JavaScript pour faire fonctionner l’éditeur**.

Ce n’est donc pas un retour de WordPress au PHP pur. Core retire juste une synchronisation manuelle quand le serveur possède déjà assez d’informations.

## L’éditeur invente les contrôles qu’il peut

Un bloc qui apparaîtrait seulement comme un rectangle inerte ne ferait évidemment gagner grand-chose.

WordPress 7.0 essaie alors de fabriquer les contrôles de l’Inspector à partir des attributs enregistrés en PHP.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)[4](https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/)

L’exemple officiel déclare notamment des attributs `string`, `integer`, `boolean` et une chaîne avec `enum`. L’éditeur peut transformer ces métadonnées en champs lorsque leur type est pris en charge.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)

Le registre se comporte alors un peu comme un petit schéma de données.

```php
'attributes' => [
    'title' => [
        'label'   => 'Title',
        'type'    => 'string',
        'default' => 'Hello World',
    ],
    'count' => [
        'label'   => 'Count',
        'type'    => 'integer',
        'default' => 5,
    ],
],
```

Vous décrivez les valeurs. WordPress fournit l’interface standard quand il sait le faire.

Mais le « quand » est important. La dev note précise que les contrôles **ne sont pas générés pour les attributs au rôle `local` ni pour les types non pris en charge**.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)

Ce n’est donc pas un générateur universel d’interface.

> **autoRegister marche tant que le bloc reste descriptible**
> Schéma allant d’attributs PHP simples vers contrôles automatiques et rendu serveur, puis montrant qu’une interface personnalisée nécessite encore du code client
> - PLUS L’INTERFACE DEVIENT SPÉCIFIQUE, PLUS LE JAVASCRIPT REVIENT
> - ATTRIBUTS PHP
texte · nombre
booléen · enum
> - INSPECTOR
contrôles
générés
> - RENDU
PHP
serveur
> - Dès que l’édition exige une UI sur mesure, du RichText, des interactions complexes ou une logique client propre : le chemin JS redevient pertinent.
> Le gain maximal arrive quand métadonnées, contrôles standards et rendu serveur suffisent. autoRegister ne cherche pas à reproduire toutes les possibilités d’un bloc client.

## Le rendu reste dynamique

Un bloc auto-enregistré doit fournir un `render_callback`.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)[3](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/)

Cette obligation fixe immédiatement le terrain de jeu.

Le HTML final reste produit côté serveur à partir des attributs ; il n’est pas figé par une fonction JavaScript `save()`. On reste dans le modèle du **bloc dynamique**.

Ça suffit pour beaucoup de blocs plutôt ordinaires :

- une liste calculée depuis la base de données ;
- un encart dont le contenu dépend du site ;
- une donnée métier déjà disponible en PHP ;
- un bloc d’intégration avec une extension serveur ;
- un composant simple dans un thème classique qui commence à adopter Gutenberg.

La dev note cite justement les thèmes classiques et les workflows pilotés côté serveur comme bénéficiaires probables.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)

Pour ce genre de code, imposer React pour fournir une prévisualisation basique ressemblait souvent moins à une nécessité d’interface qu’à un ticket d’entrée dans l’écosystème des blocs.

`autoRegister` baisse ce ticket.

## Ce qu’il ne remplace pas

WordPress ne laisse guère de place au suspense : cette API **ne doit pas remplacer le paradigme client et n’a pas vocation à offrir autant de fonctions**.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)

C’est la limite à garder sous les yeux.

Si votre bloc a besoin :

- d’une édition directe sophistiquée dans le canvas ;
- d’interactions riches entre plusieurs éléments ;
- d’un composant React spécifique ;
- d’un comportement client qui ne se résume pas à quelques attributs ;
- d’un workflow d’édition entièrement personnalisé ;

alors un vrai `edit` côté client reste la bonne abstraction.

Pas de duel PHP contre React ici. **WordPress arrête simplement de forcer le cas simple à ressembler au cas complexe**.

Cette idée est plus importante que la quantité de fichiers économisés.

## Une surface de maintenance en moins

Sur un plugin qui contient dix petits blocs dynamiques, le gain devient vite moins théorique.

Avant, chaque bloc pouvait posséder une définition serveur et une définition client qu’il fallait garder alignées : nom, attributs, supports, parfois textes et comportement de prévisualisation. `block.json` a déjà réduit une partie de ces duplications en servant de métadonnée commune.[2](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/)

`autoRegister` va plus loin pour le sous-ensemble qui n’a pas besoin de code client propre.

La logique métier reste en PHP ; vous déclarez les attributs et le rendu, Core fabrique la présence minimale dans l’éditeur.

Le gain principal n’est même pas forcément le poids du JavaScript. Ce sont les **points de désynchronisation possibles** qui disparaissent.

Un registre au lieu de deux. Une chaîne d’outillage en moins quand elle n’apporte rien. Un seul environnement à déboguer pour le rendu métier.

Cela ne rend pas Gutenberg simple.

Cela permet enfin à un bloc simple de le rester.

## La bonne question n’est plus « dois-je apprendre React ? »

Gutenberg a longtemps transformé une petite question produit en choix de stack.

« Je veux ajouter un petit composant à l’éditeur » devenait vite « dois-je installer Node, comprendre JSX, apprendre les packages WordPress et construire un bundle ? »

Pour beaucoup de blocs, oui. Une extension riche de l’éditeur reste une extension cliente riche.

La nouveauté, c’est qu’il existe enfin une sortie avant d’arriver jusque-là.

Si votre besoin tient dans des attributs simples et un `render_callback`, vous pouvez rester en PHP.[1](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)[5](https://fr.wordpress.org/2026/05/15/guide-des-changements-techniques-de-wordpress-7-0/)

Si votre expérience d’édition devient plus ambitieuse, vous passez au client.

Ce n’est pas le retour du WordPress d’avant Gutenberg.

C’est Gutenberg qui apprend enfin qu’un composant trivial n’a pas besoin de faire semblant d’être une application.

## References

1. [Make WordPress Core — PHP-only block registration, 3 mars 2026](https://make.wordpress.org/core/2026/03/03/php-only-block-registration/)
2. [WordPress Developer Resources — Registration of a block](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/)
3. [WordPress Developer Resources — Block Supports / autoRegister](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/)
4. [WordPress 7.0 Field Guide — PHP Only Block Registration](https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/)
5. [WordPress.org Français — Guide des changements techniques de WordPress 7.0, 15 mai 2026](https://fr.wordpress.org/2026/05/15/guide-des-changements-techniques-de-wordpress-7-0/)
6. [CSS-Tricks — Getting Started With WordPress Block Development](https://css-tricks.com/getting-started-with-wordpress-block-development/)