Lorsque l’on développe ou personnalise un site WordPress, nous savons que le fichier functions.php
joue un rôle central. Il permet d’ajouter facilement des fonctionnalités sans avoir besoin de créer un plugin. Pourtant, ce fichier est souvent sous-utilisé ou mal exploité, alors qu’il peut considérablement améliorer l’expérience utilisateur, les performances ou encore la sécurité du site. Dans cet article, nous allons explorer 10 extraits de code (ou « snippets ») à intégrer dans votre fichier functions.php
. Ils couvrent un éventail de besoins concrets : optimisation des ressources, amélioration du back-office, enrichissement des formats de contenu, et bien plus. Tous les exemples sont testés, commentés et prêts à l’emploi.
- Avant-propos : Un snippet, c’est quoi ?
- Améliorer les performances et le front-end avec des fonctions ciblées
- Personnaliser le back-office et le comportement de WordPress
- 4. Ajouter des formats d’image personnalisés dans WordPress
- 5. Masquer les menus inutiles dans l’administration
- Pourquoi faire cela pour un client ?
- 6. Ajouter un message personnalisé dans l’admin
- En mode agence, pourquoi faire ceci sur les interfaces clients ?
- 7. Rediriger automatiquement les utilisateurs après connexion
- Étendre les capacités de contenu de votre site WordPress
Avant-propos : Un snippet, c’est quoi ?
Dans le développement WordPress (et plus largement en programmation d’ailleurs), un snippet désigne un petit extrait de code réutilisable qui remplit une fonction bien précise. Il peut s’agir de quelques lignes de PHP permettant d’ajouter, de modifier ou de désactiver un comportement dans votre site. Les snippets sont souvent utilisés dans le fichier functions.php
d’un thème, car ils permettent d’ajouter des fonctionnalités sans créer un plugin complet.
Concrètement, un snippet peut par exemple désactiver une fonctionnalité par défaut, modifier une interface, automatiser une tâche, ou encore optimiser le front-end. Leur avantage principal réside dans leur simplicité : ce sont des blocs indépendants, faciles à comprendre, à tester et à retirer. Dans cet article, nous allons découvrir une sélection de snippets pratiques à ajouter dans le fichier functions.php
pour enrichir, alléger ou sécuriser un site WordPress.
Améliorer les performances et le front-end avec des fonctions ciblées
Commençons par utiliser des bouts de codes permettant d’améliorer la performance et le front-end :
1. Supprimer la version des scripts et styles dans le front-end de WP
Par défaut, WordPress ajoute un paramètre de version aux URLs des fichiers CSS et JavaScript chargés sur votre site. Cela ressemble à ceci :
<link rel="stylesheet" href="style.css?ver=6.5.2">
Ce paramètre ?ver=
peut poser plusieurs problèmes :
- Il empêche le navigateur de mettre correctement les fichiers en cache, car toute modification de version peut forcer le rechargement ,
- Il révèle la version de WordPress utilisée, ce qui peut être une information exploitable par des scripts malveillants. C’est donc une option de sécurité utile (voir notre article également sur Wordfence).
Voici donc un snippet pour supprimer ce paramètre de toutes les ressources CSS et JS dans le front-end :
function remove_cssjs_ver( $src ) {
if( strpos( $src, '?ver=' ) )
$src = remove_query_arg( 'ver', $src );
return $src;
}
add_filter( 'style_loader_src', 'remove_cssjs_ver', 10, 2 );
add_filter( 'script_loader_src', 'remove_cssjs_ver', 10, 2 );
Ce code fonctionne en interceptant les URLs générées par WordPress pour les scripts et styles, et en supprimant le paramètre ver
. Cela améliore légèrement les performances de mise en cache côté navigateur, surtout sur des sites à fort trafic ou à contenu statique important. Il contribue également à minimiser l’exposition d’informations techniques.
Notez que si vous utilisez un système de versionnement personnalisé (par exemple via Webpack ou Laravel Mix), vous pouvez gérer vos propres paramètres de cache.
2. Désactiver l’API Emojis de WordPress
Depuis WordPress 4.2, une bibliothèque JavaScript est chargée automatiquement sur tous les sites pour permettre l’affichage universel des emojis, même sur les anciens navigateurs. Ce comportement est activé même si vous n’utilisez jamais d’emojis dans vos contenus.
Voici un exemple de code que WordPress ajoute automatiquement :
<script src="wp-emoji-release.min.js"></script>
Sur un site professionnel, cette fonctionnalité est souvent inutile, et peut :
- Allonger un peu le temps de chargement de vos pages (requête JS et CSS supplémentaires) ;
- Polluer le
<head>
avec du code inutile ; - Gêner les outils d’optimisation de performance (PageSpeed Insights, Lighthouse, GTMetrix)
Ce bout de code permet de désactiver complètement l’API Emoji de WordPress, en retirant tous les scripts et styles associés dans l’administration comme sur le site public :
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
En supprimant ces actions, vous évitez le chargement du JavaScript wp-emoji-release.min.js
et des styles associés. Cela réduit le nombre de requêtes HTTP, améliore légèrement le score de performance, et vous donne plus de contrôle sur le code injecté dans vos pages. Attention, cette désactivation n’a aucun impact négatif sur les fonctionnalités essentielles de WordPress. Les emojis restent visibles dans les navigateurs modernes sans cette API supplémentaire.
3. Retirer les scripts de type « jquery-migrate » inutiles dans WP
WordPress charge par défaut la bibliothèque jquery-migrate
lorsqu’il inclut jQuery
sur le site. Ce fichier est censé assurer la compatibilité avec les anciens scripts jQuery (version 1.x), en comblant les différences de syntaxe ou de comportement entre les anciennes et nouvelles versions de la bibliothèque. Concrètement, cela signifie que même si votre thème ou vos plugins utilisent des versions modernes de jQuery, WordPress ajoutera une dépendance inutile à chaque chargement :
<script src=".../jquery.js"></script>
<script src=".../jquery-migrate.min.js"></script>
Ce script supplémentaire représente :
- Un temps de chargement supplémentaire (même minime, souvent 2 à 4 Ko compressés) ;
- Un script exécuté inutilement à chaque page ;
- Un bruit technique dans vos audits de performance de vitesse.
Voici comment le supprimer proprement dans le front-end (mais pas dans l’administration, pour éviter des conflits dans l’éditeur ou les plugins) :
function remove_jquery_migrate( $scripts ) {
if ( ! is_admin() && isset( $scripts->registered['jquery'] ) ) {
$script = $scripts->registered['jquery'];
if ( $script->deps ) {
$script->deps = array_diff( $script->deps, array( 'jquery-migrate' ) );
}
}
}
add_action( 'wp_default_scripts', 'remove_jquery_migrate' );
Ce code fonctionne de la manière suivante :
- Il intercepte le registre des scripts par défaut de WordPress ;
- Il identifie le script
jquery
dans la liste des scripts enregistrés ; - Il supprime
jquery-migrate
de ses dépendances si elle est présente.
Grâce à cette modification, seul le fichier jquery.js
sera chargé. Cela est recommandé si :
- Vous développez vos propres scripts avec une version moderne de jQuery (WordPress utilise jQuery 3.x depuis les versions récentes) ;
- Vos plugins sont à jour et ne dépendent plus d’anciennes syntaxes jQuery (notamment celles abandonnées après jQuery 1.9).
Attention : Avant de supprimer jquery-migrate
, testez bien l’ensemble des fonctionnalités de votre site (menus, sliders, AJAX, etc.). Certains plugins mal maintenus peuvent encore en dépendre. Vous pouvez également inspecter votre console navigateur (F12 > Console) après suppression pour détecter d’éventuelles erreurs liées à l’absence de jquery-migrate
. Si tout fonctionne correctement, vous pouvez garder cette optimisation.
Personnaliser le back-office et le comportement de WordPress
Quelques scripts à présent pour personnaliser le back-office de WP et le comportement du CMS via le fichier function.php :
4. Ajouter des formats d’image personnalisés dans WordPress
WordPress génère automatiquement plusieurs tailles d’image lorsque vous téléversez un média dans la médiathèque : miniature (thumbnail
), moyenne (medium
), grande (large
), etc. Ces tailles sont configurables dans l’administration (Réglages > Médias), mais elles restent globales et limitées. Dans de nombreux cas, surtout en développement de thèmes personnalisés, il est nécessaire d’avoir des dimensions spécifiques pour afficher les images de manière cohérente dans des sections bien définies (grilles de blog, carrousels, blocs d’équipe, etc.). WordPress permet de définir des tailles d’image supplémentaires via le fichier functions.php
à l’aide de la fonction add_image_size()
. Voici un exemple :
add_image_size( 'custom-thumb', 400, 250, true );
Ce code crée une nouvelle taille d’image nommée custom-thumb
avec les caractéristiques suivantes :
- Largeur : 400 pixels ;
- Hauteur : 250 pixels ;
- Crop :
true
signifie que l’image sera rognée pour respecter exactement les dimensions définies (recadrage centré par défaut).
Une fois cette taille définie, elle est automatiquement appliquée aux nouvelles images téléversées. Pour les anciennes images déjà présentes dans votre bibliothèque, vous devez les régénérer à l’aide d’un plugin comme Regenerate Thumbnails.
Dans vos templates ou fichiers PHP de thème, vous pouvez afficher cette taille personnalisée comme suit :
the_post_thumbnail( 'custom-thumb' );
Ce code affichera l’image à la taille exacte de custom-thumb
si elle a été générée, sinon WordPress utilisera une taille par défaut. Il est recommandé d’intégrer ce type d’appel dans une vérification conditionnelle si le format est critique :
if ( has_post_thumbnail() ) {
the_post_thumbnail( 'custom-thumb' );
}
Vous pouvez également créer plusieurs formats pour différents usages (vignettes d’actualités, bannières, logos, etc.) :
add_image_size( 'banner', 1200, 500, true );
add_image_size( 'team-thumb', 300, 300, true );
add_image_size( 'wide-thumb', 800, 400, true );
En parallèle, si vous souhaitez permettre à vos éditeurs de choisir cette taille personnalisée dans l’éditeur de blocs Gutenberg ou dans l’éditeur classique, vous devez l’enregistrer également via :
function register_custom_image_sizes() {
add_image_size( 'custom-thumb', 400, 250, true );
add_filter( 'image_size_names_choose', function( $sizes ) {
return array_merge( $sizes, [
'custom-thumb' => 'Custom Thumbnail (400x250)',
]);
});
}
add_action( 'after_setup_theme', 'register_custom_image_sizes' );
Ce complément ajoute l’option Custom Thumbnail dans le menu déroulant des tailles d’image dans l’interface d’insertion des médias. Définir des tailles d’image spécifiques permet de maîtriser l’affichage et le poids des images sur votre site (voir aussi notre sujet sur WP Imagify). Cela évite d’utiliser des images surdimensionnées ou mal recadrées, ce qui améliore à la fois le design, les performances et l’accessibilité.
L’interface d’administration de WordPress est puissante, mais elle peut aussi devenir déroutante pour des utilisateurs non techniques, comme des clients ou des contributeurs occasionnels. Par défaut, de nombreux menus sont visibles même s’ils ne sont pas pertinents pour leur rôle ou leur niveau d’intervention sur le site. Par exemple, des éléments comme « Outils », « Commentaires », ou certains menus ajoutés par des plugins peuvent entraîner des erreurs involontaires ou simplement créer de la confusion. Dans une logique de simplification et de sécurité, il est souvent judicieux d’alléger l’interface en ne montrant que ce qui est strictement nécessaire.
Voici un extrait de code permettant de masquer certains éléments de menu dans le back-office WordPress :
function remove_menus(){
remove_menu_page( 'tools.php' ); // Outils
remove_menu_page( 'edit-comments.php' ); // Commentaires
}
add_action( 'admin_menu', 'remove_menus' );
Ce code est exécuté via le hook admin_menu
, qui est appelé lors de la génération des menus du tableau de bord. La fonction remove_menu_page()
prend en paramètre le slug du menu à supprimer. Dans cet exemple :
tools.php
fait référence au menu « Outils »edit-comments.php
fait référence au menu « Commentaires »
Pourquoi faire cela pour un client ?
Plusieurs logiques à cela :
- Pour éviter les erreurs : certains clients peuvent être tentés de modifier des réglages ou utiliser des outils qu’ils ne maîtrisent pas ;
- Pour simplifier l’expérience : une interface plus épurée permet au client de se concentrer sur les tâches qui le concernent (ajout d’articles, gestion des médias, mise à jour de contenus) ;
- Pour valoriser votre prestation : proposer un tableau de bord personnalisé et épuré donne une impression de solution sur mesure, mieux pensée.
Exemple concret : si vous développez un site vitrine où les commentaires sont désactivés, il est inutile de laisser le menu « Commentaires » actif. De même, le menu « Outils » contient parfois des fonctionnalités avancées (import/export, diagnostique santé) qui peuvent prêter à confusion.
Personnalisation par rôle : Vous pouvez aussi conditionner la suppression de ces menus à un rôle utilisateur (par exemple, n’appliquer ce masquage que pour les utilisateurs ayant le rôle « editor » ou « contributor ») :
function remove_menus_for_clients(){
if( current_user_can('editor') ) {
remove_menu_page( 'tools.php' );
remove_menu_page( 'edit-comments.php' );
remove_menu_page( 'plugins.php' );
}
}
add_action( 'admin_menu', 'remove_menus_for_clients' );
Ce code permet par exemple de laisser l’accès complet aux administrateurs tout en limitant l’interface pour les autres profils. C’est un bon compromis entre contrôle et accessibilité. Vous pouvez aussi aller plus loin en combinant cette méthode avec des plugins comme Adminimize ou WP Admin UI Customize, qui offrent une interface graphique pour gérer les éléments visibles selon les rôles.
6. Ajouter un message personnalisé dans l’admin
Par défaut, WordPress affiche en bas de l’administration (dans le pied de page) un message générique tel que :
Merci d’avoir créé avec WordPress
Bien que ce message soit discret, il ne reflète ni votre marque ni celle de votre client. Dans une logique de personnalisation du back-office, vous pouvez facilement remplacer ce texte par un message personnalisé à l’aide d’un simple filtre dans le fichier functions.php
.
Voici un exemple de snippet permettant d’ajouter un message de bienvenue ou un rappel utile dans le pied de page de l’administration :
function custom_admin_footer() {
echo 'Bienvenue sur votre interface WordPress personnalisée. Pensez à sauvegarder régulièrement.';
}
add_filter( 'admin_footer_text', 'custom_admin_footer' );
Ce code utilise le filtre admin_footer_text
, qui permet de modifier dynamiquement le contenu affiché dans la zone inférieure gauche de l’administration WordPress. Vous pouvez y insérer :
- Un message de bienvenue
- Une consigne de sécurité (ex. : sauvegardes, mises à jour)
- Des coordonnées de support ou de contact
- Un lien vers une documentation interne ou une base de connaissances
En mode agence, pourquoi faire ceci sur les interfaces clients ?
- Pour rendre l’interface plus conviviale et orientée utilisateur
- Pour rappeler les bonnes pratiques, comme la sauvegarde ou la mise à jour régulière des contenus
- Pour valoriser votre accompagnement en y intégrant votre nom ou votre agence (ex. : « Site conçu par WebCréatif • Support : support@webcreatif.fr »)
Voici une version plus complète, intégrant un lien vers un support client :
function custom_admin_footer() {
echo 'Besoin d’aide ? Contactez notre support : <a href="mailto:support@votre-agence.fr">support@votre-agence.fr</a>';
}
add_filter( 'admin_footer_text', 'custom_admin_footer' );
Vous pouvez aussi afficher un message différent selon le rôle de l’utilisateur connecté :
function custom_admin_footer_by_role() {
if ( current_user_can( 'editor' ) ) {
echo 'Bonjour ! N’oubliez pas de relire vos articles avant publication.';
} elseif ( current_user_can( 'administrator' ) ) {
echo 'Administration avancée activée. Pensez à sauvegarder la base de données.';
} else {
echo 'Bienvenue dans votre espace personnalisé.';
}
}
add_filter( 'admin_footer_text', 'custom_admin_footer_by_role' );
Cette personnalisation contribue à créer une expérience administrateur plus fluide, rassurante et orientée métier. C’est aussi une belle touche finale pour un site WordPress professionnel livré à un client. Si vous voulez encore aller plus loin, vous pouvez également modifier le texte de la partie droite du pied de page (qui indique la version de WordPress) via le filtre update_footer
.
7. Rediriger automatiquement les utilisateurs après connexion
Par défaut, après une connexion réussie, WordPress redirige les utilisateurs vers le tableau de bord principal de l’administration (/wp-admin/
). Ce comportement convient dans un environnement standard, mais peut rapidement devenir inefficace, voire contre-productif, dans le cadre d’un site structuré avec plusieurs types d’utilisateurs ayant des rôles et des objectifs distincts. Par exemple, un éditeur n’a généralement pas besoin d’accéder à tout le tableau de bord. Il pourrait être plus pertinent de le rediriger directement vers l’interface de gestion des articles (edit.php
), ce qui lui permet de commencer à travailler sans navigation supplémentaire. De même, un abonné ou un auteur pourrait être redirigé vers une page de profil, un espace dédié, ou même le front-end du site.
Voici un extrait de code permettant de rediriger automatiquement les utilisateurs en fonction de leur rôle :
function redirect_after_login( $redirect_to, $request, $user ){
if ( isset( $user->roles ) && is_array( $user->roles ) ) {
if ( in_array( 'editor', $user->roles ) ) {
return admin_url( 'edit.php' );
}
}
return $redirect_to;
}
add_filter( 'login_redirect', 'redirect_after_login', 10, 3 );
Ce code utilise le filtre login_redirect
, qui permet de modifier dynamiquement l’URL de redirection après une authentification réussie. Voici ce que fait chaque partie :
$redirect_to
: l’URL par défaut de redirection, que nous allons éventuellement modifier ;$request
: l’URL demandée initialement par l’utilisateur, si elle existe ;$user
: l’objet utilisateur connecté, à partir duquel on peut détecter son rôle.
Dans l’exemple ci-dessus, on vérifie si l’utilisateur possède le rôle editor
, et on le redirige vers l’écran d’édition des articles (/wp-admin/edit.php
), ce qui est logique dans une logique de contribution éditoriale.
Vous pouvez facilement adapter cette logique à d’autres rôles ou destinations. Par exemple :
function redirect_users_by_role( $redirect_to, $request, $user ){
if ( isset( $user->roles ) && is_array( $user->roles ) ) {
if ( in_array( 'author', $user->roles ) ) {
return admin_url( 'edit.php?post_type=post' );
}
if ( in_array( 'subscriber', $user->roles ) ) {
return home_url( '/mon-espace/' );
}
}
return $redirect_to;
}
add_filter( 'login_redirect', 'redirect_users_by_role', 10, 3 );
Dans cet exemple :
- Les auteurs sont redirigés vers la liste des articles ;
- Les abonnés sont redirigés vers une page front-end spécifique appelée « Mon espace ».
Les intérêts sont multiples :
- Pour améliorer l’ergonomie et l’efficacité de la navigation utilisateur ;
- Pour guider chaque rôle vers les tâches qui le concernent, sans les faire passer par une interface inutilement générale ;
- Pour restreindre certains rôles à une section déterminée du site ou de l’administration
Cette logique peut être combinée avec des restrictions d’accès (via des plugins ou des conditions PHP) pour créer des environnements cloisonnés par rôle, renforçant ainsi l’organisation et la sécurité de votre site. Notez que si l’utilisateur tente de se connecter en accédant directement à une URL protégée (par exemple un lien d’administration), cette URL sera prioritaire, sauf si vous forcez la redirection personnalisée. Si vous voulez qu’elle s’impose dans tous les cas, utilisez également wp_login
ou surchagez le $request
.
Étendre les capacités de contenu de votre site WordPress
Dernière ligne droit de nos 10 snippets, étendre les capacités de contenu de WP :
8. Créer un shortcode personnalisé
Les shortcodes sont une fonctionnalité puissante de WordPress permettant d’insérer facilement du contenu dynamique dans des pages, des articles, des widgets ou même des champs personnalisés, il existe par ailleurs une multitude de plugins qui permettent d’en ajouter sans passer par le fichier function comme par exemple le célèbre Shortcode Ultimate. Ils sont surtout utiles lorsqu’on souhaite offrir une certaine souplesse d’affichage sans exposer l’utilisateur à du code HTML ou PHP. Voici un exemple simple de shortcode que vous pouvez ajouter dans votre fichier functions.php
:
function mon_shortcode() {
return '<p>Ce contenu est inséré via un shortcode.</p>';
}
add_shortcode( 'contenu_special', 'mon_shortcode' );
Une fois ce code ajouté, vous pouvez insérer le shortcode suivant dans l’éditeur de WordPress :
[contenu_special]
Ce shortcode générera à l’écran un paragraphe HTML contenant le texte défini dans la fonction. C’est une solution idéale pour insérer des blocs de texte récurrents, des mises en forme spécifiques, des encadrés d’information ou encore des éléments HTML complexes comme des boutons, des tableaux ou des balises conditionnelles.
Voici quelques cas d’usage concrets :
- Ajouter une signature personnalisée à la fin de chaque article ;
- Insérer des mentions légales, des encarts RGPD ou des appels à l’action dans plusieurs pages ;
- Afficher un élément graphique (ex. : icône, bouton, encadré) sans répéter le code HTML.
Bien entendu, vous pouvez enrichir ce shortcode pour le rendre dynamique. Par exemple, accepter des attributs personnalisés :
function mon_shortcode_dynamique( $atts ) {
$atts = shortcode_atts( array(
'texte' => 'Contenu par défaut',
), $atts, 'contenu_special' );
return '<p>' . esc_html( $atts['texte'] ) . '</p>';
}
add_shortcode( 'contenu_special', 'mon_shortcode_dynamique' );
Et l’utiliser comme ceci dans un article :
[contenu_special texte="Texte personnalisé pour cette page"]
Avec cette approche, vous créez un système de contenu modulaire, simple à utiliser, qui peut évoluer sans modifier le contenu des articles : il suffit de changer la logique dans la fonction, et tous les shortcodes déjà insérés seront mis à jour automatiquement.
9. Activer l’upload de fichiers SVG sur WordPress
Par défaut, WordPress ne permet pas l’envoi de fichiers SVG (Scalable Vector Graphics) dans la médiathèque. Si vous essayez de téléverser une image au format .svg, vous obtiendrez un message d’erreur du type :
Désolé, ce type de fichier n’est pas autorisé pour des raisons de sécurité.
Ce blocage est volontaire : les fichiers SVG sont en réalité des fichiers texte (XML) pouvant contenir non seulement des balises vectorielles (comme <path>
, <circle>
, etc.), mais aussi du JavaScript embarqué. Cela les rend potentiellement dangereux s’ils sont malveillants, car ils pourraient permettre une injection de code dans l’interface ou sur le site public. Cela dit, le format SVG est extrêmement utile, notamment pour :
- Afficher des logos ou des pictogrammes nets sur tous les écrans, y compris en haute résolution (retina) ;
- Réduire la taille des images vectorielles comparées à leurs équivalents PNG ou JPG ;
- Appliquer du style via CSS ou même interagir avec des scripts JS pour des animations SVG « sur votre logo génial« .
Voici comment autoriser l’envoi de fichiers SVG dans la médiathèque WordPress :
function allow_svg_upload( $mimes ) {
$mimes['svg'] = 'image/svg+xml';
return $mimes;
}
add_filter( 'upload_mimes', 'allow_svg_upload' );
Ce snippet ajoute le type MIME image/svg+xml
à la liste des formats autorisés par le filtre upload_mimes
. Une fois en place, vous pourrez téléverser vos fichiers SVG directement depuis l’interface de gestion des médias. Rappelons ici que autoriser le SVG signifie aussi ouvrir la porte à l’upload de code XML libre. Or, ce fichier peut contenir des scripts potentiellement dangereux, comme :
<script>alert('SVG malveillant')</script>
C’est pourquoi il est utile de :
- Uploader uniquement des fichiers SVG provenant de sources fiables ;
- Scanner et nettoyer vos SVG si vous les créez avec des outils comme Illustrator, Figma ou Inkscape ;
- Éviter d’autoriser les utilisateurs non techniques à téléverser des SVG.
Option de sécurité renforcée : Pour aller plus loin, vous pouvez filtrer le contenu SVG ou utiliser un plugin comme Safe SVG qui ajoute un mécanisme de validation du XML et désactive les scripts intégrés. Enfin, si vous intégrez des SVG directement dans votre code HTML (par exemple via <svg>...</svg>
), cela reste souvent plus performant et plus contrôlable qu’un SVG téléversé via la médiathèque — à condition de maîtriser le code.
10. Nettoyer la balise head de WordPress
On le sait (et c’est souvent un élément de grief pour le CMS), WordPress injecte automatiquement de nombreuses balises dans la section <head>
de votre site, même si vous ne les utilisez pas. Ces balises sont censées offrir une meilleure compatibilité avec certains services ou éditeurs externes, mais dans la majorité des cas, elles sont inutiles, voire contre-productives.
Voici quelques exemples de balises que WordPress ajoute automatiquement :
<link rel="EditURI" ...>
– utilisé par l’éditeur XML-RPC (RSD) ;<meta name="generator" content="WordPress 6.x.x" />
– indique la version exacte de WordPress ;<link rel="wlwmanifest" ...>
– support de Windows Live Writer (logiciel obsolète) ;<link rel="https://api.w.org/" ...>
– expose l’API REST de WordPress ;<link rel="shortlink" ...>
– ajoute une version courte de l’URL de l’article.
Ces éléments peuvent :
- Allonger inutilement le code HTML généré ;
- Révéler des informations techniques sensibles (comme la version exacte de WordPress) ;
- Être inutiles dans un contexte moderne (par exemple, personne n’utilise encore Windows Live Writer) ;
- Être indésirables dans des thèmes optimisés pour la performance ou le SEO.
Voici un extrait de code à ajouter dans le fichier functions.php
pour nettoyer le <head>
de WordPress :
remove_action( 'wp_head', 'rsd_link' ); // Supprime le lien vers RSD (Remote Site Discovery)
remove_action( 'wp_head', 'wp_generator' ); // Supprime la version WordPress
remove_action( 'wp_head', 'wlwmanifest_link' ); // Supprime le manifeste WLW
remove_action( 'wp_head', 'rest_output_link_wp_head' ); // Supprime le lien vers l’API REST
remove_action( 'wp_head', 'wp_shortlink_wp_head' ); // Supprime le shortlink
Ces fonctions remove_action()
désactivent proprement les actions qui injectent ces éléments HTML dans le code source. Elles n’ont aucun impact fonctionnel sur votre site si vous n’utilisez pas activement ces fonctionnalités.
En pratique, on peut dire que cela permet de :
- Disposer d’un code HTML plus propre et plus lisible ;
- Une meilleure maîtrise de ce que voit l’utilisateur ou les robots d’indexation ;
- Un léger gain de performance (moins de traitement côté serveur et navigateur) ;
- Une meilleure protection contre les attaques automatiques ciblant une version précise de WordPress.
Si vous souhaitez aller encore plus loin, vous pouvez également supprimer les liens de type feed
, les emojis, les scripts inutiles (comme déjà vu dans les snippets précédents), ou encore les DNS prefetchs.
remove_action( 'wp_head', 'feed_links', 2 );
remove_action( 'wp_head', 'feed_links_extra', 3 );
En nettoyant la balise <head>
, vous reprenez le contrôle total sur ce que WordPress affiche automatiquement, ce qui est particulièrement utile pour des projets sur mesure, des thèmes allégés ou des sites optimisés SEO/performances.
A vous de jouer 🙂
0 commentaires