Créez des blocs personnalisés uniquement avec PHP. Adieu les shortcodes à l'ancienne 🥳
Créer des blocs Gutenberg a signifié React, Node.js et un pipeline de compilation depuis que WordPress 5.0 a introduit l'éditeur de blocs. Si vos compétences sont en PHP — comme les miennes et celles de la majorité des développeurs WordPress —, cette barrière vous a tenu à l'écart pendant près d'une décennie. WordPress 7.0 change la donne. Les blocs PHP uniquement vous permettent d'enregistrer un bloc Gutenberg entièrement fonctionnel avec un seul fichier PHP et le flag autoRegister.
Vous écrivez du PHP. Vous obtenez un bloc. Aucun outillage. Aucune compilation. 🥳 Dans cet article, vous verrez comment fonctionnent les blocs PHP uniquement, et vous parcourrez un exemple concret qui remplace un shortcode classique par son équivalent en bloc.
Que sont les blocs PHP uniquement ?
Jusqu'à présent, créer un bloc Gutenberg personnalisé impliquait de mettre en place une chaîne d'outils JavaScript : npm install, un fichier block.json, une étape de compilation avec webpack.config.js ou @wordpress/scripts, et un composant edit.js écrit en JSX. Chaque modification nécessitait une étape de compilation avant de pouvoir la voir dans l'éditeur. Pour un développeur PHP qui veut simplement enregistrer un bloc d'affichage simple, cette surcharge a toujours semblé disproportionnée par rapport à la tâche.
Les blocs PHP uniquement balaient tout cela. Désormais, dans register_block_type(), il vous suffit de passer 'autoRegister' => true, et WordPress gère automatiquement tout le côté JavaScript grâce à ServerSideRender. Le bloc apparaît dans l'inséreur, affiche un aperçu en direct sur le canevas et génère des contrôles d'Inspecteur dans la barre latérale, le tout sans une seule ligne de JavaScript de votre part.
Les contrôles sont générés automatiquement en fonction du type d'attribut :
| Type d'attribut | Contrôle d'Inspecteur généré |
|---|---|
string | Champ de texte |
integer / number | Champ numérique |
boolean | Interrupteur |
string + enum | Liste déroulante |
Les contrôles générés automatiquement ne couvrent pour l'instant que les quatre types ci-dessus. Tout ce qui est plus complexe, comme les sélecteurs d'images, les téléversements de médias ou les données imbriquées, n'est pas encore pris en charge et nécessiterait un bloc enregistré en JavaScript. Les développeurs peuvent également marquer des attributs individuels avec un rôle local pour les signaler comme un état interne ; WordPress les ignore lors de la construction des contrôles de la barre latérale.
Les blocs PHP uniquement sont disponibles dès aujourd'hui dans WordPress 7.0 sans aucune dépendance supplémentaire. Pour en savoir plus, lisez la note de développement officielle sur Make WordPress Core.
À qui cela s'adresse-t-il ?
Les petites agences et les freelances sans expertise approfondie en JavaScript peuvent désormais créer des solutions pour l'éditeur de blocs qui exploitent pleinement les fonctionnalités natives de WordPress sans toucher à un pipeline de compilation. Si vous souhaitez livrer des blocs Gutenberg personnalisés propres à un thème — comme des encarts d'auteur, des citations en exergue, des témoignages, des bannières CTA, des avis et des éléments similaires — plutôt que de vous rabattre sur les shortcodes, les blocs PHP uniquement contribuent à abaisser cette barrière de manière significative.
Ils ne remplacent pas les blocs enregistrés en JavaScript lorsque vous avez besoin d'une édition de texte enrichi en ligne, d'une interface réactive en temps réel ou de l'imbrication de blocs internes, mais pour une large catégorie de blocs d'affichage structurés, ils tombent à pic.
L'ancienne méthode : les shortcodes
Avant les blocs PHP uniquement, l'approche pratique pour un développeur PHP était un shortcode. Voici un simple shortcode de témoignage avec trois attributs : le nom de l'auteur, l'entreprise, une note en étoiles, plus le contenu interne pour le texte de l'avis :
function testimonial_shortcode( $atts, $content = '' ) {
$atts = shortcode_atts( [
'name' => '',
'company' => '',
'stars' => 5,
], $atts );
$stars_count = max( 1, min( 5, intval( $atts['stars'] ) ) );
$stars_html = str_repeat( '★', $stars_count )
. str_repeat( '☆', 5 - $stars_count );
return sprintf(
'<blockquote class="testimonial">
<p class="testimonial__stars">%s</p>
<p class="testimonial__body">%s</p>
<footer class="testimonial__attribution">
<strong>%s</strong>%s
</footer>
</blockquote>',
esc_html( $stars_html ),
wp_kses_post( $content ),
esc_html( $atts['name'] ),
$atts['company'] ? ', ' . esc_html( $atts['company'] ) : ''
);
}
add_shortcode( 'testimonial', 'testimonial_shortcode' );Utilisation :
[testimonial name="Sarah K." company="Acme Corp" stars="4"]
Saved us hours every week.
[/testimonial]
Ça fonctionne... mais ce n'est qu'un shortcode 🤷🏻♂️
Voici quelques-uns des problèmes posés par les shortcodes :
- Invisibles dans l'éditeur. L'auteur voit
[testimonial name="Sarah K." ...]dans l'éditeur, et non la carte rendue. Il n'y a aucun aperçu. - Non repérables. Vous devez savoir que le shortcode existe et vous souvenir du nom de ses paramètres. Rien ne le met en évidence dans l'interface.
- Aucun contrôle de style natif. Ajuster la couleur, l'espacement ou la typographie nécessite du CSS personnalisé ou des attributs supplémentaires câblés manuellement.
- Le contenu interne n'est pas du texte enrichi. Le corps de l'avis est transmis sous forme de simple chaîne dans
$content, et non comme une zone de texte enrichi modifiable.
Les shortcodes étaient le bon outil pour leur époque. L'éditeur de blocs propose quelque chose de mieux, mais il a été difficile d'en tirer parti. WordPress 7.0 offre un raccourci sous la forme des blocs PHP uniquement.
Soyons clairs : la bonne nouvelle méthode pour créer un bloc Gutenberg reste un bloc enregistré en JavaScript avec un composant edit complet. Les blocs PHP uniquement sont une voie simplifiée — délibérément limitée aux blocs rendus côté serveur qui n'ont pas besoin d'une édition enrichie sur le canevas. Ils ne remplacent pas les blocs JavaScript, mais constituent une nouvelle option pour les cas d'usage plus simples où la surcharge d'un pipeline de compilation et de composants React ne se justifie pas.
Une option plus simple : les blocs PHP uniquement
Construisons le même témoignage sous forme de bloc personnalisé WordPress uniquement avec PHP. La recette : register_block_type() avec 'autoRegister' => true dans supports, plus un render_callback.
Voici le code complet du bloc :
function my_plugin_register_testimonial_block() {
register_block_type(
'my-plugin/testimonial', // Block name: namespace/slug
array(
'title' => 'Testimonial', // Shown in the block inserter
'attributes' => array(
// string attributes generate a text input in the sidebar
'name' => array(
'type' => 'string',
'default' => '',
),
'company' => array(
'type' => 'string',
'default' => '',
),
// integer attributes generate a number input
'stars' => array(
'type' => 'integer',
'default' => 5,
),
'body' => array(
'type' => 'string',
'default' => '',
),
),
// render_callback is the PHP function that outputs the block's HTML
'render_callback' => function ( $attributes ) {
$stars_count = max( 1, min( 5, intval( $attributes['stars'] ) ) );
$stars_html = str_repeat( '★', $stars_count )
. str_repeat( '☆', 5 - $stars_count );
// Translatable string for screen readers — standard WordPress i18n, nothing extra needed
/* translators: %d: star rating out of 5 */
$stars_label = sprintf( __( '%d out of 5 stars', 'my-plugin' ), $stars_count );
return sprintf(
'<blockquote %s>
<p class="testimonial__stars" aria-label="%s">%s</p>
<p class="testimonial__body">%s</p>
<cite class="testimonial__attribution">
<strong>%s</strong>%s
</cite>
</blockquote>',
// Merges your class with editor-added colour, spacing, and typography styles
get_block_wrapper_attributes( array( 'class' => 'testimonial wp-block-quote' ) ),
esc_attr( $stars_label ),
esc_html( $stars_html ),
wp_kses_post( $attributes['body'] ),
esc_html( $attributes['name'] ),
$attributes['company'] ? ', ' . esc_html( $attributes['company'] ) : ''
);
},
'supports' => array(
// The key flag — tells WordPress to handle JS registration automatically
'autoRegister' => true,
// The rest unlock native colour, typography, and spacing panels in the sidebar
'color' => array(
'background' => true,
'text' => true,
),
'typography' => array(
'fontSize' => true,
),
'spacing' => array(
'padding' => true,
'margin' => true,
),
),
)
);
}
add_action( 'init', 'my_plugin_register_testimonial_block' );Le résultat :
Quelques points à noter ici. Premièrement, le contenu interne d'un shortcode n'a pas d'équivalent direct dans les blocs PHP uniquement. Le corps de l'avis devient un attribut string modifiable depuis les contrôles d'Inspecteur de la barre latérale — un champ de texte sur une seule ligne, et non une zone de texte enrichi sur le canevas. Pour une courte citation de témoignage, c'est suffisant. Pour des textes plus longs, vous voudriez un bloc enregistré en JavaScript avec un composant RichText.
Deuxièmement, get_block_wrapper_attributes() fusionne votre classe avec tout ce que l'éditeur ajoute pour la couleur, la typographie et l'espacement — de sorte que les panneaux de style natifs fonctionnent sans aucun câblage CSS supplémentaire. Le render_callback reçoit un tableau $attributes contenant uniquement les valeurs définies par l'utilisateur ; aucun paramètre $content, car le contenu interne n'est pas pris en charge.
Ce que vous gagnez par rapport à la version shortcode :
- Aperçu en direct sur le canevas de l'éditeur. Fini la syntaxe brute de shortcode — l'auteur voit la carte de témoignage rendue pendant qu'il édite.
- Contrôles générés automatiquement. Le nom, l'entreprise, le corps (champs de texte) et les étoiles (champ numérique) apparaissent automatiquement dans les contrôles d'Inspecteur de la barre latérale.
- Panneaux natifs de couleur, de police et d'espacement. Issus de
supports— aucun CSS personnalisé requis. - Repérable. Le bloc apparaît dans l'inséreur sous son nom, avec une icône.
Prêt pour la traduction dès le départ
Il y a deux préoccupations de traduction distinctes lorsqu'on travaille avec des blocs PHP uniquement, et il vaut la peine d'être clair sur ce qui relève de l'une et de l'autre.
La première concerne les chaînes statiques intégrées dans votre modèle PHP : libellés, textes de boutons, textes d'interface. Elles sont gérées par __() et _e(), comme dans n'importe quel fichier PHP de WordPress. Dans le bloc ci-dessus, le libellé des étoiles en est un exemple :
/* translators: %d: star rating out of 5 */
$stars_label = sprintf( __( '%d out of 5 stars', 'my-plugin' ), $stars_count );Les outils standard de WordPress les détectent automatiquement. Rien de plus n'est nécessaire.
La seconde préoccupation concerne le contenu saisi par l'utilisateur et stocké sous forme d'attributs de bloc : le corps du témoignage, le nom de l'évaluateur, l'entreprise. C'est le contenu que vos rédacteurs saisissent réellement dans le bloc, et __() n'y touche pas. Sur un site multilingue, ces valeurs d'attributs doivent être traduites séparément dans chaque langue, et ce n'est pas quelque chose que WordPress gère par lui-même.
Gato AI Translations for Polylang prend en charge les blocs PHP uniquement dès le départ, de la même manière qu'il prend en charge Gutenberg, Bricks, Elementor et d'autres constructeurs de pages. Aucune configuration supplémentaire n'est requise.
Tous les attributs de type string sont automatiquement enregistrés pour la traduction. Si un champ spécifique ne doit pas être traduit — une référence interne, une URL, un code numérique stocké sous forme de chaîne —, vous pouvez l'exclure à l'aide d'un filtre.
Pour le bloc de témoignage de cet article, le nom de l'évaluateur, l'entreprise et le texte du corps sont tous traduits automatiquement — sans aucune configuration au-delà de l'installation de l'extension.
Ce que les blocs PHP uniquement ne peuvent (pas encore) faire
Les limitations actuelles des blocs PHP uniquement :
- Pas de blocs internes ni d'imbrication. Vous ne pouvez pas déposer d'autres blocs à l'intérieur d'un bloc PHP uniquement.
- Pas d'édition de texte enrichi sur le canevas. Le composant
RichTextnécessite du JavaScript. Les contrôles de texte ne s'affichent que sous forme de champ de texte dans la barre latérale. - Les champs de chaîne de la barre latérale sont sur une seule ligne. Un attribut
stringdevient unTextControl, et non unTextareaControl— ce qui n'est pas idéal pour les textes plus longs. - Pas d'attributs de sélection d'images ou de médias. La prise en charge du téléversement d'images/fichiers est prévue pour une version ultérieure via la Block Fields API.
- L'aperçu de l'éditeur a un délai d'aller-retour. Les modifications d'attributs déclenchent une requête à la REST API pour un nouveau rendu côté serveur, de sorte que l'aperçu ne se met pas à jour instantanément.
Pour les blocs structurés simples — témoignages, CTA, avis, biographies d'auteur, fiches d'entreprise —, les blocs PHP uniquement tombent à pic. Pour tout ce qui nécessite une édition enrichie sur le canevas, l'enregistrement en JavaScript reste le bon outil.
Et la suite ?
Les blocs PHP uniquement de WordPress 7.0 mettent le développement de blocs à la portée de tout développeur PHP. Un fichier PHP, un appel à register_block_type(), et vous avez un bloc Gutenberg entièrement fonctionnel avec des contrôles dans la barre latérale, un aperçu en direct sur le canevas et la prise en charge des styles natifs. Vous écrivez du PHP. Vous obtenez un bloc. Aucun outillage. Aucune compilation. Aucun JavaScript.
Si vous créez des sites multilingues, Gato AI Translations fonctionne parfaitement avec les blocs PHP uniquement : votre contenu est traduisible dès le premier jour.
Prêt à aller plus loin ?
- Developing WordPress blocks without JSX or a build process — pour les développeurs qui veulent ajouter un minimum de JavaScript sans pipeline de compilation complet
- Beginner WordPress Developer course — une base complète pour le développement de blocs
