Wie Sie CSS/JS eines Moduls deaktivieren, ohne es zu deinstallieren

Das Problem: Sie brauchen das Modul, aber nicht seine Assets auf jeder Seite

Es gibt viele Situationen, in denen Sie ein PrestaShop-Modul installiert und aktiv lassen möchten, aber verhindern wollen, dass es seine CSS- oder JavaScript-Dateien auf bestimmten Seiten oder sogar auf allen Seiten lädt. Vielleicht haben Sie ein Modul, dessen Funktionalität Sie benötigen, dessen Styling aber mit Ihrem Theme in Konflikt steht. Vielleicht lädt ein Modul eine schwere JavaScript-Bibliothek, die Sie bereits über Ihr Theme eingebunden haben. Vielleicht möchten Sie die Standardstile eines Moduls durch Ihr eigenes benutzerdefiniertes CSS ersetzen, ohne dass die Originalstile stören. Oder vielleicht haben Sie durch ein Performance-Audit festgestellt, dass ein Modul Assets auf Seiten lädt, auf denen es keine sichtbare Ausgabe hat, und Sie diese Verschwendung beseitigen möchten.

Das Modul zu deinstallieren kommt nicht in Frage, weil Sie seine Kernfunktionalität benötigen: seine Hooks, seine Datenbanktabellen, seine Konfiguration, seine Back-Office-Funktionen. Sie müssen lediglich chirurgisch bestimmte CSS- oder JavaScript-Dateien aus der Front-Office-Ausgabe entfernen. PrestaShop bietet mehrere Mechanismen, um dies zu erreichen, und dieser Artikel behandelt alle im Detail, vom einfachsten bis zum leistungsfähigsten.

Methode 1: Theme.yml verwenden, um Modul-Assets zu entfernen

Der einfachste und wartbarste Weg, CSS oder JavaScript eines Moduls in PrestaShop 1.7 und später zu entfernen, führt über die Konfigurationsdatei des Themes, die theme.yml. Diese Datei, die sich im Stammverzeichnis Ihres Theme-Ordners befindet, steuert, welche Assets das Theme lädt und welche Modul-Assets es entfernt.

Öffnen Sie Ihre theme.yml-Datei und suchen Sie den Assets-Bereich. Wenn er nicht existiert, können Sie ihn erstellen. Innerhalb des Assets-Bereichs können Sie CSS- und JavaScript-Dateien angeben, die nach ihrer Asset-ID entfernt werden sollen. Jedes Asset, das über registerStylesheet oder registerJavascript registriert wird, hat eine ID, die typischerweise aus dem Modulnamen gefolgt von einem beschreibenden Suffix besteht.

Um die Asset-IDs eines Moduls zu finden, untersuchen Sie den Quellcode Ihrer Seite und suchen Sie nach den Stylesheet-Link-Tags und den Script-Elementen. PrestaShop fügt diesen Elementen im Debug-Modus ein id-Attribut hinzu, oder Sie finden die IDs im Quellcode des Moduls, wo es registerStylesheet oder registerJavascript aufruft.

Fügen Sie in Ihrer theme.yml-Datei einen Bereich unter assets, dann css, dann all hinzu. Fügen Sie einen Eintrag mit der Asset-ID hinzu und setzen Sie ihn auf false. Wenn beispielsweise ein Modul ein Stylesheet mit der ID modulname-style registriert, würden Sie modulname-style mit dem Wert false unter dem Bereich css all hinzufügen. Verfahren Sie genauso für JavaScript-Dateien unter dem Bereich js all.

Nach der Änderung der theme.yml müssen Sie den PrestaShop-Cache unter Erweiterte Einstellungen, Leistung löschen. Die theme.yml-Änderungen werden nach dem Neuaufbau des Caches wirksam. Dieser Ansatz bleibt über Modul-Updates hinweg bestehen, da die Entfernung in Ihrem Theme definiert ist, nicht im Modul selbst. Er entfernt die Assets jedoch von allen Seiten. Wenn Sie die Assets auf manchen Seiten benötigen, aber auf anderen nicht, brauchen Sie einen gezielteren Ansatz.

