WordPress 6.9 : Analyse technique et Field Guide complet pour les développeurs

La sortie d'un "Field Guide" est toujours un moment charnière pour nous, développeurs d'extensions et de thèmes. C'est le signal que la phase de feature freeze est actée et qu'il est temps de tester nos environnements de staging.

WordPress 6.9, prévu pour début décembre, n'est pas une simple mise à jour de transition. C'est la culmination des efforts de l'année 2025 sur la modernisation du cœur. Si la version 6.8 avait posé les bases de la collaboration en temps réel, la 6.9 vient solidifier l'architecture technique, notamment avec l'introduction officielle de l'Abilities API et une refonte massive du moteur de rendu des blocs pour supporter les grilles natives.

J'ai passé le week-end à décortiquer le code source et les Dev Notes. Voici ce qui va casser (et améliorer) vos sites.

L'Abilities API : La fin du current_user_can

C'est probablement le changement le plus structurel de cette décennie pour le développement backend WordPress. J'en parlais récemment, mais le Field Guide confirme son intégration complète dans le Core.

L'ancienne méthode de vérification des droits, basée sur des chaînes de caractères et des rôles rigides, est désormais marquée comme "Legacy" (bien que non dépréciée hard pour l'instant).

Ce qui change concrètement

L'API introduit la notion de Policies. Au lieu de vérifier si un utilisateur a la capacité edit_post, vous vérifiez s'il a l'habilité de performer une action sur une ressource spécifique.

L'architecture repose sur trois composants :

1. L'Action : Ce que l'utilisateur veut faire (ex: update).

2. La Ressource : L'objet cible (ex: un WP_Post ou un objet métier custom).

3. Le Resolver : La logique qui détermine l'accès.

Implémentation technique

Dans votre functions.php ou votre plugin, la déclaration se fait via WP_Abilities::register.

use WordPress\Abilities\Access;
add_action( 'init', function() {
    // Définition d'une politique pour un CPT 'invoice'
    WP_Abilities::register( 'invoice', 'validate', function( $user, $invoice ) {
        // Règle 1 : Doit être comptable
        if ( ! in_array( 'accountant', $user->roles ) ) {
            return Access::deny( 'Rôle insuffisant.' );
        }
        // Règle 2 : La facture ne doit pas être déjà payée
        if ( $invoice->status === 'paid' ) {
            return Access::deny( 'Impossible de valider une facture payée.' );
        }
        return Access::allow();
    } );
} );

Pour appeler cette API dans vos templates ou contrôleurs REST :

// Beaucoup plus propre que les hooks map_meta_cap
if ( $user->can( 'validate', $invoice_object ) ) {
    // Afficher le bouton de validation
}

Impact pour les devs : Vous devez auditer vos plugins. Si vous utilisiez des map_meta_cap complexes pour gérer des droits fins, migrez vers l'Abilities API. C'est plus performant (cache intégré) et cela expose automatiquement vos règles à l'API REST pour vos interfaces React.

Grid Layout & Subgrid : Le moteur de mise en page passe la seconde

Côté frontend, WordPress 6.9 adopte enfin pleinement CSS Grid, et plus spécifiquement Subgrid. Le fichier theme.json gagne en complexité mais aussi en puissance.

Jusqu'à présent, le bloc "Groupe" permettait des mises en page Flexbox (row ou stack). La version 6.9 introduit le support natif du type grid avec une interface utilisateur dans l'éditeur qui génère du vrai CSS Grid, et non plus des div imbriquées inutiles.

Configuration dans theme.json

Les thèmes basés sur des blocs (Block Themes) peuvent désormais définir des presets de grille.

{
    "settings": {
        "layout": {
            "definitions": {
                "bento-grid": {
                    "type": "grid",
                    "columns": "repeat(auto-fit, minmax(min(100%, 300px), 1fr))",
                    "gap": "1.5rem"
                }
            }
        }
    }
}

L'arrivée de Subgrid

C'est le point technique le plus intéressant. Le Field Guide mentionne le support expérimental de subgrid pour les blocs imbriqués. Cela résout l'éternel problème d'alignement des cartes dans une grille.

Si vous avez une grille de 3 colonnes contenant des articles, vous pouvez désormais demander à ce que le titre, l'extrait et le pied de page de chaque article s'alignent sur les rangées de la grille parente, indépendamment de la hauteur du contenu.

Attention : Le CSS généré utilise des fallbacks pour les vieux navigateurs, mais attendez-vous à devoir nettoyer votre CSS personnalisé si vous aviez manuellement implémenté des grilles sur les blocs Groupes.

Data Views : L'admin se refait une beauté (React-based)

Le projet de refonte de l'admin (Phase 3) arrive à maturité. Les écrans classiques de liste (edit.php), comme la liste des Pages ou des Articles, peuvent désormais être remplacés par les Data Views.

C'est une interface 100% React, fluide, permettant le filtrage instantané, le tri, et l'édition rapide (Quick Edit) modernisée.

Pour nous développeurs, la question est : "Comment j'ajoute mes colonnes custom ?" La bonne nouvelle, c'est que l'API est beaucoup moins verbeuse que l'ancienne WP_List_Table.

L'enregistrement se fait via JavaScript (dans l'éditeur de site ou via un script chargé dans l'admin) :

import { registerDataViewField } from '@wordpress/dataviews';
registerDataViewField( 'post', {
    id: 'project_budget',
    label: 'Budget',
    getValue: ( item ) => item.meta._budget + ' €',
    render: ( { item } ) => {
        return <span className="badge-price">{ item.meta._budget } €</span>;
    },
    sortable: true,
} );

