Come disabilitare i CSS/JS di un modulo senza disinstallarlo

Il problema: hai bisogno del modulo, ma non delle sue risorse su ogni pagina

Ci sono molte situazioni in cui vuoi mantenere un modulo PrestaShop installato e attivo ma impedirgli di caricare i suoi file CSS o JavaScript su pagine specifiche, o addirittura su tutte le pagine. Forse hai un modulo di cui hai bisogno della funzionalità ma il cui stile è in conflitto con il tuo tema. Forse un modulo carica una libreria JavaScript pesante che hai già incluso attraverso il tuo tema. Forse vuoi sostituire gli stili predefiniti di un modulo con il tuo CSS personalizzato senza che gli stili originali interferiscano. Oppure forse hai identificato attraverso un audit delle prestazioni che un modulo carica risorse su pagine dove non ha alcun output visibile e vuoi eliminare quello spreco.

Disinstallare il modulo non è un'opzione perché hai bisogno delle sue funzionalità principali: i suoi hook, le sue tabelle nel database, la sua configurazione, le sue funzionalità nel back office. Devi semplicemente rimuovere chirurgicamente specifici file CSS o JavaScript dall'output del front office. PrestaShop fornisce diversi meccanismi per raggiungere questo obiettivo, e questo articolo li copre tutti in dettaglio, dal più semplice al più potente.

Metodo 1: Utilizzare Theme.yml per rimuovere le risorse dei moduli

Il modo più semplice e manutenibile per rimuovere i CSS o JavaScript di un modulo in PrestaShop 1.7 e versioni successive è attraverso il file di configurazione del tema, theme.yml. Questo file, situato nella directory radice del tuo tema, controlla quali risorse carica il tema e quali risorse dei moduli vengono rimosse.

Apri il tuo file theme.yml e cerca la sezione assets. Se non esiste, puoi crearla. All'interno della sezione assets, puoi specificare i file CSS e JavaScript da rimuovere tramite il loro ID risorsa. Ogni risorsa registrata attraverso registerStylesheet o registerJavascript ha un ID, che tipicamente è il nome del modulo seguito da un suffisso descrittivo.

Per trovare gli ID delle risorse utilizzati da un modulo, ispeziona il codice sorgente della tua pagina e cerca i tag link dei fogli di stile e gli elementi script. PrestaShop aggiunge un attributo id a questi elementi in modalità debug, oppure puoi trovare gli ID nel codice sorgente del modulo dove chiama registerStylesheet o registerJavascript.

Nel tuo file theme.yml, aggiungi una sezione sotto assets, poi css, poi all. Aggiungi una voce con l'ID della risorsa e impostalo su false. Ad esempio, se un modulo registra un foglio di stile con l'ID modulename-style, aggiungeresti modulename-style con un valore false sotto la sezione css all. Fai lo stesso per i file JavaScript sotto la sezione js all.

Dopo aver modificato theme.yml, devi svuotare la cache di PrestaShop da Parametri Avanzati, Prestazioni. Le modifiche a theme.yml hanno effetto dopo la ricostruzione della cache. Questo approccio persiste attraverso gli aggiornamenti del modulo perché la rimozione è definita nel tuo tema, non nel modulo stesso. Tuttavia, rimuove le risorse da tutte le pagine. Se hai bisogno delle risorse su alcune pagine ma non su altre, avrai bisogno di un approccio più mirato.

Metodo 2: Media::unregisterStylesheet e Media::unregisterJavascript

PrestaShop 1.7 ha introdotto i metodi della classe Media unregisterStylesheet e unregisterJavascript, che consentono di rimuovere programmaticamente specifiche risorse registrate da altri moduli. Questi metodi sono potenti perché puoi chiamarli in modo condizionale, rimuovendo le risorse solo su pagine specifiche mantenendole sulle altre.