Methode 2: Media::unregisterStylesheet und Media::unregisterJavascript

PrestaShop 1.7 führte die Media-Klassenmethoden unregisterStylesheet und unregisterJavascript ein, die es Ihnen ermöglichen, programmgesteuert bestimmte Assets zu entfernen, die von anderen Modulen registriert wurden. Diese Methoden sind leistungsfähig, weil Sie sie bedingt aufrufen können — Assets nur auf bestimmten Seiten entfernen und auf anderen beibehalten.

Um diesen Ansatz zu verwenden, benötigen Sie ein benutzerdefiniertes Modul oder eine Modifikation an einem bestehenden Modul. Rufen Sie in der hookActionFrontControllerSetMedia-Methode Ihres Moduls Media::unregisterStylesheet mit der Asset-ID der CSS-Datei auf, die Sie entfernen möchten. Rufen Sie entsprechend Media::unregisterJavascript mit der Asset-ID der JavaScript-Datei auf. Sie können diese Aufrufe in bedingte Logik einbetten, um Assets nur auf bestimmten Seitentypen zu entfernen.

Wenn Sie beispielsweise die Assets eines Slider-Moduls von jeder Seite außer der Startseite entfernen möchten, würden Sie prüfen, ob der aktuelle Controller der IndexController ist. Wenn es nicht die Startseite ist, rufen Sie die Unregister-Methoden auf. Wenn es die Startseite ist, tun Sie nichts und lassen die Assets normal laden.

Die zentrale Überlegung bei diesem Ansatz ist die Hook-Ausführungsreihenfolge. Die hookActionFrontControllerSetMedia-Methode Ihres Moduls muss nach dem Modul ausgeführt werden, dessen Assets Sie entfernen möchten. PrestaShop führt Hook-Callbacks in der Reihenfolge aus, in der Module beim Hook registriert sind, was Sie über die Seite Design, Positionen im Back-Office steuern können. Verschieben Sie Ihr benutzerdefiniertes Modul unter das Zielmodul auf dem actionFrontControllerSetMedia-Hook, um sicherzustellen, dass Ihre Unregister-Aufrufe nach der Asset-Registrierung des Zielmoduls erfolgen.

Wenn das problematische Modul die älteren addCSS- und addJS-Methoden anstelle von registerStylesheet und registerJavascript verwendet, funktionieren die Unregister-Methoden möglicherweise nicht, da die älteren Methoden nicht dasselbe Asset-Management-System verwenden. In diesem Fall benötigen Sie einen anderen Ansatz.

Methode 3: Benutzerdefiniertes Modul zum Blockieren bestimmter Assets

Wenn Sie eine feinkörnige Kontrolle darüber benötigen, welche Assets auf welchen Seiten geladen werden, ist die Erstellung eines dedizierten Asset-Manager-Moduls die flexibelste Lösung. Dieses Modul dient als zentrale Stelle, an der Sie Regeln zum Blockieren oder Zulassen bestimmter Modul-Assets definieren.

Erstellen Sie ein neues Modul mit einer hookActionFrontControllerSetMedia-Methode. Definieren Sie innerhalb dieser Methode ein Array von Asset-Regeln. Jede Regel gibt einen Modulnamen, die zu blockierenden Asset-IDs und die Bedingungen an, unter denen sie blockiert werden sollen. Die Bedingungen können auf dem Controller-Namen, dem Seitentyp oder jedem anderen im PrestaShop-Kontext verfügbaren Kriterium basieren.

Ihr Modul durchläuft die Regeln bei jedem Seitenaufruf, prüft die Bedingungen und ruft Media::unregisterStylesheet oder Media::unregisterJavascript für jedes Asset auf, das auf der aktuellen Seite blockiert werden soll. Dieser zentralisierte Ansatz ist viel einfacher zu warten, als Asset-Entfernungslogik über mehrere Module oder Theme-Dateien zu verstreuen.

