# WordPress 6.8 pour les développeurs de blocs : les changements utiles

> Tour d'horizon des évolutions d'APIs d'éditeur et des déprécations à surveiller apportées par WordPress 6.8, côté développement de blocs uniquement.

- Auteur : Clément Hadrot
- Publié le : 2025-06-20
- Mis à jour le : 2025-06-20
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/wordpress-6-8-developpeurs-blocs-changements/

## L’essentiel

- Plusieurs composants @wordpress/components internes deviennent officiellement stables
- Des ajustements de comportement sur les blocs de grille et de groupe
- Une dépréciation à anticiper sur un ancien argument de rendu de bloc

WordPress 6.8 est sortie le 15 avril 2025. Contrairement aux annonces marketing centrées sur le Speculative Loading et le passage de bcrypt pour le hachage des mots de passe — deux sujets qui ne concernent pas directement l'écriture de blocs personnalisés — cette version apporte une série d'ajustements plus discrets côté APIs d'éditeur, qui méritent leur propre inventaire pour qui maintient des blocs en production.

Rien qui casse la compatibilité de façon brutale, mais plusieurs points à vérifier avant de considérer une extension de blocs comme testée sur cette version.

## Stabilisation de composants internes

Plusieurs composants de `@wordpress/components` auparavant marqués expérimentaux (préfixés `__experimental` dans leur export) passent à un statut stable dans cette version, ce qui change leur nom d'export officiel. Les blocs qui importaient ces composants sous leur ancien nom expérimental continuent généralement de fonctionner grâce à des alias de rétrocompatibilité, mais un avertissement de dépréciation apparaît désormais en console de développement.

```
// Ancien import, toujours fonctionnel mais déprécié
import { __experimentalToolsPanel as ToolsPanel } from '@wordpress/components';

// Import recommandé après stabilisation
import { ToolsPanel } from '@wordpress/components';
```

Sur nos projets, un simple passage en revue des imports préfixés `__experimental` dans le code des blocs personnalisés a suffi à nettoyer ces avertissements, sans changement de comportement visible pour l'utilisateur final.

## Ajustements sur les blocs de grille et de groupe

Le bloc Grille (`core/group` avec la variation de disposition grille) reçoit des ajustements sur la gestion des unités de dimensionnement de ses colonnes, avec une meilleure cohérence entre l'aperçu de l'éditeur et le rendu front pour les valeurs exprimées en unités relatives. Les blocs personnalisés qui héritent du support `layout` pour proposer leurs propres options de disposition doivent vérifier que leurs styles générés restent corrects avec ces ajustements, en particulier si le bloc surcharge manuellement le CSS de disposition plutôt que de s'appuyer entièrement sur le support natif.

> L'essentiel à retenir : Plusieurs composants @wordpress/components internes deviennent officiellement stables ; Des ajustements de comportement sur les blocs de grille et de groupe ; Une dépréciation à anticiper sur un ancien argument de rendu de bloc

## Une dépréciation à anticiper

La signature de certains filtres de rendu de bloc côté serveur poursuit sa clarification amorcée dans les versions précédentes, avec un avertissement de dépréciation renforcé sur l'usage direct de la variable superglobale `$block` non typée dans certains contextes de filtre historiques, au profit de l'objet `WP_Block` désormais systématiquement transmis. Les blocs qui manipulaient encore ces filtres à l'ancienne (hérités d'une syntaxe antérieure à l'introduction de `WP_Block`) affichent un avertissement PHP en mode débogage, sans casser le rendu pour l'instant.

```
// Ancienne pratique, dépréciée mais encore tolérée
add_filter( 'render_block', function ( $contenu, $bloc_array ) {
    return $contenu;
}, 10, 2 );

// Pratique recommandée, avec accès à l'instance WP_Block complète
add_filter( 'render_block', function ( $contenu, $bloc_array, $instance ) {
    // $instance est un objet WP_Block, avec accès à ->context, ->parsed_block, etc.
    return $contenu;
}, 10, 3 );
```

## Autres points relevés

- Amélioration de la gestion des raccourcis clavier dans l'éditeur, avec une meilleure cohérence entre les blocs natifs et les blocs personnalisés qui exposent leurs propres raccourcis via `useShortcut`.
- Ajustements mineurs de l'API de `ServerSideRender`, sans changement de signature, mais avec une meilleure gestion des erreurs réseau affichées dans l'éditeur en cas d'échec de la requête de prévisualisation.
- Corrections de bugs sur le comportement de `useEntityProp` pour certains champs de métadonnées personnalisées enregistrés avec `register_post_meta()` et un schéma de type `object`.

### Ce qui n'a pas bougé

Contrairement à d'autres versions majeures marquées par un changement structurel visible (le zoom out en 6.7, les script modules en 6.5), la 6.8 ne modifie aucune API fondamentale de déclaration ou d'enregistrement de bloc. `register_block_type()`, `block.json` et le cycle `edit()`/`save()` restent identiques dans leur usage courant.

> Sur ce projet de mise à jour, la seule action réellement nécessaire a été de traiter les avertissements de dépréciation des imports `__experimental` — une demi-journée de travail pour une dizaine de blocs personnalisés, sans aucun changement de comportement visible côté utilisateur.

## En résumé

WordPress 6.8 n'impose aucune migration urgente côté développement de blocs, mais mérite un passage en revue des imports de composants expérimentaux et des filtres de rendu à l'ancienne syntaxe, tous deux désormais signalés comme dépréciés en mode débogage. Une vérification rapide qui évite de futures mauvaises surprises quand ces alias de rétrocompatibilité finiront, un jour, par disparaître complètement.