Masquer des plugins WordPress sans les désactiver peut sembler un détail cosmétique, mais derrière ce petit bricolage se cache un vrai enjeu de sécurité WordPress et de sérénité pour l’admin. Entre les footprints laissés par les extensions, les clients qui adorent cliquer sur « Désactiver » au hasard, et les curieux qui inspectent le code source pour comprendre ta stack, disposer d’un tutoriel clair pour cacher plugins via du code PHP change vite la donne. L’idée n’est pas de transformer ton site en bunker imprenable, mais de réduire la surface d’attaque et de rendre la vie un peu plus compliquée aux robots et aux opportunistes.
Le point intéressant, c’est qu’il existe deux axes complémentaires. D’un côté, on peut masquer la présence d’un plugin dans l’interface d’admin, histoire d’éviter qu’un utilisateur un peu trop enthousiaste ne sabote la configuration. De l’autre, on peut réduire les traces techniques visibles dans l’arborescence ou dans le navigateur, pour limiter les infos offertes gratuitement à un attaquant. Le tout en restant sur une méthode simple, basée sur du PHP côté thème et quelques règles dans le .htaccess, sans plugin supplémentaire qui deviendrait lui-même une dépendance de plus à surveiller. Au fil des sections qui suivent, tu vas voir comment articuler ces techniques pour une protection plugins propre, pratique et, surtout, adaptée à la réalité d’un site WordPress en production.
En bref
- Objectif principal : masquer extensions WordPress sensibles sans les désactiver, pour gagner en sécurité et en ergonomie dans l’admin.
- Outil clé : un filtre PHP sur all_plugins pour retirer certains plugins de la liste, tout en les gardant actifs.
- Côté sécurité : usage de règles .htaccess pour envoyer des 404 propres sur les fichiers d’extensions que tu veux rendre invisibles.
- Côté pratique : création d’un tableau PHP de plugins à cacher, facile à maintenir et à faire évoluer au fil du temps.
- Limites à connaître : impossible de rendre totalement invisible un plugin qui sert des CSS/JS publics sans adapter son chemin ou son code.
Cacher des plugins WordPress en PHP : à quoi ça sert vraiment en termes de sécurité et d’ergonomie
Derrière la question « comment cacher plugins dans WordPress ? » se cache souvent une inquiétude très concrète : comment empêcher un visiteur mal intentionné ou un bot de scanner ton site à la recherche de failles connues dans des extensions populaires. Chaque plugin actif ajoute du code, des fichiers, parfois des endpoints, et parfois aussi une page readme ou un commentaire HTML qui trahit son nom et sa version. Pour un attaquant, ce sont autant d’indices pour cibler une vulnérabilité précise plutôt que de tirer dans le vide.
Les fameux footprints des plugins, ce sont toutes ces traces visibles ou déductibles : un lien en pied de page « powered by… », un commentaire dans le HTML, un dossier accessible dans wp-content/plugins, un fichier readme.txt ou readme.html bavard sur la version exacte. Même si tu as déjà nettoyé la balise generator de WordPress, les fichiers de la distribution d’origine continuent parfois de révéler beaucoup de choses à qui sait regarder. Et un simple scan automatisé peut parcourir ces chemins standards en quelques secondes.
Il y a aussi un deuxième enjeu, souvent sous-estimé : garder ses petits secrets. Certains sites tournent avec un plugin maison, une extension peu connue ou un outil de génération de contenu qui donne un avantage concurrentiel. Laisser ces éléments visibles dans le code source ou dans la structure des URL, c’est presque offrir le plan de ton système à quiconque prend le temps de fouiller. Pour un site orienté SEO, par exemple, afficher clairement le nom d’un plugin d’automatisation ou d’agrégation, c’est se tirer une balle dans le pied.
Pour les freelances et agences, le problème se déplace souvent côté back-office. Un client qui a les droits d’admin adore tester. Il active, désactive, supprime des plugins, parfois sans mesurer les conséquences sur la sécurité WordPress, les perfs ou la cohérence du design. Un système de protection plugins basé sur le masquage dans l’admin permet de garder le contrôle tout en lui laissant suffisamment de liberté pour gérer le contenu, les médias, les utilisateurs. L’interface reste lisible, moins intimidante, et surtout moins propice aux mauvaises manipulations.
L’objectif n’est pas de cacher absolument tout. Au contraire, un site où plus aucun plugin ne laisse la moindre trace peut paraître suspect si un audit de sécurité approfondi est effectué. Le but est plutôt de réduire les signaux inutiles : retirer de la vue ce qui n’a aucune raison d’être visible, limiter les informations techniques offertes sans justification, et garder la possibilité de diagnostiquer et maintenir proprement l’instance. En résumé, cacher des plugins avec du PHP et quelques règles de réécriture, c’est d’abord une stratégie de sobriété : montrer uniquement ce qui sert le fonctionnement du site, et rien de plus.
Dans cette optique, une bonne méthode simple doit répondre à deux contraintes. Première contrainte : ne pas casser la chaîne de mises à jour WordPress. Si tu dois rééditer trois fichiers de plugin à chaque upgrade, tu ne tiendras pas la distance. Deuxième contrainte : rester compréhensible pour le prochain développeur qui passera derrière toi. Un snippet clair dans le functions.php d’un thème enfant, commenté proprement, vaut mieux qu’une usine à gaz dispersée dans plusieurs mu-plugins. L’étape suivante consiste justement à voir comment brancher ce code PHP sur les bons hooks.
Masquer des extensions dans la liste WordPress avec un filtre PHP sur all_plugins
La première brique consiste à nettoyer la vue dans l’admin. L’idée est simple : utiliser un hook fourni par WordPress pour filtrer la liste renvoyée par le cœur, puis retirer les éléments que tu ne veux plus afficher. Tu n’as pas besoin de modifier un seul fichier dans le dossier du plugin, tout se passe dans ton thème, ce qui reste compatible avec les mises à jour automatiques et manuelles.
WordPress propose le filtre all_plugins, qui reçoit un tableau contenant les plugins détectés dans wp-content/plugins. Chaque entrée du tableau est indexée par un chemin du type nom-du-plugin/nom-du-fichier-principal.php. Tant que tu connais ce chemin, tu peux supprimer la ligne correspondante du tableau et l’extension disparaît visuellement de la page « Extensions installées », sans être désactivée pour autant.
Le squelette du tutoriel tient en quelques lignes de code PHP à placer dans le fichier functions.php de ton thème enfant :
Exemple minimal de filtre all_plugins
Tu peux t’inspirer de cette structure, à adapter avec tes propres chemins :
add_filter( 'all_plugins', 'custom_hide_plugin_entries' );
function custom_hide_plugin_entries( $listePlugins ) {
$hiddenPlugins = array(
'akismet/akismet.php',
'module-n2/index.php'
);
foreach ( $hiddenPlugins as $filenameToHide ) {
if ( isset( $listePlugins[ $filenameToHide ] ) ) {
unset( $listePlugins[ $filenameToHide ] );
}
}
return $listePlugins;
}
Ce bloc ne touche pas aux plugins eux-mêmes. Ils restent présents sur le disque, activés, et leur code continue d’être chargé par WordPress comme avant. Seule la représentation dans l’interface change. Autrement dit, c’est une forme de cloisonnement visuel qui empêche un utilisateur autorisé, mais pas forcément à l’aise, de tout casser « pour voir ». Sur un projet client, cette approche réduit déjà beaucoup de tickets de support inutiles.
Reste la question : comment trouver le bon chemin à mettre dans le tableau $hiddenPlugins sans aller farfouiller sur le FTP. Il existe une astuce directement depuis l’admin. Dans le menu Extensions, clique sur « Éditeur d’extension ». Par défaut, WordPress charge automatiquement la première extension de la liste avec une mention en haut du type « Modification de akismet/akismet.php ». C’est précisément cette chaîne qu’il faut recopier dans le tableau, guillemets compris.
Pour chaque plugin à masquer, il suffit de le sélectionner dans la liste déroulante de l’éditeur, d’attendre que la page se recharge, puis de relever le chemin affiché. En procédant ainsi, tu construis progressivement ton tableau, sans quitter l’interface d’admin. C’est une manière assez pratique de garder la main même quand tu n’as pas un accès direct au serveur, par exemple sur un hébergement mutualisé géré par un prestataire.
Certains développeurs aiment garder une porte dérobée pour afficher tous les plugins malgré tout, par exemple pour un audit ponctuel. Une solution simple consiste à prévoir un paramètre dans l’URL, du type ?showall=1. Dans ce cas, ta fonction renvoie la liste d’origine sans filtrage. Ajoute simplement un test en début de fonction :
if ( isset( $_GET['showall'] ) && $_GET['showall'] == '1' ) {
return $listePlugins;
}
Avec cette condition, tu gardes un mode « vue complète » activable uniquement par quelqu’un qui connaît le paramètre. Est-ce inviolable ? Non. Est-ce suffisant pour éviter que ton client tombe dessus par hasard en cliquant dans l’admin ? Clairement. Pour beaucoup de contextes, ce niveau de discrétion correspond déjà à ce qu’on attend d’une méthode simple pour masquer extensions sensibles dans WordPress.
Une fois que ce filtre tourne correctement, tu peux pousser un peu plus loin la logique et, par exemple, connecter cette technique à une organisation globale de ton projet décrite sur d’autres ressources de type architecture. L’article sur l’architecture front et back sur Musee Informatique donne justement un cadre intéressant pour réfléchir à la place de chaque plugin dans ton écosystème applicatif.
Rendre des plugins invisibles côté fichiers avec .htaccess et 404 propres
Une fois les plugins dissimulés dans l’interface, reste la partie plus subtile : les traces visibles côté fichiers. Même si ton client ne voit plus certaines extensions dans l’admin, un robot peut encore très bien tester des chemins du genre /wp-content/plugins/akismet/ ou /wp-content/plugins/mon-plugin-secret/readme.txt. Si le dossier existe et que les fichiers répondent avec un code 200, l’info est déjà trop bavarde pour quelqu’un qui prépare une attaque ciblée.
La première réaction logique consiste à désactiver le listing de répertoire, par exemple via une directive sur le serveur ou en posant un index.php vide dans chaque dossier de plugin. Cela empêche l’affichage brut de la liste de fichiers. Le problème, c’est que ce genre de précaution n’empêche pas un attaquant de faire des requêtes directes sur des chemins connus. Si readme.txt répond toujours, la présence de l’extension est confirmée en un coup d’œil.
Une autre piste souvent montrée consiste à filtrer ce qui sort de wp-content avec des règles de type :
Order deny,allow
Deny from all
<Files ~ ".(xml|css|jpe?g|png|gif|js)$">
Allow from all
</Files>
Ce genre de configuration laisse passer les ressources statiques (CSS, images, JS) et bloque le reste. Sur le papier, ça limite déjà la surface d’attaque. Dans la pratique, ça envoie un code d’erreur différent selon le type de fichier, et un scanner reçoit malgré tout des signaux sur ce qui est accessible ou non. Autrement dit, tu réduis un peu les dégâts, mais tu n’effaces pas réellement la présence des plugins sensibles.
Une approche plus maligne repose sur la réécriture d’URL : au lieu de laisser le serveur répondre directement, on redirige certaines requêtes vers index.php pour que WordPress génère sa propre page 404. Pour un robot, un dossier de plugin qui renvoie la même 404 que n’importe quel chemin inexistant devient beaucoup plus difficile à distinguer d’un simple faux nom. Tu transformes une 404 « brute » en 404 applicative, qui passe par la logique du CMS.
Le .htaccess par défaut de WordPress contient déjà un bloc du type :
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
En gros, tant que le fichier ou le dossier demandé existe physiquement, Apache sert directement le contenu, sans faire intervenir WordPress. Il faut donc insérer une règle avant ce bloc pour attraper les requêtes visées et les relayer volontairement à index.php. Par exemple :
RewriteRule readme.txt$ /index.php [L]
Avec cette ligne, tous les chemins se terminant par readme.txt sont envoyés dans le routeur de WordPress. Comme l’URL ne correspond à aucune page, ton thème renvoie la 404 standard du site. À l’écran, un readme existant ou inexistant produira la même page d’erreur, ce qui brouille déjà bien les pistes. Tu peux aller plus loin en ciblant un plugin précis :
RewriteRule wp-content/plugins/wordpress-seo /index.php [L]
Cette fois, tout ce qui passe par le dossier wordpress-seo est intercepté, qu’il s’agisse de PHP, CSS ou autre. Côté front, le plugin devient « invisible » : impossible de distinguer son dossier d’un chemin inventé de toutes pièces. Pour le module de sécurité WordPress, cette technique complète bien le filtrage dans l’admin, mais il ne faut pas oublier l’impact sur le fonctionnement de l’extension elle-même.
Dès que tu coupes l’accès direct aux fichiers CSS et JS utilisés par l’admin de certains plugins, l’interface peut se dégrader. Les boutons se déforment, les scripts ne chargent plus, voire certaines pages deviennent inutilisables. Pour les plugins qui n’interviennent que côté back-office, ce problème reste gérable : il suffit de prévoir une exception pour les admins, par exemple à l’aide d’un cookie dédié. C’est ce que tu vas voir dans la section suivante, qui combine intelligemment .htaccess et petites astuces côté connexion.
Combiner 404 WordPress et cookie secret pour garder les plugins utilisables en admin
Le vrai défi, quand on parle de sécurisé et de praticité, c’est de ne pas sacrifier l’expérience de l’administrateur. Un système de protection plugins qui rend l’interface inutilisable n’a aucune chance de rester en place longtemps. La clé consiste à faire en sorte que les règles agressives du .htaccess s’appliquent uniquement aux visiteurs anonymes, tandis que les admins profitent d’un accès complet, y compris aux CSS et JS de leurs extensions chouchoutes.
Une méthode courante repose sur un cookie « secret ». Le principe est assez simple : lors de la connexion à l’admin, on pose un cookie spécifique dans le navigateur de l’utilisateur autorisé. Le .htaccess vérifie la présence de ce cookie avant d’appliquer la règle de masquage. S’il est présent, la condition court-circuite la RewriteRule et le plugin reste visible et fonctionnel. S’il est absent, les requêtes vers le dossier sensible sont envoyées vers index.php et finissent en 404 WordPress.
Dans le .htaccess, une condition typique ressemble à ceci :
RewriteCond %{HTTP_COOKIE} !^.*mon-cookie-secret.*$ [NC]
RewriteRule wp-content/plugins/wordpress-seo /index.php [L]
Tant que le cookie « mon-cookie-secret » n’apparaît pas dans l’en-tête HTTP_COOKIE, la règle s’applique. Pour un visiteur lambda ou un bot, le plugin reste donc maquillé derrière une 404 propre. Pour un admin connecté qui possède ce cookie, les fichiers sont servis normalement et l’interface de configuration reste fluide. L’équilibre entre sécurité WordPress et confort de gestion se joue largement là.
Reste à placer ce cookie. Tu peux le définir en PHP lors d’un événement lié à la connexion admin, par exemple en te branchant sur l’action wp_login. Une fonction compacte dans ton thème enfant peut suffire :
add_action( 'wp_login', 'set_secret_cookie_after_login', 10, 2 );
function set_secret_cookie_after_login( $user_login, $user ) {
setcookie( 'mon-cookie-secret', '1', time() + 3600, COOKIEPATH, COOKIE_DOMAIN, is_ssl(), true );
}
Avec ce genre de bloc, chaque admin qui s’authentifie reçoit le fameux cookie valable pendant une heure. Tu peux ajuster la durée de vie selon ton besoin, mais garde en tête qu’un temps trop long augmente le risque de cookie qui traîne sur un poste partagé. Là encore, l’objectif est de garder une méthode simple, raisonnablement sécurisé, plutôt qu’un tunnel complet d’authentification personnalisé qui deviendrait compliqué à maintenir.
Un point important à garder en tête : tous les plugins ne se prêtent pas à ce type de masquage agressif. Certains servent des fichiers publics indispensables, comme des CSS pour un formulaire de contact ou des scripts JS chargés sur le front. Pour ceux-là, il devient compliqué de bloquer totalement les accès sans modifier leurs chemins ou sans recopier les ressources dans un autre répertoire plus neutre. En gros, plus le plugin se comporte comme une mini-application autonome, plus il faut être prudent avant de jouer avec ses URLs.
C’est là que la stratégie globale entre en jeu. Sur un gros projet, tu peux choisir de ne cacher par .htaccess que quelques plugins très sensibles, par exemple un outil de gestion multisite à distance ou un module de backup. Pour les autres, le simple masquage dans l’admin via le filtre all_plugins suffit déjà à éviter les bêtises tout en gardant un comportement normal côté front. L’idée, encore une fois, n’est pas de tout camoufler, mais de cibler ce qui mérite vraiment une couche de discrétion supplémentaire.
Cette combinaison filtre PHP + cookie + règles de réécriture crée un socle robuste, sans nécessiter de framework externe ni de plugin de sécurité tentaculaire. Tu peux ensuite ajuster au cas par cas, en fonction de la typologie de ton site, de la maturité des personnes qui le gèrent et de l’environnement d’hébergement. Si tu sais déjà orchestrer une stack complète front/back décrite dans des ressources comme celles sur l’architecture web, cette mécanique de masquage s’intègre assez naturellement dans ta façon de construire le projet.
Construire un snippet PHP réutilisable pour masquer une ou toutes les extensions
Revenons côté PHP. Une des grandes forces du filtre all_plugins, c’est sa flexibilité. Avec une seule fonction bien pensée dans ton thème, tu peux soit masquer quelques plugins sensibles, soit retirer toute la liste et ne la rendre visible qu’en cas de besoin. Tout dépend de la manière dont tu alimentes ton tableau $hiddenPlugins et des conditions que tu ajoutes autour.
Pour clarifier les choses, voici un tableau comparatif entre quelques approches possibles de masquage d’extensions :
| Approche | Visuel dans l’admin | Impact sur le front | Niveau de sécurité |
|---|---|---|---|
| Filtre all_plugins ciblé | Masque seulement certains plugins | Aucun, plugins actifs normalement | Moyen (empêche surtout les erreurs humaines) |
| Filtre all_plugins global | Masque tous les plugins de la liste | Aucun impact technique direct | Moyen+ (évite le repérage rapide en interne) |
| .htaccess + 404 WordPress | Aucun effet sur l’admin | Masque les fichiers ciblés, risque sur les CSS/JS | Élevé si bien ciblé |
| Plugins de sécurité généralistes | Interface dédiée | Règles parfois très larges | Variable, dépend du réglage global |
Pour un usage quotidien, la variante la plus confortable reste souvent le filtre ciblé, avec un tableau clair des extensions à masquer. Le code complet ressemble à ceci, en gardant la logique expliquée plus haut :
add_filter( 'all_plugins', 'custom_hide_plugin_entries' );
function custom_hide_plugin_entries( $listePlugins ) {
$hiddenPlugins = array(
'akismet/akismet.php',
'module-n2/index.php'
);
if ( isset( $_GET['showall'] ) && $_GET['showall'] == '1' ) {
return $listePlugins;
}
foreach ( $hiddenPlugins as $filenameToHide ) {
if ( isset( $listePlugins[ $filenameToHide ] ) ) {
unset( $listePlugins[ $filenameToHide ] );
}
}
return $listePlugins;
}
Ce bloc fait trois choses : il définit les plugins à masquer dans un tableau facile à maintenir, il prévoit une issue de secours avec le paramètre showall=1, et il retire proprement les entrées ciblées avant de rendre la liste finale. Sur le long terme, c’est lisible, prévisible et compatible avec la plupart des workflows de mise à jour. Pour un site vitrine ou un blog classique, tu peux vivre longtemps avec ce genre de snippet comme unique brique de masquage.
Certains contextes nécessitent une approche plus radicale, par exemple dans un back-office géré pour des rédacteurs qui n’ont aucune raison de savoir ce qui tourne derrière. Dans ce cas, tu peux tout à fait choisir de masquer tous les plugins de la liste par défaut. Une version ultra concise pourrait simplement brancher une fonction qui renvoie un tableau vide. Une variante un peu plus souple consiste à inclure une whitelist ou un paramètre d’URL pour ne pas te piéger toi-même.
Au passage, cette logique n’empêche pas d’ajouter par la suite un deuxième filtre plus spécialisé pour n’autoriser la vue des plugins qu’à certains rôles, via current_user_can(). C’est une manière élégante de combiner contrôle de rôle et masquage, sans plonger les mains dans la gestion fine des capacités WordPress. Tu restes toujours sur du code PHP que tu maîtrises, sans dépendre d’un plugin tiers parfois trop large pour ton besoin.
Une fois ce socle en place, l’étape suivante consiste souvent à formaliser un petit fichier de snippets réutilisables entre projets. Beaucoup de développeurs WordPress gardent ce genre de fonctions dans un thème « starter » ou un mu-plugin maison. L’important, c’est de documenter clairement l’usage de chaque bloc : conditions, limites, impact sur la maintenance. Un masquage mal compris peut faire perdre un temps fou à quelqu’un qui cherche un plugin « disparu » dans l’admin sans savoir qu’il est simplement filtré.
Erreurs fréquentes et bonnes pratiques pour un masquage de plugins réellement sécurisé
Dès qu’on touche à la sécurité WordPress, les fausses bonnes idées ne manquent pas. Cacher des plugins uniquement pour le style, sans penser au reste de la configuration, ne changera pas grand-chose au risque réel. À l’inverse, durcir agressivement le .htaccess sans tester l’impact sur les CSS/JS peut casser une interface au pire moment, par exemple pendant une campagne marketing où le site doit encaisser du trafic.
Un piège courant consiste à croire qu’un simple renommage de dossier de plugin suffit. Modifier « contact-form-7 » en « cf7-projet-x » donnera peut-être une impression de discrétion, mais la structure interne du plugin, ses scripts, ses shortcodes restent facilement identifiables. Et surtout, tu t’éloignes des chemins attendus par le système de mise à jour, ce qui peut bloquer ou compliquer les upgrades. Du point de vue maintenance, ce genre de bricolage finit souvent par coûter cher.
Autre erreur fréquente : cumuler un filtre all_plugins très large avec un plugin de gestion des rôles mal configuré. Tu te retrouves avec une situation où certains plugins sont visibles pour des rôles « Editor » mais pas pour « Administrator » ou l’inverse, selon l’ordre des filtres. Résultat, plus personne ne comprend qui voit quoi et pourquoi. Le conseil simple : commencer par un seul mécanisme de masquage, puis ajouter éventuellement une couche de rôle en ayant bien vérifié qui a réellement besoin de voir la liste complète.
Pour rester dans le concret, voici une petite liste de réflexes utiles quand tu mets en place ce type de tutoriel sur un projet :
- Tester systématiquement le back-office avec un compte admin « réel », dans un autre navigateur ou une fenêtre privée, après chaque changement de .htaccess.
- Documenter quelque part (dans le repo ou l’outil de suivi) la liste des plugins masqués et la logique utilisée pour le faire.
- Prévoir une URL d’urgence avec ?showall=1 ou une condition similaire pour retrouver la vue complète en cas de doute.
- Vérifier les logs d’erreurs serveur après l’ajout de règles .htaccess, surtout si l’hébergement applique déjà ses propres filtres.
Une fois ces bases posées, le masquage de plugins devient un outil parmi d’autres dans ta boîte à outils de durcissement. Il complète le travail sur les droits de fichier, la désactivation de l’édition de thème dans l’admin, le durcissement des mots de passe ou l’activation de l’authentification à deux facteurs. Pris isolément, il ne suffit pas à protéger un site mal entretenu, mais intégré dans un ensemble cohérent, il te permet d’éviter une catégorie complète de problèmes, à la fois humains et techniques.
Au fond, la maxime « pour vivre heureux, vivons cachés » s’applique plutôt bien au cas des plugins WordPress. Moins tu en révèles sur ta stack exacte, plus tu compliques le travail d’un attaquant qui cherche à exploiter une faille connue. Tant que ce jeu de discrétion ne se fait pas au détriment de la maintenabilité du projet ni de la compréhension par l’équipe, tu restes du bon côté du compromis entre sécurité, performance et lisibilité.
Est-ce que cacher un plugin WordPress suffit à le sécuriser ?
Non. Cacher un plugin réduit la quantité d’informations visibles par un attaquant, mais ne corrige pas les failles éventuelles de l’extension. Les mises à jour régulières, la suppression des plugins inutilisés et une configuration serveur propre restent indispensables. Le masquage joue surtout un rôle de réduction de surface d’attaque et de prévention des erreurs humaines dans l’admin.
Où placer le code PHP pour masquer des extensions dans WordPress ?
Le plus simple est d’ajouter le snippet basé sur le filtre all_plugins dans le fichier functions.php d’un thème enfant actif. Tu peux aussi créer un petit plugin personnalisé si tu préfères séparer clairement la logique métier et la présentation. Dans tous les cas, évite de modifier directement un thème parent ou un plugin tiers, sinon tes changements seront écrasés à la prochaine mise à jour.
Peut-on cacher tous les plugins de la liste des extensions ?
Oui, techniquement tu peux renvoyer un tableau vide dans le filtre all_plugins ou filtrer l’ensemble de la liste. Cela masque tout aux yeux des utilisateurs, mais il devient plus compliqué de dépanner un site en urgence si la personne qui intervient ne connaît pas ce mécanisme. Si tu fais ce choix, prévois au minimum un paramètre d’URL ou un rôle spécifique qui permet de réactiver l’affichage complet temporairement.
Les règles .htaccess pour masquer des plugins fonctionnent-elles avec tous les hébergements ?
Elles fonctionnent tant que ton site tourne derrière Apache ou un serveur compatible avec mod_rewrite. Sur certaines plateformes modernes qui utilisent Nginx ou un proxy, la configuration doit être adaptée côté serveur et tu n’auras pas toujours la main. Dans ce cas, concentre-toi d’abord sur le masquage dans l’admin via PHP, puis discute avec l’hébergeur si tu veux aller plus loin côté réécriture d’URL.
Comment vérifier que le masquage de plugin n’a rien cassé ?
Teste systématiquement le front du site en navigation anonyme, puis le back-office avec un compte admin après chaque modification. Inspecte la console du navigateur pour détecter des erreurs de chargement de CSS ou JS, et consulte les logs serveur si tu suspectes un problème de réécriture d’URL. Si tout fonctionne et que les plugins ciblés ne s’affichent plus dans la liste ou dans les chemins directs, ton masquage est en place.