Sie können dieses Modul mit einer Back-Office-Konfigurationsseite erweitern, die es Ihnen ermöglicht, die Regeln über die PrestaShop-Admin-Oberfläche zu verwalten, anstatt Code zu bearbeiten. Ein einfaches Formular mit Feldern für Modulname, Asset-ID und einer Mehrfachauswahl für Seitentypen, auf denen das Asset blockiert werden soll, gibt Ihnen eine benutzerfreundliche Möglichkeit, das Asset-Laden zu verwalten, ohne nach der Ersteinrichtung Code anfassen zu müssen.

Dieser Ansatz funktioniert sowohl mit dem neuen registerStylesheet-System als auch mit dem älteren addCSS-System, wobei Sie für jedes möglicherweise unterschiedliche Techniken anwenden müssen. Für Assets, die mit dem neuen System registriert wurden, verwenden Sie die Media::unregister-Methoden. Für Assets, die mit dem älteren System hinzugefügt wurden, können Sie die css_files- und js_files-Arrays des Controllers direkt in der hookActionFrontControllerSetMedia-Methode manipulieren.

Methode 4: Der Hook-Abhänge-Ansatz

Ein aggressiverer, aber manchmal notwendiger Ansatz besteht darin, ein Modul vollständig von den Hooks abzuhängen, bei denen es seine Assets registriert. Gehen Sie zu Design, dann Positionen in Ihrem Back-Office. Finden Sie das Modul auf dem displayHeader- oder actionFrontControllerSetMedia-Hook. Klicken Sie auf den Löschen- oder Abhängen-Button, um das Modul vollständig von diesem Hook zu entfernen.

Dies verhindert, dass das Modul überhaupt Assets lädt, auf jeder Seite. Die anderen Hooks des Moduls, wie displayProductAdditionalInfo oder displayFooter, funktionieren weiterhin normal. Die Front-Office-Ausgabe des Moduls kann jedoch fehlerhaft werden, wenn sie von ihrem CSS für die Gestaltung oder ihrem JavaScript für interaktives Verhalten abhängt.

Dieser Ansatz ist besonders nützlich, wenn Sie die Gestaltung des Moduls vollständig durch Ihr eigenes benutzerdefiniertes CSS ersetzen möchten. Sie hängen das Modul von displayHeader ab, um das Laden seines CSS zu verhindern, und schreiben dann Ihre eigenen Stile in der benutzerdefinierten CSS-Datei Ihres Themes, die auf die HTML-Elemente des Moduls abzielen. Dies gibt Ihnen die vollständige Kontrolle über das Erscheinungsbild des Moduls ohne Konflikte zwischen den Originalstilen und Ihren Anpassungen.

Für JavaScript ist das Abhängen riskanter. Wenn das Modul auf sein JavaScript für Kernfunktionalität wie AJAX-Aufrufe, Formularvalidierung oder dynamisches Laden von Inhalten angewiesen ist, werden diese Funktionen durch das Entfernen des JavaScripts nicht mehr funktionieren. Hängen Sie JavaScript nur ab, wenn Sie sicher sind, dass die Front-Office-Ausgabe des Moduls nicht davon abhängt, oder wenn Sie eine Ersatzimplementierung über Ihr Theme bereitstellen.

Ein wichtiger Vorbehalt: Wenn Sie das Modul aktualisieren, kann der Aktualisierungsprozess das Modul erneut bei den Hooks registrieren, von denen Sie es entfernt haben. Prüfen Sie nach jeder Modulaktualisierung unter Design, Positionen, ob Ihre Abhängung noch wirksam ist. Manche Module registrieren ihre Hooks während des Aktualisierungsprozesses explizit neu, was Ihre manuelle Abhängung überschreibt.

Methode 5: Modul-Assets über Ihr Theme überschreiben

PrestaShops Theme-System ermöglicht es Ihnen, Modul-Template-Dateien zu überschreiben, indem Sie sie im modules-Verzeichnis Ihres Themes platzieren. Obwohl dies primär für Template-Überschreibungen verwendet wird, können Sie es auch nutzen, um das Asset-Laden indirekt zu steuern.