Per utilizzare questo approccio, hai bisogno di un modulo personalizzato o di una modifica a un modulo esistente. Nel metodo hookActionFrontControllerSetMedia del tuo modulo, chiama Media::unregisterStylesheet con l'ID della risorsa del file CSS che vuoi rimuovere. Analogamente, chiama Media::unregisterJavascript con l'ID della risorsa del file JavaScript. Puoi racchiudere queste chiamate in logica condizionale per rimuovere le risorse solo su specifici tipi di pagina.

Ad esempio, se vuoi rimuovere le risorse di un modulo slider da ogni pagina eccetto la homepage, verificheresti se il controller corrente è IndexController. Se non è la homepage, chiami i metodi di deregistrazione. Se è la homepage, non fai nulla e lasci che le risorse si carichino normalmente.

La considerazione chiave con questo approccio è l'ordine di esecuzione degli hook. Il hookActionFrontControllerSetMedia del tuo modulo deve essere eseguito dopo il modulo di cui vuoi rimuovere le risorse. PrestaShop esegue i callback degli hook nell'ordine in cui i moduli sono registrati sull'hook, che puoi controllare attraverso la pagina Design, Posizioni nel back office. Sposta il tuo modulo personalizzato sotto il modulo target sull'hook actionFrontControllerSetMedia per assicurarti che le tue chiamate di deregistrazione avvengano dopo che il modulo target ha registrato le sue risorse.

Se il modulo problematico utilizza i vecchi metodi addCSS e addJS invece di registerStylesheet e registerJavascript, i metodi di deregistrazione potrebbero non funzionare perché i vecchi metodi non utilizzano lo stesso sistema di gestione delle risorse. In quel caso, hai bisogno di un approccio diverso.

Metodo 3: Modulo personalizzato per bloccare risorse specifiche

Quando hai bisogno di un controllo granulare su quali risorse si caricano su quali pagine, creare un modulo dedicato alla gestione delle risorse è la soluzione più flessibile. Questo modulo funge da punto centrale dove definisci le regole per bloccare o consentire specifiche risorse dei moduli.

Crea un nuovo modulo con un metodo hookActionFrontControllerSetMedia. All'interno di questo metodo, definisci un array di regole per le risorse. Ogni regola specifica il nome di un modulo, gli ID delle risorse da bloccare e le condizioni in base alle quali bloccarle. Le condizioni possono essere basate sul nome del controller, sul tipo di pagina o su qualsiasi altro criterio disponibile nel contesto PrestaShop.

Il tuo modulo scorre le regole a ogni caricamento di pagina, verifica le condizioni e chiama Media::unregisterStylesheet o Media::unregisterJavascript per ogni risorsa che dovrebbe essere bloccata sulla pagina corrente. Questo approccio centralizzato è molto più facile da mantenere rispetto a distribuire la logica di rimozione delle risorse tra più moduli o file del tema.

Puoi migliorare questo modulo con una pagina di configurazione nel back office che ti permette di gestire le regole attraverso l'interfaccia di amministrazione di PrestaShop invece di modificare il codice. Un semplice modulo con campi per il nome del modulo, l'ID della risorsa e un multiselect per i tipi di pagina dove la risorsa dovrebbe essere bloccata ti offre un modo intuitivo per gestire il caricamento delle risorse senza toccare il codice dopo la configurazione iniziale.

Questo approccio funziona sia con il nuovo sistema registerStylesheet sia con il vecchio sistema addCSS, anche se potresti dover utilizzare tecniche diverse per ciascuno. Per le risorse registrate con il nuovo sistema, usa i metodi Media::unregister. Per le risorse aggiunte con il vecchio sistema, puoi manipolare direttamente gli array css_files e js_files del controller nel metodo hookActionFrontControllerSetMedia.

Metodo 4: L'approccio di sganciamento dall'hook

Un approccio più aggressivo ma talvolta necessario è sganciare completamente un modulo dagli hook dove registra le sue risorse. Vai su Design, quindi Posizioni nel tuo back office. Trova il modulo sull'hook displayHeader o actionFrontControllerSetMedia. Clicca sul pulsante elimina o sgancia per rimuovere il modulo da quell'hook completamente.

