Sur un site web WordPress partagé entre plusieurs profils (clients, rédacteurs, admins techniques), afficher toute la liste des plugins n’est pas toujours une bonne idée. Entre les extensions sensibles de sécurité, les modules maison un peu « bricolés » et les outils que l’on préfère garder discrets, il existe de vraies raisons de vouloir masquer certains plugins sans les désactiver. Ce tutoriel montre comment le faire proprement en PHP, côté code, sans tout confier à un énième plugin de gestion.
L’idée n’est pas de jouer au magicien qui cache tout, mais de reprendre le contrôle sur la gestion plugins dans WordPress. D’abord en filtrant la liste dans l’admin, puis en limitant l’accès à certains rôles utilisateurs, et enfin en évitant que des extensions critiques ne disparaissent lors d’un ménage un peu trop enthousiaste. En pratique, quelques hooks bien placés dans le functions.php d’un thème enfant suffisent à rendre l’interface beaucoup plus propre pour les utilisateurs finaux, tout en gardant les fonctionnalités intactes.
En bref
- Utiliser les hooks all_plugins et pre_update_option_active_plugins pour cacher des extensions sans les désactiver.
- Placer le code PHP dans un thème enfant ou un petit mu-plugin pour éviter qu’il ne saute à la prochaine mise à jour.
- Adapter le filtrage en fonction du rôle utilisateur afin de garder une vision complète pour les vrais admins.
- Protéger des plugins critiques (sécurité, backup, passerelles de paiement) contre les désactivations accidentelles.
- Tester sur un environnement de préproduction avant d’appliquer ces changements sur un site web en production.
Tuto PHP pour masquer des plugins WordPress sans les désactiver
La base de ce tutoriel repose sur un comportement simple de WordPress : la page « Extensions installées » s’appuie sur un tableau PHP qui contient la liste de toutes les extensions. En interceptant ce tableau au bon moment, il devient possible de masquer des éléments à l’écran tout en laissant le cœur de WordPress les considérer comme actifs.
Concrètement, la logique consiste à cibler quelques slugs de plugins dans un tableau, puis à les retirer de la liste affichée. L’extension reste chargée en mémoire, ses hooks continuent de tourner, mais les utilisateurs autorisés seulement sauront qu’elle existe. C’est particulièrement utile lorsqu’un client gère lui-même son site web, mais qu’il vaut mieux l’empêcher de jouer avec Wordfence, un connecteur de paiement ou un plugin d’API métier.
Filtrer la liste des plugins avec le hook all_plugins
Le premier outil à maîtriser, c’est le filtre all_plugins. Ce hook reçoit un tableau associatif dont les clés sont les chemins des plugins (par exemple hello-dolly/hello.php) et les valeurs des sous-tableaux de métadonnées. En retirant certaines clés de ce tableau, l’interface admin ne les affichera tout simplement plus.
Un exemple typique pourrait ressembler à ceci dans le fichier functions.php de votre thème enfant :
Exemple de code PHP pour masquer un ou plusieurs plugins
add_filter( 'all_plugins', 'tutoit_masquer_plugins_liste' );
function tutoit_masquer_plugins_liste( $plugins ) {
// Slugs de plugins à masquer dans l’admin
$plugins_a_cacher = array(
'hello-dolly/hello.php',
'akismet/akismet.php',
);
// Optionnel : ne rien cacher pour les super admins
if ( current_user_can( ‘manage_network_plugins’ ) || current_user_can( ‘manage_options’ ) ) {
return $plugins;
}
foreach ( $plugins_a_cacher as $slug ) {
if ( isset( $plugins[ $slug ] ) ) {
unset( $plugins[ $slug ] );
}
}
return $plugins;
}
Le tableau $plugins_a_cacher peut être alimenté de manière dynamique (option en base, constantes d’environnement, etc.), mais ce format statique suffit déjà pour séparer ce qui doit rester visible de ce qui relève de la cuisine interne. Le contrôle via current_user_can évite par ailleurs de se tirer une balle dans le pied et de masquer des extensions à l’admin principal.
Adapter le masquage selon le rôle utilisateur ou une URL de debug
Le cas récurrent en agence, c’est Paul, le client qui se connecte avec un rôle administrateur, mais qui ne devrait pas avoir la main sur tout. Dans ce contexte, il devient intéressant de moduler la liste de plugins affichés en fonction du rôle ou même d’un paramètre d’URL réservé aux techniciens.
Une approche assez souple consiste à introduire une variable de contrôle, un peu comme un mode debug : si une URL contient un paramètre du type ?show_all_plugins=1 et que l’utilisateur a les droits suffisants, alors aucun plugin n’est masqué. Sinon, le filtre habituel s’applique. Cela permet de faire des audits rapides côté client sans modifier le code à chaque fois.
Préparer un environnement propre pour ce tutoriel PHP WordPress
Avant de jouer avec la liste des plugins, mieux vaut vérifier que le terrain est propre. Un crochet mal placé sur un site critique peut transformer une simple expérimentation en panne fonctionnelle. D’où l’intérêt d’un homelab, d’un staging ou au moins d’un clone local sous Docker ou Local WP.
Une règle qui revient souvent chez les techniciens expérimentés : ce qui touche au cœur de la gestion plugins doit d’abord passer par un environnement de test. Le but est de s’assurer que le filtrage n’interfère pas avec des outils de déploiement, des scanners de sécurité ou des mises à jour automatiques.
Où placer le code pour masquer les extensions sans les désactiver
Beaucoup de débutants collent ce genre de code dans le functions.php du thème actif. Ça fonctionne, mais ce n’est pas toujours le meilleur choix à long terme. Un changement de thème, et tout le mécanisme disparaît d’un coup, laissant à nouveau tout visible. Pour un contrôle durable, deux options sortent du lot.
La première consiste à utiliser un thème enfant dédié, dont le functions.php contient toutes les surcharges techniques, y compris ce tutoriel PHP. La seconde, plus propre, est d’utiliser un mu-plugin (must-use plugin) qui s’exécute quoi qu’il arrive, indépendamment des thèmes installés. Dans les environnements avec plusieurs intervenants, c’est clairement ce second choix qui tient mieux la route.
Tableau récapitulatif des emplacements possibles pour le code
Pour comparer rapidement les options, voici un aperçu des points clés pour chaque emplacement envisageable :
| Emplacement du code | Persistance au changement de thème | Niveau de maintenance | Contexte recommandé |
|---|---|---|---|
| functions.php du thème principal | Faible | Correct si un seul thème | Petit site vitrine, peu d’intervenants |
| functions.php d’un thème enfant | Moyenne | Gérable | Sites personnalisés, évolution graphique prévue |
| Mu-plugin (/wp-content/mu-plugins) | Élevée | Plus technique | Sites critiques, multi-admins, environnements pro |
Une fois ce choix fait, toute la mécanique de masquage repose sur les mêmes hooks. Seul l’endroit où l’on pose le code change, pas sa logique.
Empêcher la désactivation de plugins sensibles en complément du masquage
Masquer une extension dans la liste, c’est bien. Empêcher qu’elle soit désactivée par erreur, c’est encore mieux. WordPress stocke les extensions actives dans l’option active_plugins, sous la forme d’un tableau sérialisé. En filtrant avant la mise à jour de cette option, on peut forcer la présence de certaines entrées coûte que coûte.
Ce mécanisme protège des plugins clés : passerelles bancaires, sécurité, backups, intégrations métiers. Quand un utilisateur clique sur « Désactiver », WordPress tente de retirer leur slug de la liste, mais le filtre le remet dans le tableau au moment de l’enregistrement. Le bouton tombe donc à plat, du point de vue fonctionnel.
Exemple de code PHP pour verrouiller certains plugins actifs
Un snippet typique, toujours dans un thème enfant ou un mu-plugin, peut ressembler à ceci :
add_filter( 'pre_update_option_active_plugins', 'tutoit_verrouiller_plugins_actifs', 10, 2 );
function tutoit_verrouiller_plugins_actifs( $new_value, $old_value ) {
$plugins_proteges = array(
'wordfence/wordfence.php',
'updraftplus/updraftplus.php',
);
if ( ! is_array( $new_value ) ) {
$new_value = array();
}
foreach ( $plugins_proteges as $slug ) {
if ( ! in_array( $slug, $new_value, true ) ) {
$new_value[] = $slug;
}
}
return $new_value;
}
Ici, la fonctionnalité activée par ces plugins reste disponible même si quelqu’un tente de les couper depuis l’interface. Couplée au filtrage de la liste, cette astuce rend la gestion beaucoup plus robuste sur des sites WordPress exposés à plusieurs mains.
Scénario concret : une plateforme de commande en ligne pour des clients
Imaginez une plateforme de commandes en ligne pour plusieurs restaurants, basée sur WordPress et quelques plugins WooCommerce, un système de livraison, plus des extensions maison. Les gérants doivent pouvoir gérer les produits, les commandes, parfois les utilisateurs, mais en aucun cas les briques qui assurent le paiement ou la sécurité.
Dans ce contexte, le combo « masquer dans la liste » + « empêcher la désactivation » fait toute la différence. Le client garde la sensation d’un back-office simple, centré sur son métier. L’équipe technique garde le contrôle sur ce qui ne doit jamais sauter, sans passer son temps à réparer des plantages liés à des clics malheureux.
Aller plus loin que le simple masquage : rôles, menus et sécurité globale
Une fois la liste des plugins nettoyée, la suite logique consiste à adapter le reste de l’interface. Cacher une extension tout en laissant le menu correspondant accessible à tous n’a pas beaucoup de sens. L’objectif, c’est une cohérence globale : seulement les outils nécessaires pour chaque profil utilisateur, rien de plus.
Quelques plugins d’interface comme « Hide Admin Menu » permettent déjà de masquer certains items à des rôles choisis. Mais pour un contrôle vraiment fin, le même type d’approche en PHP est possible, via les hooks WordPress classiques, pour filtrer menus, barres d’admin, voire certains écrans selon le contexte.
Techniques complémentaires pour sécuriser un site WordPress
On croise encore souvent des sites qui misent tout sur un plugin de sécurité en espérant que ça suffise. En réalité, le masquage et la gestion plugins ne représentent qu’un étage du dispositif. D’autres couches restent indispensables pour que l’ensemble tienne le choc.
- Mises à jour régulières de WordPress, thèmes et extensions, de préférence automatisées mais contrôlées.
- Mise en place d’un WAF côté hébergeur ou via un service type Cloudflare pour filtrer une partie du trafic avant qu’il n’arrive au serveur.
- Stratégie de sauvegardes hors du serveur principal, avec restauration testée et documentée.
- Segmentation claire des rôles utilisateurs, avec des droits limités à ce qui est réellement nécessaire.
- Audit périodique des extensions installées pour vérifier celles qui sont encore maintenues et utiles.
Le masquage des plugins vient simplement ajouter une petite couche de friction pour les erreurs humaines et les curieux. Pris isolément, ce n’est pas un bouclier. Inséré dans une stratégie globale, c’est un maillon plutôt pratique.
Masquer un plugin WordPress en PHP change-t-il son fonctionnement sur le site web ?
Non. Le fait de masquer une extension via le filtre all_plugins n’agit que sur l’affichage dans l’interface d’administration. Le plugin reste chargé par WordPress, ses hooks et ses fonctionnalités continuent de tourner tant qu’il est marqué comme actif dans la configuration du site.
Où placer le code PHP pour masquer des plugins sans les désactiver ?
Le plus robuste consiste à placer ce code dans un mu-plugin (dossier wp-content/mu-plugins), ce qui le rend indépendant du thème. Un thème enfant peut aussi convenir, mais en cas de changement de thème, le masquage disparaîtra. Évitez de modifier un thème parent fourni par un éditeur, car une mise à jour écraserait vos ajustements.
Comment retrouver un plugin masqué si j’ai besoin de le désinstaller ?
Il suffit de commenter temporairement le code PHP qui filtre all_plugins ou de retirer le slug concerné du tableau de plugins à cacher. Rechargez ensuite la page Extensions dans l’admin WordPress pour voir réapparaître l’extension, et procédez à la désactivation ou à la suppression si nécessaire.
Est-ce risqué pour le SEO de masquer des plugins WordPress côté administration ?
Non, ces techniques ne modifient pas le contenu public ni la structure des URLs. Les moteurs de recherche n’ont pas accès à la page d’admin et ne voient pas la liste de vos plugins. Le référencement dépend surtout de la qualité des pages, de la performance et de l’architecture de votre site web, pas de la visibilité interne des extensions.
Peut-on combiner ce tutoriel PHP avec un plugin de sécurité WordPress existant ?
Oui, c’est même souvent recommandé. Le code de masquage agit sur la présentation de la liste des plugins et, éventuellement, sur la protection de certains d’entre eux contre la désactivation. Un plugin de sécurité se charge d’autres aspects comme le pare-feu applicatif, la détection d’intrusion ou la limitation des tentatives de connexion. Les deux approches se complètent bien si les tests sont faits proprement en amont.