Wenn ein Modul seine Assets über seine Template-Dateien lädt, indem es Smarty-Funktionen wie Script- oder Stylesheet-Tags direkt in TPL-Dateien verwendet, anstatt über PHP-Hooks, können Sie diese Templates in Ihrem Theme überschreiben und die Asset-Referenzen entfernen. Kopieren Sie die Template-Datei des Moduls in das modules-Verzeichnis Ihres Themes unter Beibehaltung der gleichen Verzeichnisstruktur und bearbeiten Sie die Kopie, um die unerwünschten CSS- oder JavaScript-Referenzen zu entfernen.

Dieser Ansatz ist theme-spezifisch, das heißt, er betrifft nur das aktuelle Theme. Wenn Sie das Theme wechseln, werden die Überschreibungen nicht übernommen. Er erfordert auch Wartung: Wenn das Modul seine Templates aktualisiert, müssen Sie Ihre Überschreibungen aktualisieren, um strukturelle Änderungen zu übernehmen und gleichzeitig Ihre Asset-Entfernungs-Modifikationen beizubehalten.

Für Module, die Assets über PHP-Hooks statt über Templates laden, helfen Theme-Template-Überschreibungen nicht beim Asset-Blockieren. Verwenden Sie in diesem Fall eine der anderen in diesem Artikel beschriebenen Methoden.

PrestaShop 1.7 vs. 8.x: Unterschiede im Ansatz

PrestaShop 8.x verfeinerte das in 1.7 eingeführte Asset-Management-System, aber die grundlegenden Ansätze bleiben gleich. Die Hauptunterschiede liegen in der internen Implementierung und einigen zusätzlichen Funktionen.

In PrestaShop 1.7 verwendet das Asset-Management-System registerStylesheet und registerJavascript mit einem Prioritätssystem. Die Methoden Media::unregisterStylesheet und Media::unregisterJavascript funktionieren zuverlässig für Assets, die über dieses System registriert werden. Module, die noch die veralteten addCSS- und addJS-Methoden verwenden (die veraltet, aber weiterhin funktionsfähig sind), durchlaufen jedoch nicht das neue Asset-Management-System, was es schwieriger macht, sie sauber zu entfernen.

PrestaShop 8.x verbesserte die Abwärtskompatibilität, sodass auch Assets, die über die veralteten Methoden hinzugefügt werden, durch die neue Asset-Pipeline verarbeitet werden. Das bedeutet, dass die Media::unregister-Methoden konsistenter über alle Module hinweg funktionieren, unabhängig davon, welche Registrierungsmethode sie verwenden. Wenn Sie PrestaShop 8.x verwenden, ist der Unregister-Ansatz die zuverlässigste Methode für alle Module.

PrestaShop 8.x führte auch ein verbessertes Cache-Busting für Assets ein, was bedeutet, dass Änderungen nach dem Löschen des Caches sofort wirksam werden, ohne dass Kunden veraltete gecachte Versionen sehen. In PrestaShop 1.7 musste man manchmal sowohl den PrestaShop-Cache als auch den Browser-Cache löschen oder warten, bis das Combine-Compress-Cache (CCC)-System die kombinierten Dateien neu generiert hatte.

Beide Versionen unterstützen den theme.yml-Ansatz zur Asset-Entfernung, und die Syntax ist identisch. Wenn Sie ein benutzerdefiniertes Modul für das Asset-Management schreiben, funktioniert derselbe Code auf beiden Versionen 1.7 und 8.x mit minimalen Unterschieden.

Leistungsgewinne nach dem Deaktivieren von Assets messen

Nach dem Deaktivieren von Modul-Assets sollten Sie die Leistungsverbesserung messen, um zu bestätigen, dass Ihre Änderungen den erwarteten Effekt hatten. Verwenden Sie eine Kombination von Tools für eine umfassende Messung.

Beginnen Sie mit dem Netzwerk-Tab der Chrome DevTools. Vergleichen Sie die Gesamtzahl der Anfragen und die gesamte übertragene Größe vor und nach Ihren Änderungen. Filtern Sie nach CSS und JS, um die spezifische Reduzierung der Stylesheet- und JavaScript-Dateianzahl und -größen zu sehen. Eine sinnvolle Optimierung sollte eine deutliche Reduzierung sowohl der Anfragenanzahl als auch der Gesamtgröße zeigen.

