WordPress 7.0 «Armstrong» : tout ce qui change pour les développeurs

Sorti le 20 mai 2026, WordPress 7.0 «Armstrong» est la version la plus significative depuis des années. Plus de 419 tickets Trac fermés, dont 76 améliorations et fonctionnalités. Si pour les éditeurs l’interface a évolué en douceur, côté code c’est une autre histoire : certains changements cassent des hypothèses vieilles de plusieurs années. Tour d’horizon de ce qui compte vraiment si tu maintiens un thème, un plugin ou un site sur mesure.

Le block editor passe à 100 % iframe

C’est la rupture la plus silencieuse et potentiellement la plus douloureuse. Depuis 7.0, chaque session d’édition tourne dans un iframe sans exception. Jusqu’ici tu pouvais cibler window ou document depuis un script injecté dans l’éditeur pour manipuler le DOM. Cette porte est fermée.

• Tout script qui fait window.parent ou document.querySelector sur l’éditeur doit être revu.
• Les styles CSS chargés dans le thème ou un plugin ne « saignent » plus dans l’éditeur automatiquement.
• La fonction add_editor_style() continue de fonctionner, mais uniquement via le mécanisme block editor stylesheet.

Si tu as des blocs personnalisés avec du JavaScript d’édition qui interagit avec l’enveloppe de la page, c’est le premier truc à tester après la mise à jour.

PHP-only block registration

Voilà une feature que beaucoup attendaient depuis le lancement de Gutenberg. Il est maintenant possible d’enregistrer un bloc fonctionnel en pur PHP, sans un seul fichier JavaScript. Le flag autoRegister => true dans supports suffit.

register_block_type( 'mon-plugin/stats', [
    'title'           => 'Statistiques',
    'attributes'      => [
        'titre'  => [ 'type' => 'string',  'default' => 'Chiffres clés' ],
        'compte' => [ 'type' => 'integer', 'default' => 10 ],
        'actif'  => [ 'type' => 'boolean', 'default' => true ],
    ],
    'render_callback' => function ( $attrs ) {
        return sprintf(
            '<div %s><h3>%s</h3><p>%d éléments</p></div>',
            get_block_wrapper_attributes(),
            esc_html( $attrs['titre'] ),
            $attrs['compte']
        );
    },
    'supports' => [
        'autoRegister' => true,
    ],
] );

WordPress génère automatiquement les contrôles d’inspecteur pour les types string, integer, number, boolean et enum. Le preview dans l’éditeur passe par un ServerSideRender qui appelle la REST API à chaque modification d’attribut. Pour des blocs hautement interactifs côté éditeur, l’approche classique reste préférable. Mais pour tout ce qui est rendu serveur pur (requêtes WP_Query, shortcodes migrés, widgets custom), c’est un gain de temps considérable.

L’Abilities API arrive côté JavaScript

L’Abilities API avait été introduite côté PHP dans WordPress 6.9. Dans 7.0, elle reçoit son pendant JavaScript sous forme de deux packages distincts.

@wordpress/abilities est un module de state management autonome, sans dépendance WordPress. Il peut tourner dans n’importe quel projet JS. @wordpress/core-abilities est la couche d’intégration WordPress : une fois chargé, il récupère automatiquement via la REST API toutes les abilities enregistrées côté serveur.

import { registerAbility } from '@wordpress/abilities';

registerAbility({
    name: 'mon-plugin/exporter-csv',
    label: 'Exporter en CSV',
    description: 'Lance un export CSV des articles sélectionnés',
    category: 'mon-plugin',
    callback: async ( params ) => {
        const response = await apiFetch({
            path: '/mon-plugin/v1/export',
            data: params,
            method: 'POST'
        });
        return response;
    },
    meta: { annotations: { readonly: false } },
});

Cette API est conçue pour être consommée par des agents IA, des outils d’automatisation ou d’autres plugins. Commencer à exposer tes actions via cette interface te prépare à l’écosystème qui se construit autour de WordPress 7.x.

L’AI Web Client API : une interface standardisée pour les LLM

WordPress 7.0 embarque un AI Client natif basé sur le package php-ai-client avec trois providers disponibles dans le répertoire officiel : OpenAI, Google et Anthropic. Pour un développeur de plugin, cela signifie qu’on peut déléguer à WordPress la gestion de la connexion au LLM.

$client = WordPressAIget_client();
$response = $client->complete([
    [ 'role' => 'user', 'content' => 'Résume ce contenu : ' . $post->post_content ]
]);

L’API est provider-agnostic. L’admin du site choisit son provider dans le nouvel écran «Connectors» du tableau de bord. Ton plugin ne gère plus de clés API, ne bundle plus de SDK, et fonctionne avec n’importe quel provider configuré par l’utilisateur.

watch() dans l’Interactivity API

L’API d’interactivité (@wordpress/interactivity) gagne une fonction watch() qui permet de réagir aux changements d’état de manière programmatique, sans passer par un attribut data-wp-* sur un élément DOM.

import { watch, getContext } from '@wordpress/interactivity';

watch( () => {
    const ctx = getContext();
    if ( ctx.compteur > 10 ) {
        console.log( 'seuil atteint' );
    }
});

C’est de la réactivité native WordPress : pas de framework externe, pas de dépendance tierce. L’attribut data-wp-watch sur les éléments DOM reste disponible pour les cas simples, watch() sert pour la logique pure sans attache DOM.

États interactifs dans theme.json

Les développeurs de thèmes peuvent maintenant déclarer les styles :hover, :focus, :focus-visible et :active sur les blocs bouton directement dans theme.json, sans CSS personnalisé.

{
    "styles": {
        "blocks": {
            "core/button": {
                "variations": {
                    "outline": {
                        "interactivity": {
                            ":hover": {
                                "color": {
                                    "background": "var(--wp--preset--color--primary)",
                                    "text": "#ffffff"
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

PHP 7.2 et 7.3 supprimés

Le minimum passe à PHP 7.4, la version recommandée est 8.3. Si tu maintiens des sites encore sur PHP 7.2 ou 7.3 en production, c’est le moment de passer à l’action avant la mise à jour vers 7.0.

Ce qui n’a pas atterri

La collaboration en temps réel (RTC) est retirée de 7.0 suite à des problèmes de race conditions, de charge serveur et d’efficacité mémoire. Elle devrait revenir dans une version ultérieure, potentiellement 7.1.

Ressources et communauté

• WordPress 7.0 Field Guide (Make Core) : la référence officielle pour tous les changements.
• Developer Blog WordPress.org : les notes mensuelles «What’s new for developers».
• Make WordPress Core : les décisions architecturales en temps réel.
• WordPress Slack (#core, #core-editor) : là où se prennent les décisions.
• PHP-only block registration (Make Core) : le dev note complet sur autoRegister.
• Client-Side Abilities API (Make Core) : détail technique sur les deux packages JS.
• Abilities API Handbook : documentation officielle.
• WordPress GitHub : le repo Core pour suivre les PRs en cours.