Il n'y a plus besoin de jongler entre manage_posts_columns et manage_posts_custom_column en PHP. Tout passe par l'API REST et le store de données côté client. Assurez-vous que vos champs meta sont bien exposés dans l'API REST (show_in_rest => true), sinon ils seront invisibles ici.

Performance : Script Modules et Lazy Loading natif des iframes

WordPress 6.9 continue sa guerre contre le bloat JavaScript.

Généralisation des Script Modules

Introduits timidement en 6.5, les Script Modules (ESM) deviennent la norme. La fonction wp_enqueue_script_module() remplace progressivement wp_enqueue_script() pour les blocs.

L'avantage majeur est l'élimination de la duplication des dépendances. Si deux plugins requièrent une bibliothèque utilitaire moderne (comme date-fns), et qu'elle est enregistrée comme module, le navigateur ne la téléchargera qu'une seule fois, sans besoin de bundling complexe côté serveur.

Auto-Sizes pour le Lazy Loading

Une amélioration technique subtile mais cruciale pour le CLS (Cumulative Layout Shift) : WordPress injecte désormais automatiquement l'attribut sizes="auto" sur les images lazy-loadées si le navigateur le supporte. Cela permet au navigateur de calculer l'espace nécessaire à l'image avant même d'avoir téléchargé le CSS, en se basant sur les dimensions intrinsèques et le layout prévisionnel.

Pour les développeurs de thèmes : vérifiez que vous ne surchargez pas l'attribut sizes manuellement dans vos fonctions wp_get_attachment_image si vous souhaitez bénéficier de cette optimisation automatique.

Interactivity API : Le passage à la v2

L'Interactivity API (le standard pour faire des blocs interactifs sans jQuery ni React lourd côté front) reçoit une mise à jour significative.

La directive data-wp-context supporte désormais des objets profonds et des références dynamiques. Mais surtout, le Server-Side Rendering (SSR) partiel est optimisé.

Imaginez un bloc "Panier d'achat". Jusqu'à présent, tout le bloc devait être hydraté. Avec la 6.9, vous pouvez définir des zones statiques au sein d'un bloc interactif qui seront ignorées par le runtime JavaScript, économisant du temps de main thread.

<div data-wp-interactive="myPlugin/cart">
    <button data-wp-on--click="actions.toggleCart">Ouvrir</button>
    <div data-wp-ignore>
        <img src="icon.svg" />
        <p>Texte statique lourd...</p>
    </div>
</div>

Block Bindings API : Connecter n'importe quoi à n'importe quoi

C'était la pièce manquante pour faire de l'édition de site un véritable CMS headless-like. La Block Bindings API permet de lier les attributs d'un bloc (comme le content d'un paragraphe ou le url d'une image) à une source de données dynamique (Post Meta, Option, Transients, API externe).

En 6.9, l'interface utilisateur pour connecter ces données arrive enfin dans l'éditeur. Plus besoin de coder le JSON à la main.

Pour les développeurs, cela signifie que nous pouvons créer des Custom Fields complexes (avec ACF ou natifs) et permettre aux clients de les lier visuellement à des blocs natifs sans créer de blocs personnalisés.

Exemple de déclaration d'une source custom :

register_block_bindings_source( 'my-plugin/api-weather', array(
    'label'              => 'Météo Locale',
    'get_value_callback' => 'my_weather_callback',
    'uses_context'       => array( 'postId' ),
) );

function my_weather_callback( array $source_args, $block_instance ) {
    // Appel API externe mis en cache
    return get_weather_for_post( $block_instance->context['postId'] );
}

Deprecations et Nettoyage (Breaking Changes)

Un Field Guide ne serait pas complet sans la liste des choses qui vont disparaître et casser le code existant.

• PHP 8.2 Minimum Recommandé : Si WordPress 6.9 tourne encore sur PHP 8.0, des avertissements de dépréciation (Notices) seront désormais affichés agressivement dans le Health Check. Le support de PHP 7.4 est officiellement en mode "Security Fixes Only" dégradé.

• Suppression de vieux polyfills JS : wp-polyfill a subi une cure d'amaigrissement drastique. Si vous supportez encore IE11 (sérieusement ?), vos scripts risquent de planter. Les navigateurs modernes sont la cible.

• Mise à jour des dépendances React : WordPress embarque désormais une version alignée sur React 19. Attention aux hooks dépréciés comme useContext (dans certains cas spécifiques) ou aux changements sur useRef lors du rendu. Vérifiez la console de votre navigateur.

WordPress 6.9 est une version pour les "Power Users" et les développeurs. Elle nous donne les outils (Abilities, Grid, Script Modules) pour construire des sites plus robustes, plus rapides et plus maintenables.

La barrière à l'entrée technique s'élève légèrement : il devient difficile d'ignorer le JavaScript moderne (ESM, React) ou les concepts d'architecture logicielle (Policies, Resolver). Mais c'est le prix à payer pour une plateforme qui ne se contente plus d'être un moteur de blog, mais un véritable OS pour le web.

Mon conseil immédiat : Installez la RC1 sur un environnement local, lancez vos tests unitaires (surtout ceux liés aux permissions utilisateurs), et commencez à refactoriser vos theme.json pour adopter les nouvelles grilles.

Rendez-vous au déploiement final !