Questo impedisce al modulo di caricare qualsiasi risorsa, su qualsiasi pagina. Gli altri hook del modulo, come displayProductAdditionalInfo o displayFooter, continuano a funzionare normalmente. Tuttavia, l'output del modulo sul front office potrebbe rompersi se dipende dai suoi CSS per lo stile o dai suoi JavaScript per il comportamento interattivo.

Questo approccio è più utile quando prevedi di sostituire interamente lo stile del modulo con il tuo CSS personalizzato. Sganci il modulo da displayHeader per impedire il caricamento del suo CSS, poi scrivi i tuoi stili nel file CSS personalizzato del tuo tema che puntano agli elementi HTML del modulo. Questo ti dà il controllo completo sull'aspetto del modulo senza alcun conflitto tra gli stili originali e le tue personalizzazioni.

Per il JavaScript, lo sganciamento è più rischioso. Se il modulo si basa sul suo JavaScript per funzionalità core come chiamate AJAX, validazione dei form o caricamento dinamico dei contenuti, rimuovere il JavaScript romperà quelle funzionalità. Sgancia il JavaScript solo se sei certo che l'output del modulo sul front office non dipenda da esso, o se stai fornendo un'implementazione sostitutiva attraverso il tuo tema.

Un'avvertenza importante: se aggiorni il modulo, il processo di aggiornamento potrebbe ri-registrare il modulo sugli hook da cui lo avevi rimosso. Dopo ogni aggiornamento del modulo, controlla Design, Posizioni per verificare che il tuo sganciamento sia ancora attivo. Alcuni moduli registrano esplicitamente i loro hook durante il processo di aggiornamento, il che sovrascrive il tuo sganciamento manuale.

Metodo 5: Sovrascrivere le risorse dei moduli attraverso il tema

Il sistema di temi di PrestaShop consente di sovrascrivere i file template dei moduli posizionandoli nella directory modules del tuo tema. Sebbene questo sia utilizzato principalmente per le sovrascritture dei template, puoi anche usarlo per controllare indirettamente il caricamento delle risorse.

Se un modulo carica le sue risorse attraverso i suoi file template utilizzando funzioni Smarty come tag script o stylesheet direttamente nei file TPL piuttosto che attraverso hook PHP, puoi sovrascrivere quei template nel tuo tema e rimuovere i riferimenti alle risorse. Copia il file template del modulo nella directory modules del tuo tema, mantenendo la stessa struttura di directory, e modifica la copia per rimuovere i riferimenti CSS o JavaScript indesiderati.

Questo approccio è specifico del tema, il che significa che influisce solo sul tema corrente. Se cambi tema, le sovrascritture non si trasferiscono. Richiede anche manutenzione: quando il modulo aggiorna i suoi template, devi aggiornare le tue sovrascritture per corrispondere a eventuali modifiche strutturali mantenendo le tue modifiche di rimozione delle risorse.

Per i moduli che caricano risorse attraverso hook PHP piuttosto che template, le sovrascritture dei template del tema non aiutano con il blocco delle risorse. In quel caso, usa uno degli altri metodi descritti in questo articolo.

PrestaShop 1.7 vs 8.x: differenze nell'approccio

PrestaShop 8.x ha perfezionato il sistema di gestione delle risorse introdotto nella 1.7, ma gli approcci fondamentali rimangono gli stessi. Le differenze principali riguardano l'implementazione interna e alcune funzionalità aggiuntive.

In PrestaShop 1.7, il sistema di gestione delle risorse utilizza registerStylesheet e registerJavascript con un sistema di priorità. I metodi Media::unregisterStylesheet e Media::unregisterJavascript funzionano in modo affidabile per le risorse registrate attraverso questo sistema. Tuttavia, i moduli che utilizzano ancora i vecchi metodi addCSS e addJS (che sono deprecati ma ancora funzionanti) non passano attraverso il nuovo sistema di gestione delle risorse, rendendoli più difficili da rimuovere in modo pulito.

