Comment désactiver le CSS/JS d'un module sans le désinstaller

Le problème : vous avez besoin du module, mais pas de ses ressources sur chaque page

Il existe de nombreuses situations où vous souhaitez garder un module PrestaShop installé et actif mais l'empêcher de charger ses fichiers CSS ou JavaScript sur des pages spécifiques, voire sur toutes les pages. Peut-être avez-vous un module dont vous avez besoin des fonctionnalités mais dont le style entre en conflit avec votre thème. Peut-être qu'un module charge une bibliothèque JavaScript lourde que vous avez déjà incluse via votre thème. Peut-être souhaitez-vous remplacer les styles par défaut d'un module par votre propre CSS personnalisé sans que les styles d'origine interfèrent. Ou peut-être avez-vous identifié lors d'un audit de performance qu'un module charge des ressources sur des pages où il n'a aucune sortie visible, et vous souhaitez éliminer ce gaspillage.

Désinstaller le module n'est pas une option car vous avez besoin de ses fonctionnalités de base : ses hooks, ses tables de base de données, sa configuration, ses fonctionnalités de back office. Vous devez simplement supprimer chirurgicalement des fichiers CSS ou JavaScript spécifiques de la sortie du front office. PrestaShop fournit plusieurs mécanismes pour y parvenir, et cet article les couvre tous en détail, du plus simple au plus puissant.

Méthode 1 : Utiliser Theme.yml pour supprimer les ressources des modules

La manière la plus simple et la plus maintenable de supprimer le CSS ou le JavaScript d'un module dans PrestaShop 1.7 et versions ultérieures est via le fichier de configuration du thème, theme.yml. Ce fichier, situé à la racine du répertoire de votre thème, contrôle quelles ressources le thème charge et quelles ressources de modules il supprime.

Ouvrez votre fichier theme.yml et recherchez la section assets. Si elle n'existe pas, vous pouvez la créer. Dans la section assets, vous pouvez spécifier les fichiers CSS et JavaScript à supprimer par leur identifiant de ressource (asset ID). Chaque ressource enregistrée via registerStylesheet ou registerJavascript possède un identifiant, qui est généralement le nom du module suivi d'un suffixe descriptif.

Pour trouver les identifiants de ressources utilisés par un module, inspectez le code source de votre page et recherchez les balises link de feuilles de style et les éléments de ressources. PrestaShop ajoute un attribut id à ces éléments en mode debug, ou vous pouvez trouver les identifiants dans le code source du module là où il appelle registerStylesheet ou registerJavascript.

Dans votre fichier theme.yml, ajoutez une section sous assets, puis css, puis all. Ajoutez une entrée avec l'identifiant de la ressource et réglez-la sur false. Par exemple, si un module enregistre une feuille de style avec l'identifiant modulename-style, vous ajouteriez modulename-style avec la valeur false sous la section css all. Faites de même pour les fichiers JavaScript sous la section js all.

Après avoir modifié theme.yml, vous devez vider le cache PrestaShop depuis Paramètres avancés, Performance. Les modifications de theme.yml prennent effet après la reconstruction du cache. Cette approche persiste à travers les mises à jour des modules car la suppression est définie dans votre thème, pas dans le module lui-même. Cependant, elle supprime les ressources de toutes les pages. Si vous avez besoin des ressources sur certaines pages mais pas d'autres, vous aurez besoin d'une approche plus ciblée.

Méthode 2 : Media::unregisterStylesheet et Media::unregisterJavascript

PrestaShop 1.7 a introduit les méthodes de la classe Media unregisterStylesheet et unregisterJavascript, qui vous permettent de supprimer programmatiquement des ressources spécifiques enregistrées par d'autres modules. Ces méthodes sont puissantes car vous pouvez les appeler conditionnellement, supprimant des ressources uniquement sur des pages spécifiques tout en les conservant sur d'autres.

