WordPress 7.1 : nouveautés, version 7.1.3 et points à vérifier avant de mettre à jour

WordPress 7.1 « Mary Lou » est sorti le 19 août 2026. La version à installer aujourd’hui est WordPress 7.1.3, publiée le 6 octobre 2026 avec sept correctifs de sécurité. Elle fonctionne à partir de PHP 7.4, mais wordpress.org recommande PHP 8.3 ou plus. Ses principaux apports : des styles responsive dans l’éditeur, un nouvel éditeur d’images avec un traitement des médias dans le navigateur, les blocs Onglets et Playlist, et des Notes de collaboration plus riches.

J’ai suivi la 7.1 depuis sa bêta sur mes environnements de développement. Voici ce qui a réellement été livré (vérifié dans l’annonce officielle et le Field Guide), ce qui a été repoussé, ce qui peut casser sur un site Avada ou Elementor, et la méthode que j’applique pour mettre à jour sans mauvaise surprise.

WordPress 7.1 en bref : date de sortie, dernière version et PHP requis

WordPress 7.1 est la deuxième version majeure de 2026, trois mois après la 7.0 du 20 mai. Selon l’annonce officielle, elle a réuni plus de 800 contributeurs, dont plus de 170 pour la première fois, sous la direction d’Anne McCarthy, et regroupe plus de 1 500 améliorations et corrections. Son nom rend hommage à la pianiste de jazz Mary Lou Williams. Trois versions de maintenance ont suivi.

7.1.1, 7.1.2 et 7.1.3 : des correctifs de sécurité à appliquer sans attendre

Ce sont avant tout des versions de sécurité, que wordpress.org recommande d’installer immédiatement. La plus sérieuse est la 7.1.2 : une traversée de répertoire exploitable sans être connecté dans la résolution des modèles de page, pouvant mener sous conditions à une exécution de code à distance. La 7.1.1 corrigeait entre autres une traversée de répertoire dans l’API REST, exploitable par un compte connecté, et une faille XSS stockée déposable sans compte via un commentaire, une fois celui-ci approuvé ; la 7.1.3, une faille XSS dans l’écran des commentaires et une injection SQL dans l’export WXR. Les notes des versions 7.1.1, 7.1.2 et 7.1.3 ne citent aucun identifiant CVE. Et les mises à jour ne font pas tout : voici comment sécuriser un site WordPress au-delà des mises à jour.

Sur la branche 7.0, le dernier correctif est la 7.0.7, sortie le même jour que la 7.1.3. Ces correctifs sont reportés sur les anciennes branches par courtoisie, mais seule la dernière version de WordPress est activement maintenue : rester en 7.0 ne peut être qu’une solution d’attente. C’était déjà le cas lors de la mise à jour de sécurité 7.0.2.

Quelle version de PHP pour WordPress 7.1 ?

WordPress 7.1 demande PHP 7.4 au minimum : le support de PHP 7.2 et 7.3 a été retiré dans la 7.0. Le tableau de compatibilité officiel la déclare compatible de PHP 7.4 à PHP 8.5. Pour un site en production, wordpress.org recommande PHP 8.3 ou plus, avec MySQL 8.0 ou plus, ou MariaDB 10.11 ou plus.

Le minimum technique n’est pas une version raisonnable. Selon php.net, PHP 7.4, 8.0 et 8.1 ne reçoivent plus aucun correctif, et PHP 8.2 n’en recevra plus après le 31 décembre 2026. PHP 8.3 reçoit des correctifs de sécurité jusqu’à fin 2027, PHP 8.4 jusqu’à fin 2028. Mon conseil : viser PHP 8.3 ou 8.4, après un test du thème et des extensions en préproduction ; c’est souvent une vieille extension, pas WordPress, qui bloque. Votre version s’affiche dans Outils > Santé du site > Informations.

Les nouveautés de WordPress 7.1

Des styles responsive dans l’éditeur

C’est la nouveauté structurante de cette version : vous pouvez définir l’apparence d’un bloc par taille d’écran, depuis les Styles globaux ou les réglages du bloc, sans CSS personnalisé. Elle complète les options d’affichage et de masquage par appareil qui existaient déjà. L’aperçu permet de travailler à plusieurs largeurs d’écran, et les thèmes blocs peuvent définir leurs propres points de rupture mobile et tablette dans le fichier theme.json.