PrestaShop 8.x ha migliorato la retrocompatibilità in modo che anche le risorse aggiunte attraverso i vecchi metodi vengano elaborate attraverso la nuova pipeline delle risorse. Questo significa che i metodi Media::unregister funzionano in modo più coerente su tutti i moduli, indipendentemente dal metodo di registrazione utilizzato. Se utilizzi PrestaShop 8.x, l'approccio di deregistrazione è il metodo più affidabile per tutti i moduli.

PrestaShop 8.x ha anche introdotto un migliore cache-busting per le risorse, il che significa che quando rimuovi o modifichi le risorse, le modifiche hanno effetto immediatamente dopo aver svuotato la cache, senza che i clienti vedano versioni memorizzate in cache obsolete. In PrestaShop 1.7, a volte era necessario svuotare sia la cache di PrestaShop sia la cache del browser, o attendere che il sistema Combine, Compress, Cache (CCC) rigenerasse i file combinati.

Entrambe le versioni supportano l'approccio theme.yml per la rimozione delle risorse, e la sintassi è identica. Se stai scrivendo un modulo personalizzato per la gestione delle risorse, lo stesso codice funziona sia su 1.7 che su 8.x con differenze minime.

Misurare i miglioramenti delle prestazioni dopo la disabilitazione delle risorse

Dopo aver disabilitato le risorse dei moduli, dovresti misurare il miglioramento delle prestazioni per confermare che le tue modifiche hanno avuto l'effetto previsto. Usa una combinazione di strumenti per una misurazione completa.

Inizia con la scheda Network dei Chrome DevTools. Confronta il numero totale di richieste e la dimensione totale trasferita prima e dopo le tue modifiche. Filtra per CSS e JS per vedere la riduzione specifica nel numero e nelle dimensioni dei file di fogli di stile e JavaScript. Un'ottimizzazione significativa dovrebbe mostrare una chiara riduzione sia nel numero di richieste sia nella dimensione totale.

Esegui un audit delle prestazioni con Lighthouse prima e dopo. Concentrati sulle metriche più influenzate dal caricamento di CSS e JavaScript: il First Contentful Paint è influenzato dai CSS render-blocking, il Largest Contentful Paint è influenzato dal caricamento complessivo delle risorse e il Total Blocking Time è influenzato dal parsing e dall'esecuzione del JavaScript. Registra queste metriche da almeno tre esecuzioni e confronta le medie.

Usa la scheda Coverage nei Chrome DevTools per misurare l'utilizzo di CSS e JavaScript. Apri la scheda Coverage dal menu a tre punti sotto Altri Strumenti, poi ricarica la pagina. La scheda Coverage ti mostra quanto di ogni file CSS e JavaScript viene effettivamente utilizzato sulla pagina corrente. I file con alte percentuali di inutilizzo (mostrate in rosso) sono candidati per la rimozione o il caricamento condizionale. Dopo aver disabilitato le risorse dei moduli, i file rimanenti dovrebbero mostrare percentuali di utilizzo più alte, indicando che hai rimosso con successo lo spreco.

Considera anche le metriche reali dalla tua piattaforma di analytics. Se usi Google Analytics o uno strumento simile, confronta i tempi di caricamento delle pagine per una settimana prima e dopo la tua ottimizzazione. I dati reali provenienti dai visitatori effettivi su diversi dispositivi e condizioni di rete ti danno il quadro più accurato del miglioramento delle prestazioni.

Rischi e problemi di compatibilità

La disabilitazione delle risorse dei moduli comporta rischi che devi comprendere e gestire. Il rischio più comune è la rottura visiva. Quando rimuovi il CSS di un modulo, i suoi elementi HTML perdono il loro stile e possono essere visualizzati in modo errato. Questo può variare da problemi estetici minori come colori o spaziature errate a problemi di layout importanti come elementi sovrapposti o contenuti invisibili.

La rimozione del JavaScript comporta un rischio maggiore. I moduli moderni spesso dipendono dal loro JavaScript per le funzionalità principali. Rimuovere il JavaScript può causare l'interruzione completa delle funzionalità: pulsanti che non rispondono ai clic, form che non si inviano, popup che non si aprono, contenuti AJAX che non si caricano. Testa sempre ogni funzionalità di un modulo dopo aver rimosso il suo JavaScript.