Pour utiliser cette approche, vous avez besoin d'un module personnalisé ou d'une modification d'un module existant. Dans la méthode hookActionFrontControllerSetMedia de votre module, appelez Media::unregisterStylesheet avec l'identifiant de la ressource du fichier CSS que vous souhaitez supprimer. De même, appelez Media::unregisterJavascript avec l'identifiant du fichier JavaScript. Vous pouvez encadrer ces appels d'une logique conditionnelle pour ne supprimer les ressources que sur des types de pages spécifiques.

Par exemple, si vous souhaitez supprimer les ressources d'un module de diaporama de toutes les pages sauf la page d'accueil, vous vérifieriez si le contrôleur actuel est IndexController. Si ce n'est pas la page d'accueil, vous appelez les méthodes de désenregistrement. Si c'est la page d'accueil, vous ne faites rien et laissez les ressources se charger normalement.

La considération clé avec cette approche est l'ordre d'exécution des hooks. La méthode hookActionFrontControllerSetMedia de votre module doit s'exécuter après le module dont vous voulez supprimer les ressources. PrestaShop exécute les callbacks de hooks dans l'ordre d'enregistrement des modules sur le hook, que vous pouvez contrôler via la page Apparence, Positions dans le back office. Déplacez votre module personnalisé en dessous du module cible sur le hook actionFrontControllerSetMedia pour vous assurer que vos appels de désenregistrement se produisent après que le module cible a enregistré ses ressources.

Si le module fautif utilise les anciennes méthodes addCSS et addJS au lieu de registerStylesheet et registerJavascript, les méthodes de désenregistrement peuvent ne pas fonctionner car les anciennes méthodes n'utilisent pas le même système de gestion des ressources. Dans ce cas, vous avez besoin d'une approche différente.

Méthode 3 : Module personnalisé pour bloquer des ressources spécifiques

Lorsque vous avez besoin d'un contrôle granulaire sur quelles ressources se chargent sur quelles pages, créer un module dédié de gestion des ressources est la solution la plus flexible. Ce module agit comme un point central où vous définissez les règles de blocage ou d'autorisation de ressources spécifiques de modules.

Créez un nouveau module avec une méthode hookActionFrontControllerSetMedia. À l'intérieur de cette méthode, définissez un tableau de règles de ressources. Chaque règle spécifie un nom de module, les identifiants de ressources à bloquer et les conditions dans lesquelles les bloquer. Les conditions peuvent être basées sur le nom du contrôleur, le type de page ou tout autre critère disponible dans le contexte PrestaShop.

Votre module parcourt les règles à chaque chargement de page, vérifie les conditions et appelle Media::unregisterStylesheet ou Media::unregisterJavascript pour chaque ressource qui devrait être bloquée sur la page actuelle. Cette approche centralisée est beaucoup plus facile à maintenir que de disperser la logique de suppression de ressources dans plusieurs modules ou fichiers de thème.

Vous pouvez améliorer ce module avec une page de configuration dans le back office qui vous permet de gérer les règles via l'interface d'administration PrestaShop au lieu de modifier le code. Un formulaire simple avec des champs pour le nom du module, l'identifiant de la ressource et un multi-select pour les types de pages où la ressource doit être bloquée vous donne un moyen convivial de gérer le chargement des ressources sans toucher au code après la configuration initiale.

Cette approche fonctionne avec le nouveau système registerStylesheet comme avec l'ancien système addCSS, bien que vous puissiez avoir besoin d'utiliser des techniques différentes pour chacun. Pour les ressources enregistrées avec le nouveau système, utilisez les méthodes Media::unregister. Pour les ressources ajoutées avec l'ancien système, vous pouvez manipuler directement les tableaux css_files et js_files du contrôleur dans la méthode hookActionFrontControllerSetMedia.

Méthode 4 : L'approche par décrochage de hook

Une approche plus agressive mais parfois nécessaire consiste à décrocher complètement un module des hooks où il enregistre ses ressources. Allez dans Apparence, puis Positions dans votre back office. Trouvez le module sur le hook displayHeader ou actionFrontControllerSetMedia. Cliquez sur le bouton supprimer ou décrocher pour retirer le module de ce hook entièrement.

