WordPress 7.1 ouvre enfin la porte aux bibliothèques d’icônes natives

Une vraie API d’icônes arrive dans WordPress 7.1

WordPress avait déjà introduit un bloc Icon avec la version 7.0, mais il manquait encore un élément essentiel : une API publique permettant aux thèmes et extensions d’ajouter leurs propres pictogrammes.

WordPress 7.1 corrige ce manque avec une nouvelle Icon Registration API.

Deux fonctions constituent le cœur du système : wp_register_icon_collection() pour déclarer une collection, puis wp_register_icon() pour enregistrer les icônes qui lui appartiennent.

Une fois enregistrées, elles peuvent apparaître dans la bibliothèque du bloc Icon, être rendues directement en PHP avec wp_get_icon() ou être exposées via l’API REST. Cette dernière n’est toutefois pas publique : les routes sont en lecture seule et nécessitent un utilisateur authentifié disposant de la capacité edit_posts.

Des SVG locaux plutôt qu’une bibliothèque complète

C’est probablement là que cette nouveauté devient particulièrement intéressante pour les performances.

Une icône peut être déclarée de deux façons :

• avec son markup SVG directement dans content ;
• avec le chemin absolu d’un fichier .svg via file_path.

Il faut choisir l’une ou l’autre : fournir content et file_path en même temps fait échouer l’enregistrement.

Dans le cas de file_path, WordPress précise que le fichier est chargé de manière lazy : il n’est pas lu lors de l’enregistrement de l’icône, mais uniquement lorsque son contenu est réellement nécessaire, par exemple lors du rendu ou d’une requête REST.

Cette logique a un corollaire pratique : un mauvais chemin peut passer inaperçu au moment de l’enregistrement. Le problème ne se manifeste que plus tard, lorsque WordPress tente réellement de lire le fichier, avec un contenu vide plutôt qu’une erreur immédiate d’enregistrement. C’est un petit piège de debug à garder en tête.

Le rendu via wp_get_icon() retourne ensuite directement le markup SVG prêt à être intégré dans la page.

Pour un site qui utilise aujourd’hui une bibliothèque comme Font Awesome uniquement pour afficher quelques icônes, l’approche est séduisante. Il devient possible d’embarquer seulement les SVG réellement utiles dans un thème ou une extension, sans charger une police d’icônes, une feuille CSS globale ou un kit JavaScript tiers.

Un potentiel gain de performances, mais pas automatique

Cette API ne signifie évidemment pas que toute utilisation de Font Awesome deviendra instantanément inutile.

Une bibliothèque tierce apporte aussi un catalogue très large, une nomenclature cohérente, des variantes et parfois des composants prêts à l’emploi. WordPress fournit ici surtout l’infrastructure permettant de construire sa propre bibliothèque légère.

Pour des projets maîtrisés, notamment des sites sur mesure, c’est en revanche très intéressant. Une dizaine de pictogrammes SVG intégrés localement peuvent être beaucoup plus raisonnables qu’une dépendance globale chargée sur toutes les pages.

Le principal avantage est architectural : chaque icône peut devenir une petite ressource indépendante, enregistrée une fois puis rendue là où elle est nécessaire.

Mais il y a une différence importante avec une icon font ou une bibliothèque déjà pensée pour hériter naturellement de la couleur du texte. Dans WordPress 7.1, l’allowlist conserve fill sur les éléments <path> et <polygon>, mais pas sur le <svg> externe. Un wp_get_icon() utilisé seul peut donc afficher l’icône avec la couleur définie dans ses formes — souvent du noir — plutôt qu’avec la couleur du texte environnant.

Le bloc Icon masque en partie ce problème grâce à sa propre feuille de style. En PHP standalone, si l’objectif est réellement de remplacer Font Awesome dans un thème, il faut prévoir son CSS ou enregistrer les formes avec fill="currentColor". Le remplacement est donc possible, mais pas totalement iso-fonctionnel.

Les SVG restent très encadrés dans WordPress 7.1

La première version de l’API impose plusieurs restrictions.

Pour des raisons de sécurité, WordPress sanitize les SVG avec une liste très limitée d’éléments autorisés. Dans WordPress 7.1, seuls <svg>, <path> et <polygon> sont conservés, et chacun de ces éléments est lui-même limité à un jeu fixe d’attributs autorisés.

Les attributs utilisant stroke sont également supprimés. Les icônes reposant sur des contours plutôt que sur des formes remplies peuvent donc ne pas fonctionner correctement.

Le Core travaille déjà sur un élargissement de cette liste pour les prochaines versions.

Autre limite : l’intégration native est aujourd’hui surtout visible dans le bloc Icon. WordPress envisage déjà de rendre le sélecteur d’icônes réutilisable dans d’autres blocs, mais ce travail n’est pas encore finalisé pour 7.1.

Un point intéressant pour l’accessibilité

La nouvelle API ne se limite pas au rendu visuel. wp_get_icon() accepte aussi un paramètre label pour fournir un libellé accessible lorsque l’icône porte une information utile.

Lorsqu’un label est fourni, l’icône peut être annoncée aux lecteurs d’écran. Sans libellé, elle est considérée comme décorative et masquée aux technologies d’assistance.

Pour les projets soumis à des exigences d’accessibilité, notamment RGAA, c’est un détail important : le Core fournit déjà un mécanisme explicite pour distinguer une icône informative d’une simple décoration. Cela évite de bricoler systématiquement aria-hidden, role ou un texte masqué autour du SVG.

Une petite API qui pourrait avoir beaucoup d’impact

Cette fonctionnalité peut sembler secondaire face aux évolutions majeures de l’éditeur ou du Full Site Editing. Pourtant, elle répond à un problème très concret rencontré dans énormément de projets WordPress : comment gérer proprement quelques icônes sans embarquer toute une dépendance externe ?

Avec une API native, des SVG locaux et un rendu directement intégré au Core, WordPress fournit enfin une réponse standardisée.

Cela ne signe probablement pas la fin de Font Awesome et des autres bibliothèques d’icônes. Mais pour les thèmes et extensions qui n’utilisent qu’une petite partie de ces catalogues, WordPress 7.1 offre désormais une alternative beaucoup plus légère et surtout beaucoup mieux intégrée — à condition de tenir compte de ses limites actuelles sur la couleur, la sanitization, l’accès REST et le rendu accessible.