WordPress : un bloc sans React, en PHP seul

Ce qui se passe

Depuis l'arrivée de l'éditeur de blocs, en 2018, écrire un bloc personnalisé supposait deux enregistrements — un en PHP, un en JavaScript — et donc une chaîne de compilation, des paquets npm, et une connaissance minimale de React. Sept ans et demi plus tard, WordPress 7.0 accepte l'enregistrement d'un bloc en PHP seul. Fränk Klein en fait le tour sur CSS-Tricks, avantages et impasses comprises.

Tout tient dans un drapeau posé dans les supports :

PHP

register_block_type( 'mon-theme/encart', [
    'title'           => 'Encart',
    'render_callback' => function ( $attributes ) {
        return sprintf(
            '<div %s>%s</div>',
            get_block_wrapper_attributes(),
            esc_html( $attributes['message'] )
        );
    },
    'supports'   => [ 'autoRegister' => true ],
    'attributes' => [
        'message' => [ 'type' => 'string', 'default' => 'Bonjour' ],
    ],
] );

Avec autoRegister, WordPress fabrique lui-même le code client : enregistrement du bloc dans l'éditeur, aperçu, et contrôles générés dans la barre latérale à partir des attributs déclarés. Aucun fichier JavaScript à écrire, aucun node_modules à installer.

Pourquoi ça compte

Pour un développeur PHP qui livre des sites, la marche d'entrée disparaît. Un bloc devient un fichier dans un plugin, versionné avec le reste, sans étape de build à maintenir dans le temps — c'est souvent là que le coût réel se situe, des années après la livraison.

Les limites, et elles ne bougeront pas

C'est la partie que l'article a le mérite de détailler, en précisant qu'elles découlent de l'architecture retenue.

L'aperçu passe par l'API REST. Le bloc n'appartient donc pas à l'application JavaScript de l'éditeur. Conséquence : pas de contrôle dans l'aperçu lui-même, uniquement dans la barre latérale — et cette barre ne gère aujourd'hui ni envoi d'image ni texte multiligne.

Aucun JavaScript ne tient sur l'aperçu. Le balisage est récupéré de manière asynchrone et remplacé à chaque rendu : les écouteurs d'événements posés au premier chargement sautent dès le rendu suivant. Un carrousel qui fonctionne parfaitement sur le site public sera inutilisable côté rédaction.

Les données affichées sont celles de la base. L'éditeur travaille sur un magasin de données côté client, qui n'est écrit en base qu'à l'enregistrement. Un bloc PHP interroge la base directement, donc il affiche l'ancienne valeur. Changez le titre de l'article : le bloc continue d'afficher le précédent jusqu'au prochain enregistrement suivi d'un rechargement.

Comment choisir

Bloc PHP : contenu statique, données externes, rendu calculé côté serveur, encarts éditoriaux simples.
Bloc JavaScript : tout ce que l'utilisateur modifie dans l'éditeur — titre, contenu, extrait, image mise en avant, taxonomies — et toute édition en place.

À retenir

L'attente valait le coup pour une catégorie précise de blocs, pas pour toutes. La bonne question n'est plus « puis-je éviter React ? » mais « ce bloc affiche-t-il quelque chose que l'auteur modifie sous ses yeux ? ». Si oui, la version PHP mentira, et c'est irrattrapable.

Source : CSS-Tricks