Cela empêche le module de charger toute ressource, sur n'importe quelle page. Les autres hooks du module, comme displayProductAdditionalInfo ou displayFooter, continuent de fonctionner normalement. Cependant, la sortie du module en front office peut être cassée s'il dépend de son CSS pour le style ou de son JavaScript pour le comportement interactif.

Cette approche est plus utile lorsque vous prévoyez de remplacer entièrement le style du module par votre propre CSS personnalisé. Vous décrochez le module de displayHeader pour empêcher le chargement de son CSS, puis vous écrivez vos propres styles dans le fichier CSS personnalisé de votre thème ciblant les éléments HTML du module. Cela vous donne un contrôle complet sur l'apparence du module sans aucun conflit entre les styles d'origine et vos personnalisations.

Pour le JavaScript, le décrochage est plus risqué. Si le module s'appuie sur son JavaScript pour des fonctionnalités essentielles comme les appels AJAX, la validation de formulaires ou le chargement de contenu dynamique, supprimer le JavaScript cassera ces fonctionnalités. Ne décrochez le JavaScript que si vous êtes certain que la sortie du module en front office n'en dépend pas, ou si vous fournissez une implémentation de remplacement via votre thème.

Une mise en garde importante : si vous mettez à jour le module, le processus de mise à jour peut réenregistrer le module sur les hooks dont vous l'avez retiré. Après chaque mise à jour de module, vérifiez dans Apparence, Positions que votre décrochage est toujours en vigueur. Certains modules enregistrent explicitement leurs hooks pendant le processus de mise à jour, ce qui écrase votre décrochage manuel.

Méthode 5 : Remplacer les ressources des modules via votre thème

Le système de thèmes de PrestaShop vous permet de surcharger les fichiers de templates de modules en les plaçant dans le répertoire modules de votre thème. Bien que cela soit principalement utilisé pour les surcharges de templates, vous pouvez également l'utiliser pour contrôler indirectement le chargement des ressources.

Si un module charge ses ressources via ses fichiers de templates en utilisant des fonctions Smarty comme des balises de ressources directement dans les fichiers TPL plutôt que via des hooks PHP, vous pouvez surcharger ces templates dans votre thème et supprimer les références aux ressources. Copiez le fichier de template du module dans le répertoire modules de votre thème, en conservant la même structure de répertoires, et modifiez la copie pour supprimer les références CSS ou JavaScript indésirables.

Cette approche est spécifique au thème, ce qui signifie qu'elle n'affecte que le thème actuel. Si vous changez de thème, les surcharges ne sont pas transférées. Elle nécessite également de la maintenance : lorsque le module met à jour ses templates, vous devez mettre à jour vos surcharges pour correspondre aux changements structurels tout en conservant vos modifications de suppression de ressources.

Pour les modules qui chargent des ressources via des hooks PHP plutôt que des templates, les surcharges de templates de thème n'aident pas au blocage des ressources. Dans ce cas, utilisez l'une des autres méthodes décrites dans cet article.

PrestaShop 1.7 vs 8.x : différences d'approche

PrestaShop 8.x a affiné le système de gestion des ressources introduit dans la version 1.7, mais les approches fondamentales restent les mêmes. Les principales différences résident dans l'implémentation interne et quelques fonctionnalités supplémentaires.

Dans PrestaShop 1.7, le système de gestion des ressources utilise registerStylesheet et registerJavascript avec un système de priorité. Les méthodes Media::unregisterStylesheet et Media::unregisterJavascript fonctionnent de manière fiable pour les ressources enregistrées via ce système. Cependant, les modules qui utilisent encore les anciennes méthodes addCSS et addJS (qui sont dépréciées mais toujours fonctionnelles) ne passent pas par le nouveau système de gestion des ressources, ce qui les rend plus difficiles à supprimer proprement.

PrestaShop 8.x a amélioré la rétrocompatibilité de sorte que même les ressources ajoutées via les anciennes méthodes sont traitées par le nouveau pipeline de ressources. Cela signifie que les méthodes Media::unregister fonctionnent de manière plus cohérente sur tous les modules, quelle que soit la méthode d'enregistrement utilisée. Si vous utilisez PrestaShop 8.x, l'approche de désenregistrement est la méthode la plus fiable pour tous les modules.

