hariri.ch
Prenez contact

Développement

WordPress 7.1 ajoute une API publique pour enregistrer des icônes SVG personnalisées

6 min de lecture

Illustration abstraite montrant des icônes vectorielles reliées à une collection modulaire dans une interface de publication stylisée.

Ce que WordPress 7.1 change pour les icônes

WordPress 7.1 doit être publié le 19 août 2026, et cette version embarque une nouveauté attendue côté développement : une API publique d’enregistrement d’icônes. Le Developer Blog de WordPress présente cette évolution comme l’arrivée d’une API publique pour les icônes personnalisées, avec un article pratique publié le 18 août 2026 par Justin Tadlock.

Concrètement, cela donne aux auteurs de thèmes et d’extensions un point d’entrée officiel pour déclarer leurs propres collections d’icônes SVG, puis exposer chaque icône individuellement. Pour un écosystème aussi large que WordPress, présenté par WordPress.org comme une plateforme de publication open source utilisée par des millions de sites, l’intérêt est surtout la standardisation : au lieu de solutions maison, il devient possible de s’appuyer sur une interface commune.

Cette API arrive dans un contexte où WordPress continue d’élargir ses capacités. La page d’accueil du projet met déjà en avant WordPress 7.0 et la possibilité de connecter des fournisseurs d’IA sur l’ensemble d’un site. Avec 7.1, le sujet est différent, mais l’enjeu reste le même : fournir des briques natives pour éviter de réinventer l’intégration dans chaque projet.

Deux fonctions au cœur du dispositif

L’API repose d’abord sur l’enregistrement d’une collection, via wp_register_icon_collection( string $slug, array $args );. Les arguments mentionnés pour cette fonction sont label et description. Le premier sert d’étiquette lisible et internationalisée pour l’interface, tandis que la description documente la collection.

Une fois la collection créée, les icônes sont enregistrées une par une avec wp_register_icon( string $icon_name, array $icon_properties );. Les propriétés listées sont label, content et file_path.

Le point important est la règle sur la source SVG : content et file_path sont chacun optionnels pris séparément, mais il faut fournir l’un ou l’autre pour qu’une icône soit effectivement enregistrée. En pratique, cela laisse deux approches : embarquer directement le SVG dans le code, ou référencer un fichier SVG sur disque.

Cette séparation entre collection et icônes individuelles est utile pour les projets réels. Une extension peut publier un jeu cohérent d’icônes métier, tandis qu’un thème peut n’en enregistrer qu’un sous-ensemble adapté à son interface ou à ses blocs.

À quoi ressemble l’usage dans un plugin

L’exemple mis en avant dans la documentation s’appuie sur un plugin de démonstration nommé DevBlog: Restaurant Icons. Son en-tête indique une version 1.0.0, un prérequis WordPress de 7.1, un prérequis PHP de 8.1 et une licence GPL-3.0-or-later.

Le dépôt GitHub associé porte le nom wptrainingteam/devblog-restaurant-icons. Sa description précise qu’il s’agit d’un plugin de démonstration pour l’enregistrement d’icônes SVG dans WordPress 7.1+, et le README le présente comme une vitrine pour montrer comment enregistrer et utiliser des icônes SVG personnalisées.

Dans cet exemple, la constante COLLECTION vaut devblog-restaurant. C’est ce slug qui sert de préfixe logique pour les icônes de la collection. Le balisage de bloc généré montré dans l’article prend la forme <!-- wp:icon {"icon":"devblog-restaurant/cake"} /-->. Autrement dit, l’icône est référencée par une combinaison collection/nom, ici devblog-restaurant/cake.

Le jeu d’icônes de démonstration comprend notamment bakery.svg, bento.svg, breakfast.svg, brunch.svg, cake.svg, dinner.svg, kebab.svg, lunch.svg, ramen.svg, restaurant.svg, rice-bowl.svg, soup-kitchen.svg et tapas.svg. Ce n’est pas seulement décoratif : cela montre comment structurer une collection thématique complète, avec des noms d’icônes stables et réutilisables.

Les limites actuelles de l’API SVG

L’API n’ouvre pas la porte à n’importe quel SVG. L’article précise qu’à ce stade, seuls les éléments <svg>, <path> et <polygon> sont autorisés pour une icône SVG. C’est une contrainte importante pour les équipes qui disposent déjà d’une bibliothèque d’assets exportés depuis des outils de design : certains fichiers devront probablement être simplifiés avant de pouvoir être utilisés tels quels.

Autre restriction concrète : l’attribut stroke n’est actuellement pas autorisé. Cela signifie qu’on ne peut pas s’appuyer sur lui pour styliser les SVG dans ce cadre. Pour les bibliothèques d’icônes construites autour de traits plutôt que de formes pleines, cette limitation peut imposer une adaptation du pipeline de production ou du style graphique.

Ces garde-fous ont un impact direct sur l’adoption. L’API est publique, donc exploitable dès WordPress 7.1, mais elle ne remplace pas encore toutes les variantes de SVG que l’on rencontre dans des bibliothèques existantes. Avant migration, il faudra vérifier la compatibilité réelle des fichiers.

Pourquoi cela compte pour les développeurs WordPress

Pour les développeurs d’extensions, l’intérêt principal est de pouvoir livrer des icônes métier sans bricoler une intégration propriétaire. Pour les développeurs de thèmes, cela peut simplifier la cohérence visuelle entre blocs, variations et composants éditoriaux. Et pour les équipes produit, une API officielle réduit le coût de maintenance à long terme : moins de code spécifique, plus d’alignement avec le cœur de WordPress.

Un autre détail mérite l’attention : des points d’accès REST en lecture seule existent pour les icônes. Le fait qu’ils soient explicitement mentionnés indique que les icônes ne sont pas seulement un sujet d’interface interne, mais aussi une ressource exploitable par d’autres couches de l’écosystème. Les détails de ces endpoints ne sont pas fournis ici, mais leur présence suggère des usages côté éditeur, intégrations ou outils de découverte.

Le calendrier compte aussi. Le Developer Blog rappelait en juillet 2026 que la bêta 1 de WordPress 7.1 arrivait le 15 juillet, avec des bêtas hebdomadaires jusqu’à la fin du mois, avant une sortie finale prévue le 19 août 2026. Pour les équipes qui suivent de près les cycles de publication, cela signifie que l’API a été suffisamment stabilisée pour entrer dans la version finale.

En résumé, WordPress 7.1 apporte moins une simple collection d’icônes qu’un cadre officiel pour les enregistrer et les consommer. La nouveauté sera surtout utile aux projets qui veulent intégrer des SVG personnalisés proprement, avec une structure claire par collection, une référence stable dans les blocs, et un comportement aligné sur le cœur. La contrepartie, pour l’instant, est un périmètre SVG encore restreint.

À retenir

  • WordPress 7.1, attendu le 19 août 2026, inclut une API publique pour les icônes personnalisées.
  • Les collections s’enregistrent avec <code>wp_register_icon_collection()</code> et les icônes individuelles avec <code>wp_register_icon()</code>.
  • Pour une icône, il faut fournir soit <code>content</code>, soit <code>file_path</code>.
  • Le balisage d’exemple référence une icône sous la forme collection/nom, comme <code>devblog-restaurant/cake</code>.
  • Seuls <code><svg></code>, <code><path></code> et <code><polygon></code> sont actuellement autorisés, et l’attribut <code>stroke</code> ne l’est pas.
  • Des endpoints REST en lecture seule existent déjà pour les icônes.

Sources