C'è anche un rischio di compatibilità con gli aggiornamenti dei moduli. Quando un modulo viene aggiornato, lo sviluppatore potrebbe aggiungere nuovi file CSS o JavaScript con ID risorsa diversi. Le tue regole di rimozione, sia in theme.yml che in un modulo personalizzato, potrebbero non intercettare le nuove risorse perché puntano ai vecchi ID. Dopo ogni aggiornamento del modulo, verifica che il tuo blocco delle risorse funzioni ancora correttamente e aggiorna le tue regole se necessario.

Alcuni moduli eseguono il rilevamento delle funzionalità nel loro JavaScript e si comportano diversamente quando il loro CSS non è caricato. Un modulo potrebbe verificare l'esistenza di specifiche classi CSS o stili calcolati prima di inizializzare la sua funzionalità JavaScript. Rimuovere il CSS in questo caso non cambia solo l'aspetto ma rompe anche il comportamento JavaScript che dipende da quegli stati definiti via CSS.

Infine, fai attenzione alle dipendenze tra moduli. Il Modulo A potrebbe caricare una libreria JavaScript come un plugin lightbox che anche il Modulo B utilizza ma non carica autonomamente perché presuppone che sia il Modulo A a fornirla. Rimuovere i file JavaScript del Modulo A in questo scenario romperebbe entrambi i moduli. Controlla le dipendenze condivise prima di rimuovere qualsiasi risorsa.

Un flusso di lavoro pratico per la rimozione sicura delle risorse

Segui questo flusso di lavoro per disabilitare in sicurezza le risorse dei moduli senza rompere il tuo negozio. Per prima cosa, documenta il tuo stato attuale. Fai screenshot di ogni tipo di pagina dove il modulo visualizza contenuti. Registra i punteggi Lighthouse e le statistiche della scheda Network. Questo ti dà una base di confronto e un riferimento per come il modulo dovrebbe apparire e funzionare.

Secondo, identifica le risorse specifiche che vuoi rimuovere. Usa i DevTools per trovare i nomi esatti dei file e gli ID delle risorse. Determina quali pagine necessitano delle risorse e quali no.

Terzo, implementa la rimozione utilizzando il metodo più appropriato di questo articolo. Per una rimozione globale semplice, usa theme.yml. Per una rimozione condizionale basata sul tipo di pagina, crea un modulo personalizzato con chiamate Media::unregister. Per una sostituzione completa delle risorse, sgancia il modulo e fornisci i tuoi stili.

Quarto, testa approfonditamente. Controlla ogni tipo di pagina dove il modulo dovrebbe visualizzare contenuti. Verifica che l'aspetto visivo del modulo sia corretto e che tutte le funzionalità interattive funzionino. Controlla le pagine dove hai rimosso le risorse per confermare che non si stanno più caricando. Testa su più browser e dispositivi.

Quinto, misura il miglioramento delle prestazioni. Esegui audit Lighthouse e confronta con la tua base di riferimento. Controlla la scheda Network per la riduzione nel numero di richieste e nelle dimensioni. Se il miglioramento è significativo, la tua ottimizzazione ha avuto successo. Se il miglioramento è minimo, le risorse che hai rimosso potrebbero non essere state il principale collo di bottiglia delle prestazioni e dovresti indagare altre opportunità di ottimizzazione.

Sesto, documenta le tue modifiche. Registra quali risorse hai rimosso, quale metodo hai utilizzato e quali pagine sono interessate. Questa documentazione è essenziale per la risoluzione dei problemi futuri, specialmente dopo gli aggiornamenti dei moduli, e per il trasferimento di conoscenze se qualcun altro gestisce il negozio.

Seguendo questo approccio sistematico, puoi ridurre in sicurezza il peso delle pagine del tuo negozio e migliorare i tempi di caricamento senza sacrificare le funzionalità dei moduli da cui il tuo negozio dipende. La chiave è sempre testare e misurare: non dare mai per scontato che rimuovere una risorsa sia sicuro e verifica sempre i risultati con dati concreti.