PrestaShop 8.x a également introduit un meilleur cache-busting pour les ressources, ce qui signifie que lorsque vous supprimez ou modifiez des ressources, les changements prennent effet immédiatement après avoir vidé le cache, sans que les clients voient des versions mises en cache obsolètes. Dans PrestaShop 1.7, vous deviez parfois vider à la fois le cache PrestaShop et le cache du navigateur, ou attendre que le système Combiner, Compresser, Mettre en Cache (CCC) régénère les fichiers combinés.

Les deux versions prennent en charge l'approche theme.yml pour la suppression de ressources, et la syntaxe est identique. Si vous écrivez un module personnalisé pour la gestion des ressources, le même code fonctionne sur les versions 1.7 et 8.x avec des différences minimales.

Mesurer les gains de performance après la désactivation des ressources

Après avoir désactivé les ressources des modules, vous devriez mesurer l'amélioration des performances pour confirmer que vos modifications ont eu l'effet attendu. Utilisez une combinaison d'outils pour une mesure complète.

Commencez avec l'onglet Réseau des DevTools de Chrome. Comparez le nombre total de requêtes et la taille totale transférée avant et après vos modifications. Filtrez par CSS et JS pour voir la réduction spécifique du nombre et de la taille des fichiers de feuilles de style et JavaScript. Une optimisation significative devrait montrer une réduction claire à la fois du nombre de requêtes et de la taille totale.

Lancez un audit de performance Lighthouse avant et après. Concentrez-vous sur les métriques les plus affectées par le chargement de CSS et JavaScript : le First Contentful Paint est affecté par le CSS bloquant le rendu, le Largest Contentful Paint est affecté par le chargement global des ressources, et le Total Blocking Time est affecté par l'analyse et l'exécution du JavaScript. Enregistrez ces métriques d'au moins trois exécutions et comparez les moyennes.

Utilisez l'onglet Couverture (Coverage) dans les DevTools de Chrome pour mesurer l'utilisation du CSS et du JavaScript. Ouvrez l'onglet Couverture depuis le menu à trois points sous Plus d'outils, puis rechargez la page. L'onglet Couverture vous montre quelle proportion de chaque fichier CSS et JavaScript est réellement utilisée sur la page actuelle. Les fichiers avec un pourcentage élevé de code inutilisé (affiché en rouge) sont des candidats à la suppression ou au chargement conditionnel. Après avoir désactivé les ressources des modules, les fichiers restants devraient montrer des pourcentages d'utilisation plus élevés, indiquant que vous avez réussi à éliminer le gaspillage.

Considérez également les métriques du monde réel issues de votre plateforme d'analyse. Si vous utilisez Google Analytics ou un outil similaire, comparez les temps de chargement des pages pendant une semaine avant et après votre optimisation. Les données réelles de vrais visiteurs avec différents appareils et conditions réseau vous donnent l'image la plus précise de l'amélioration des performances.

Risques et problèmes de compatibilité

La désactivation des ressources de modules comporte des risques que vous devez comprendre et gérer. Le risque le plus courant est la casse visuelle. Lorsque vous supprimez le CSS d'un module, ses éléments HTML perdent leur style et peuvent s'afficher incorrectement. Cela peut aller de problèmes cosmétiques mineurs comme des couleurs ou des espacements incorrects à des problèmes de mise en page majeurs comme des éléments qui se chevauchent ou du contenu invisible.

La suppression du JavaScript comporte un risque plus élevé. Les modules modernes dépendent souvent de leur JavaScript pour des fonctionnalités essentielles. Supprimer le JavaScript peut provoquer l'arrêt complet de fonctionnalités : des boutons qui ne répondent pas aux clics, des formulaires qui ne se soumettent pas, des popups qui ne s'ouvrent pas, du contenu AJAX qui ne se charge pas. Testez toujours chaque fonctionnalité d'un module après avoir supprimé son JavaScript.