Führen Sie ein Lighthouse-Performance-Audit vor und nach der Änderung durch. Konzentrieren Sie sich auf die Metriken, die am stärksten vom CSS- und JavaScript-Laden beeinflusst werden: First Contentful Paint wird durch render-blockierendes CSS beeinflusst, Largest Contentful Paint durch das gesamte Ressourcenladen und Total Blocking Time durch JavaScript-Parsing und -Ausführung. Erfassen Sie diese Metriken aus mindestens drei Durchläufen und vergleichen Sie die Durchschnittswerte.

Verwenden Sie den Coverage-Tab in den Chrome DevTools, um die CSS- und JavaScript-Nutzung zu messen. Öffnen Sie den Coverage-Tab über das Drei-Punkte-Menü unter Weitere Tools und laden Sie dann die Seite neu. Der Coverage-Tab zeigt Ihnen, wie viel von jeder CSS- und JavaScript-Datei auf der aktuellen Seite tatsächlich verwendet wird. Dateien mit hohem Anteil ungenutzten Codes (rot angezeigt) sind Kandidaten für Entfernung oder bedingtes Laden. Nach dem Deaktivieren von Modul-Assets sollten die verbleibenden Dateien höhere Nutzungsprozentsätze aufweisen, was darauf hinweist, dass Sie Verschwendung erfolgreich beseitigt haben.

Berücksichtigen Sie auch Realwelt-Metriken von Ihrer Analytics-Plattform. Wenn Sie Google Analytics oder ein ähnliches Tool verwenden, vergleichen Sie die Seitenladezeiten für eine Woche vor und nach Ihrer Optimierung. Reale Daten von tatsächlichen Besuchern auf verschiedenen Geräten und unter verschiedenen Netzwerkbedingungen geben Ihnen das genaueste Bild der Leistungsverbesserung.

Risiken und Kompatibilitätsbedenken

Das Deaktivieren von Modul-Assets birgt Risiken, die Sie verstehen und managen müssen. Das häufigste Risiko ist visueller Bruch. Wenn Sie das CSS eines Moduls entfernen, verlieren seine HTML-Elemente ihre Gestaltung und können fehlerhaft angezeigt werden. Dies kann von geringfügigen kosmetischen Problemen wie falschen Farben oder Abständen bis hin zu schwerwiegenden Layout-Problemen wie überlappenden Elementen oder unsichtbaren Inhalten reichen.

Das Entfernen von JavaScript birgt ein höheres Risiko. Moderne Module hängen oft von ihrem JavaScript für Kernfunktionalität ab. Das Entfernen von JavaScript kann dazu führen, dass Funktionen vollständig aufhören zu arbeiten: Buttons, die nicht auf Klicks reagieren, Formulare, die nicht abgesendet werden, Popups, die sich nicht öffnen, AJAX-Inhalte, die nicht geladen werden. Testen Sie immer jede Funktion eines Moduls, nachdem Sie sein JavaScript entfernt haben.

Es gibt auch ein Kompatibilitätsrisiko bei Modul-Updates. Wenn ein Modul aktualisiert wird, kann der Entwickler neue CSS- oder JavaScript-Dateien mit anderen Asset-IDs hinzufügen. Ihre Entfernungsregeln, ob in der theme.yml oder einem benutzerdefinierten Modul, erfassen die neuen Assets möglicherweise nicht, weil sie auf die alten Asset-IDs abzielen. Überprüfen Sie nach jedem Modul-Update, ob Ihre Asset-Blockierung noch korrekt funktioniert, und aktualisieren Sie Ihre Regeln bei Bedarf.