Pour les sites construits avec l’éditeur de blocs, c’est un vrai rattrapage sur les page builders. Sur un site Avada ou Elementor, dont la mise en page passe par le constructeur, elle change peu de choses au quotidien.

Des états de survol et de focus pour les boutons

Dans l’éditeur, seul le bloc Bouton reçoit des réglages distincts pour le survol, le focus et l’état actif, pour un seul bouton ou pour tous. Les auteurs de thèmes disposent des états :hover, :focus, :focus-visible et :active dans theme.json, ainsi que des ombres de texte dans les Styles globaux.

Un nouvel éditeur d’images et des médias traités dans le navigateur

Le bouton Recadrer ouvre désormais une fenêtre dédiée qui réunit le recadrage libre ou par ratio, le retournement horizontal et vertical, la rotation précise et l’édition des métadonnées. Le changement le plus profond est invisible : compression, redimensionnement et miniatures se font dans le navigateur, grâce à une version WebAssembly de libvips. Le serveur travaille moins et les gros envois butent moins sur les limites de PHP.

S’y ajoutent la prise en charge native d’AVIF, de HEIC et des gain maps HDR, la conversion facultative des GIF en vidéo, la reprise automatique des envois interrompus et le défilement infini dans la médiathèque (chaque utilisateur peut revenir à la pagination).

Deux nouveaux blocs : Onglets et Playlist

Un bloc Onglets natif (fini les extensions tierces pour trois onglets de contenu) et un bloc Playlist qui regroupe plusieurs pistes audio, avec une forme d’onde en option. Les développeurs peuvent aussi enregistrer leurs propres collections d’icônes pour le bloc Icône. Petit ajout pratique : le bloc Boucle de requête peut désormais exclure l’article en cours.

Des Notes de collaboration enfin utilisables

Les Notes acceptent maintenant le texte enrichi (gras, italique, code, liens) et les @mentions, qui notifient la personne citée. On peut annoter un passage précis plutôt que le bloc entier, mener plusieurs discussions sur un même bloc et replier les notes longues. Si vous travaillez la rédaction à plusieurs dans l’admin, ça commence à ressembler à Google Docs.

La barre d’administration dans tous les éditeurs

La barre d’administration reste désormais affichée dans tous les éditeurs, y compris l’éditeur de site, avec quelques retouches visuelles. On sait où l’on se trouve et on garde ses raccourcis habituels. Des petites choses, mais qui corrigent des irritants quotidiens.

Côté développeurs : icônes, Abilities API, Design System

• L’API d’icônes SVG devient publique : wp_register_icon_collection(), wp_register_icon() et wp_get_icon().
• L’Abilities API, apparue en 6.9, gagne un cycle d’exécution filtrable, une validation personnalisée et un indicateur d’exposition publique : c’est la base des futures intégrations, y compris par IA.
• Un Design System pour l’administration (jetons de design, composant ThemeProvider), des supports de bloc dégradé et largeur minimale, des info-bulles accessibles (wp_get_tooltip()).
• jQuery UI passe en version 1.14.2.

Aucune fonction d’IA n’apparaît dans l’interface : la 7.1 pose de l’infrastructure. Le détail est dans le Field Guide de WordPress 7.1.

Ce qui n’est pas arrivé dans WordPress 7.1

Plusieurs articles écrits avant la sortie, dont la première version de celui-ci, rédigée pendant la bêta, présentent comme acquises des fonctions qui n’ont pas été livrées.

• L’édition collaborative en temps réel a été testée, mais n’est pas activée.
• Le passage à React 19 est reporté ; il reste une expérimentation dans l’extension Gutenberg.
• Le bloc Classique reste dans l’outil d’insertion : son masquage a été proposé, puis annulé.
• Le widget « On This Day » du tableau de bord n’a pas été retenu.
• Le préchargement spéculatif ne devient pas plus agressif. Le réglage par défaut reste prudent (prefetch, conservative) ; la 7.1 permet seulement de le changer sans extension (voir plus bas).
• Le streaming et les embeddings de l’AI Client, envisagés par l’équipe IA pendant le cycle, ainsi que les Block Bindings sur les éléments de liste ou les galeries remplies automatiquement, ne figurent ni dans l’annonce ni dans le Field Guide.