Il y a également un risque de compatibilité avec les mises à jour de modules. Lorsqu'un module est mis à jour, le développeur peut ajouter de nouveaux fichiers CSS ou JavaScript avec des identifiants de ressources différents. Vos règles de suppression, que ce soit dans theme.yml ou un module personnalisé, peuvent ne pas intercepter les nouvelles ressources car elles ciblent les anciens identifiants. Après chaque mise à jour de module, vérifiez que votre blocage de ressources fonctionne toujours correctement et mettez à jour vos règles si nécessaire.

Certains modules effectuent une détection de fonctionnalités dans leur JavaScript et se comportent différemment lorsque leur CSS n'est pas chargé. Un module peut vérifier l'existence de classes CSS spécifiques ou de styles calculés avant d'initialiser ses fonctionnalités JavaScript. Supprimer le CSS dans ce cas ne change pas seulement l'apparence mais casse également le comportement JavaScript qui dépend de ces états définis par le CSS.

Enfin, soyez conscient des dépendances entre modules. Le Module A peut charger une bibliothèque JavaScript comme un plugin de lightbox que le Module B utilise également mais ne charge pas lui-même parce qu'il suppose que le Module A la fournit. Supprimer les fichiers JavaScript du Module A casserait les deux modules dans ce scénario. Vérifiez les dépendances partagées avant de supprimer des ressources.

Un flux de travail pratique pour la suppression sécurisée des ressources

Suivez ce flux de travail pour désactiver en toute sécurité les ressources de modules sans casser votre boutique. Premièrement, documentez votre état actuel. Prenez des captures d'écran de chaque type de page où le module affiche du contenu. Enregistrez les scores Lighthouse et les statistiques de l'onglet Réseau. Cela vous donne une base de comparaison et une référence pour l'apparence et le fonctionnement attendus du module.

Deuxièmement, identifiez les ressources spécifiques que vous souhaitez supprimer. Utilisez les DevTools pour trouver les noms de fichiers exacts et les identifiants de ressources. Déterminez quelles pages ont besoin des ressources et lesquelles n'en ont pas.

Troisièmement, implémentez la suppression en utilisant la méthode la plus appropriée de cet article. Pour une suppression globale simple, utilisez theme.yml. Pour une suppression conditionnelle basée sur le type de page, créez un module personnalisé avec des appels Media::unregister. Pour un remplacement complet des ressources, décrochez le module et fournissez vos propres styles.

Quatrièmement, testez minutieusement. Vérifiez chaque type de page où le module devrait afficher du contenu. Vérifiez que l'apparence visuelle du module est correcte et que toutes les fonctionnalités interactives fonctionnent. Vérifiez les pages où vous avez supprimé les ressources pour confirmer qu'elles ne se chargent plus. Testez sur plusieurs navigateurs et appareils.

Cinquièmement, mesurez l'amélioration des performances. Lancez des audits Lighthouse et comparez avec votre référence. Vérifiez l'onglet Réseau pour la réduction du nombre de requêtes et des tailles. Si l'amélioration est significative, votre optimisation a réussi. Si l'amélioration est minimale, les ressources que vous avez supprimées n'étaient peut-être pas le principal goulot d'étranglement de performance, et vous devriez investiguer d'autres opportunités d'optimisation.

Sixièmement, documentez vos modifications. Enregistrez quelles ressources vous avez supprimées, quelle méthode vous avez utilisée et quelles pages sont affectées. Cette documentation est essentielle pour le dépannage de problèmes futurs, surtout après les mises à jour de modules, et pour le transfert de connaissances si quelqu'un d'autre maintient la boutique.

En suivant cette approche systématique, vous pouvez réduire en toute sécurité le poids de page de votre boutique et améliorer les temps de chargement sans sacrifier les fonctionnalités de module dont votre boutique dépend. La clé est toujours le test et la mesure : ne supposez jamais que la suppression d'une ressource est sûre, et vérifiez toujours les résultats avec des données concrètes.