Manche Module führen Feature-Erkennung in ihrem JavaScript durch und verhalten sich anders, wenn ihr CSS nicht geladen ist. Ein Modul könnte die Existenz bestimmter CSS-Klassen oder berechneter Stile prüfen, bevor es seine JavaScript-Funktionalität initialisiert. Das Entfernen des CSS ändert in diesem Fall nicht nur das Erscheinungsbild, sondern bricht auch das JavaScript-Verhalten, das von diesen CSS-definierten Zuständen abhängt.

Beachten Sie schließlich Abhängigkeiten zwischen Modulen. Modul A könnte eine JavaScript-Bibliothek wie ein Lightbox-Plugin laden, das Modul B ebenfalls verwendet, aber selbst nicht lädt, weil es davon ausgeht, dass Modul A sie bereitstellt. Das Entfernen der JavaScript-Dateien von Modul A würde in diesem Szenario beide Module beschädigen. Prüfen Sie auf gemeinsame Abhängigkeiten, bevor Sie Assets entfernen.

Ein praktischer Workflow für sichere Asset-Entfernung

Befolgen Sie diesen Workflow, um Modul-Assets sicher zu deaktivieren, ohne Ihren Shop zu beschädigen. Erstens: Dokumentieren Sie Ihren aktuellen Zustand. Machen Sie Screenshots von jedem Seitentyp, auf dem das Modul Inhalte anzeigt. Erfassen Sie Lighthouse-Scores und Netzwerk-Tab-Statistiken. Dies gibt Ihnen eine Ausgangsbasis zum Vergleichen und eine Referenz dafür, wie das Modul aussehen und funktionieren sollte.

Zweitens: Identifizieren Sie die spezifischen Assets, die Sie entfernen möchten. Verwenden Sie DevTools, um die genauen Dateinamen und Asset-IDs zu finden. Bestimmen Sie, welche Seiten die Assets benötigen und welche nicht.

Drittens: Implementieren Sie die Entfernung mit der am besten geeigneten Methode aus diesem Artikel. Für einfache globale Entfernung verwenden Sie theme.yml. Für bedingte Entfernung basierend auf dem Seitentyp erstellen Sie ein benutzerdefiniertes Modul mit Media::unregister-Aufrufen. Für einen vollständigen Asset-Ersatz hängen Sie das Modul ab und stellen Ihre eigenen Stile bereit.

Viertens: Testen Sie gründlich. Prüfen Sie jeden Seitentyp, auf dem das Modul Inhalte anzeigen sollte. Überprüfen Sie, dass das visuelle Erscheinungsbild des Moduls korrekt ist und alle interaktiven Funktionen funktionieren. Prüfen Sie Seiten, auf denen Sie die Assets entfernt haben, um zu bestätigen, dass sie nicht mehr geladen werden. Testen Sie auf mehreren Browsern und Geräten.

Fünftens: Messen Sie die Leistungsverbesserung. Führen Sie Lighthouse-Audits durch und vergleichen Sie mit Ihrer Ausgangsbasis. Prüfen Sie den Netzwerk-Tab auf reduzierte Anfragenzahlen und -größen. Wenn die Verbesserung signifikant ist, war Ihre Optimierung erfolgreich. Wenn die Verbesserung minimal ist, waren die entfernten Assets möglicherweise nicht der Hauptleistungsengpass, und Sie sollten andere Optimierungsmöglichkeiten untersuchen.

Sechstens: Dokumentieren Sie Ihre Änderungen. Notieren Sie, welche Assets Sie entfernt haben, welche Methode Sie verwendet haben und welche Seiten betroffen sind. Diese Dokumentation ist unerlässlich für die Fehlerbehebung zukünftiger Probleme, insbesondere nach Modul-Updates, und für den Wissenstransfer, falls jemand anderes den Shop wartet.

Indem Sie diesem systematischen Ansatz folgen, können Sie das Seitengewicht Ihres Shops sicher reduzieren und die Ladezeiten verbessern, ohne auf die Modulfunktionalität zu verzichten, auf die Ihr Shop angewiesen ist. Der Schlüssel ist immer Testen und Messen: Gehen Sie nie davon aus, dass das Entfernen eines Assets sicher ist, und überprüfen Sie die Ergebnisse immer mit konkreten Daten.