Ce qui peut casser après la mise à jour : mes points de vigilance

Une version majeure ne casse jamais « en général ». Elle casse sur des configurations précises. Voici celles que je surveille.

L’éditeur d’articles entièrement en iframe

Comme l’éditeur de site avant lui, l’éditeur d’articles tourne désormais dans une iframe pour tous les thèmes, y compris quand des extensions ajoutent d’anciennes meta boxes. Les styles de l’administration ne débordent plus sur le contenu, mais les extensions qui allaient chercher des éléments de l’éditeur depuis la page d’administration, en JavaScript ou en CSS, peuvent cesser de fonctionner. Si votre back-office repose sur des extensions d’édition anciennes ou peu maintenues, testez avant.

jQuery UI 1.14.2 et les vieux écrans d’extensions

La nouvelle version de jQuery UI peut modifier les écrans d’administration qui en dépendent (glisser-déposer, sélecteurs de date, fenêtres de dialogue). Après la mise à jour, ouvrez les réglages des extensions les plus anciennes et vérifiez qu’ils enregistrent toujours.

Avada, Elementor : attendre la version compatible du constructeur

C’est le point qui concerne le plus grand nombre de mes clients, dont les sites tournent sous Avada ou Elementor. Leurs éditeurs publient en général des correctifs de compatibilité dans les jours ou les semaines qui suivent chaque version majeure. La règle que j’applique systématiquement : on ne met pas à jour le cœur en production tant que le constructeur n’a pas publié sa version compatible. Puis on teste les deux ensemble en préproduction.

Le 8 octobre 2026, la fiche wordpress.org d’Elementor indiquait une compatibilité testée jusqu’à WordPress 7.1.3, comme celles de WooCommerce, Rank Math et Wordfence : une déclaration de l’éditeur, pas une garantie pour votre combinaison d’extensions. Avada, vendu hors du répertoire officiel, se vérifie dans le journal des modifications de ThemeFusion. Et WooCommerce 11.2 exige WordPress 7.0 au minimum. Seule exception à cette patience : les versions de sécurité (7.1.3, ou 7.0.7 sur la branche 7.0), qui s’appliquent sans attendre.

Le traitement des images et vos extensions d’optimisation

Avec la compression faite dans le navigateur, une extension d’optimisation d’images (CompressX, Imagify, ShortPixel…) peut faire une partie du travail en double. Envoyez quelques images de formats différents, dont du HEIC, et vérifiez le poids final, les miniatures et le format servi aux visiteurs.

Le préchargement spéculatif : ce qui change vraiment

Depuis la 6.8, WordPress demande au navigateur de précharger certaines pages pour les visiteurs non connectés, quand le site utilise des permaliens lisibles. La 7.1 garde le réglage par défaut (prefetch, conservative), mais permet de le modifier sans extension, par deux constantes ou les variables d’environnement du même nom. Le filtre wp_speculation_rules_configuration reste prioritaire.

// Dans wp-config.php, avant la ligne require_once ABSPATH . 'wp-settings.php';
// Mode : 'prefetch' (défaut) ou 'prerender'.
define( 'WP_SPECULATIVE_LOADING_DEFAULT_MODE', 'prefetch' );
// Niveau : 'conservative' (défaut), 'moderate' ou 'eager'.
define( 'WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS', 'moderate' );

Avant de rendre le préchargement plus agressif, vérifiez que les URL à effet de bord en sont exclues. WordPress écarte déjà l’administration, la page de connexion, les liens avec paramètres (avec des permaliens lisibles), les liens rel="nofollow" et les éléments portant la classe no-prefetch. Si votre extension de boutique n’écarte pas déjà le panier, la commande et le compte client, une petite extension à placer dans wp-content/mu-plugins/ suffit (adaptez les chemins aux pages de votre site) :

<?php
/**
 * Plugin Name: Exclusions du préchargement spéculatif
 * Description: Retire le panier, la commande et le compte client du préchargement spéculatif (WordPress 6.8 ou plus).
 */
defined( 'ABSPATH' ) || exit;
/**
 * Ajoute des chemins à exclure des règles de préchargement générées par WordPress.
 *
 * WordPress ajoute lui-même ses exclusions de base (wp-admin, wp-login.php, etc.) :
 * le filtre ne reçoit que les chemins ajoutés par d'autres extensions.
 *
 * @param string[] $paths Chemins supplémentaires à exclure (le joker * est accepté).
 * @return string[]
 */
function devwp_speculation_exclude_paths( $paths ) {
	return array_merge( (array) $paths, array( '/panier/*', '/commande/*', '/mon-compte/*' ) );
}
add_filter( 'wp_speculation_rules_href_exclude_paths', 'devwp_speculation_exclude_paths' );

En mode prerender, la page est réellement exécutée à l’avance : vérifiez que vos statistiques ne comptent pas de visites fantômes et surveillez la charge du serveur.

Mettre à jour vers WordPress 7.1.3 sans casser son site : ma méthode

Les versions mineures de sécurité s’installent automatiquement par défaut, sauf si votre hébergeur ou une extension a désactivé ces mises à jour. Pour passer d’une branche majeure à l’autre, de 7.0.x à 7.1.3 par exemple, voici l’ordre des opérations que j’applique.

1. D’abord, une sauvegarde complète testée (fichiers et base de données, et vous savez la restaurer).
2. Ensuite, la version de PHP vérifiée dans Outils > Santé du site : 8.3 ou plus de préférence.
3. Puis un test sur un environnement de préproduction, jamais directement en production : mêmes extensions, même thème, même version PHP.
4. Avant la production, la vérification des compatibilités annoncées par vos extensions critiques et votre constructeur de pages : leur journal des modifications vous dit s’ils sont prêts pour la 7.1.
5. La mise à jour en production, à un moment de faible trafic, une fois la préproduction validée.
6. Enfin, un tour du propriétaire : pages clés, formulaires, tunnel de commande si vous vendez en ligne, et un œil sur les erreurs PHP dans les journaux.

Si cette liste vous semble raisonnable mais que vous savez déjà que vous ne la ferez pas (pas le temps, pas d’environnement de test, pas envie de lire des journaux de modifications), c’est très exactement le travail que je fais pour mes clients dans le cadre de mes contrats de maintenance : chaque version majeure est testée sur une copie de leur site avant d’être déployée, avec sauvegarde et vérification derrière. Et le rythme ne faiblit pas : trois versions majeures en 2026 (7.0 en mai, 7.1 en août, 7.2 prévue début décembre), sans compter les versions de sécurité. Si vous envisagez de déléguer ce suivi, j’ai détaillé ailleurs les tarifs de maintenance pratiqués sur le marché.

Mon avis sur WordPress 7.1

La 7.1 est une bonne mise à jour. C’est une version de consolidation intelligente : les styles responsive natifs comblent un manque historique de l’éditeur, la refonte des médias s’attaque à un des points les plus datés de WordPress, et les fondations IA sont posées proprement, en infrastructure plutôt qu’en gadget. Pas de révolution visible, mais une plateforme plus solide.

Les styles responsive remplacent-ils un page builder ? Pas encore. Ils comblent le manque le plus criant de l’éditeur de blocs, mais un constructeur comme Avada ou Elementor conserve une longueur d’avance sur les mises en page complexes, les templates conditionnels et l’écosystème de widgets. En revanche, pour un nouveau site éditorial simple, l’éditeur natif devient une option de plus en plus sérieuse.

Si votre site n’est pas encore en 7.1.3 (ou en 7.0.7 sur la branche 7.0), c’est la priorité, avant toute nouveauté.

Questions fréquentes sur WordPress 7.1

Vous hésitez à passer votre site en 7.1.3, ou vous voulez faire tester votre thème et vos extensions en préproduction avant ? Décrivez-moi votre site, et nous verrons ensemble ce qu’il faut vérifier avant la mise à jour.

Mis à jour en octobre 2026, avec WordPress 7.1.3.