Nicht bösartig. Nur nachlässig — was ein PrestaShop-Modul mit den Schlüsseln zu Ihrem Shop anrichtet
Ein kostenpflichtiges PrestaShop-Modul, das wir im Shop eines Kunden fanden, lud auf jeder einzelnen Seite eine dekorative Schriftart von einem fremden CDN nach — auf der Startseite, in jeder Kategorie, auf jedem Produkt, im Warenkorb, im Checkout. Genutzt wurde die Schrift an genau einer Stelle: auf der eigenen Einstellungsseite des Moduls, tief im Back-Office, wo im Unternehmen vielleicht eine einzige Person je hinsah.
Was diese Nachlässigkeit tatsächlich kostete, haben wir auf der Live-Startseite gemessen. Das Modul fügte eine neue Fremddomain, drei zusätzliche Requests pro Seite (ein Stylesheet und zwei Schriftdateien) sowie rund 159 KB Gewicht hinzu, das kein Browser eines Besuchers brauchte. Weil das Stylesheet im <head> der Seite lag, blockierte es das Rendering: Jeder Erstbesucher wartete auf einen DNS-Lookup und einen TLS-Handshake zu einem Server, von dem der Shop-Betreiber noch nie gehört hatte, bevor die Seite fertig gezeichnet werden konnte. Auf einer gedrosselten Mobilverbindung rutschte der Largest Contentful Paint von 2,4 auf 2,9 Sekunden, und der Lighthouse-Performance-Score fiel aus den unteren 90ern in die Mitte der 80er. Nicht katastrophal. Nur eine Steuer, still erhoben auf jeden Seitenaufruf, für immer, für eine Schrift, die außerhalb der Verwaltung nie jemand zu sehen bekam.
Der Wirkungsradius war der ganze Shop; die Funktion war ein einziger Bildschirm. Genau diese Lücke — zwischen dem, was ein Modul berührt, und dem, wofür es eigentlich da ist — ist das ganze Thema dieses Artikels. Wir begrenzten das Asset so, dass die Schrift nur noch auf der Seite lädt, die sie verwendet, und die Zahlen waren wieder auf Ausgangsniveau. Die Korrektur kostete einen Nachmittag. Zu bemerken, dass das Problem überhaupt bestand, kostete einen Browser und eine Gewohnheit.
Dieses Modul war keine Malware. Das ist der Punkt. Niemand wollte jemandem schaden. Ein Entwickler wollte, dass seine Einstellungsseite gut aussieht, griff zu einer Schrift und fügte das CDN-Snippet ein, das die Website der Schrift ihm gab — und registrierte dann, aus derselben Copy-and-paste-Gewohnheit heraus, dasselbe Stylesheet zusätzlich am globalen Front-Office-Header-Hook, obwohl nur die Einstellungsseite es überhaupt nutzte. Jede Entscheidung war für sich klein und vernünftig. Die Summe war eine shopweite Performance-Verschlechterung, die kein „aber es ist doch nur ein kleines Modul“ vorhergesagt hätte. Nachlässigkeit genügte. Sie genügt meistens.
Wenn Sie sehen wollen, wie wenig dazu nötig ist, hier die Gestalt des Fehlers — nachgebaut, nicht der Originalcode des Anbieters. Die Einstellungsseite selbst lädt diese Schrift im Back-Office völlig einwandfrei; der Schaden entstand durch eine zweite, überflüssige Zeile, die dasselbe Stylesheet zusätzlich am Front-Office-Header-Hook registrierte — jenem, der auf jeder Storefront-Seite feuert, wo nichts es verwendet:
// Runs on EVERY page of the storefront — home, category, product, checkout
public function hookDisplayHeader($params)
{
// …yet nothing on the storefront uses this font — the settings screen loads it itself.
$this->context->controller->addCSS(
'https://3p-cdn.net/fancy-display/style.css' // third-party, render-blocking
);
}Nichts daran ist böswillig; es sind eine Handvoll Zeilen, die genau das tun, was sie sagen. Das Problem ist, dass dieser Hook nichts mit der Einstellungsseite zu tun hat, für die die Schrift gedacht ist. displayHeader rendert auf der Storefront, also wird eine Schrift, die für eine einzige Admin-Seite gedacht war, von jedem Käufer heruntergeladen — für nichts. Die Korrektur besteht darin, die Storefront-Registrierung ganz zu streichen und das Back-Office die Schrift dort laden zu lassen, wo sie tatsächlich gebraucht wird:
// The storefront never shows this font, so the front-office hook loads nothing.
public function hookDisplayHeader($params)
{
return;
}
// It loads only on this module's own settings screen in the back office —
// self-hosted, so no third-party domain and no extra DNS + TLS round-trip.
public function hookDisplayBackOfficeHeader($params)
{
if (Tools::getValue('configure') !== $this->name) {
return; // every other admin page pays nothing either
}
$this->context->controller->addCSS($this->_path.'views/css/fancy-display.css');
}Gleiche Funktion, gleiche Schrift — die Storefront lädt jetzt nichts, was sie nicht verwendet, und die shopweite Steuer verschwindet zusammen mit der Fremddomain. Diese Lücke zwischen den beiden Versionen ist der ganze Unterschied zwischen einem Modul, das in seiner Spur bleibt, und einem, das jede Seite still für eine Funktion belastet, die fast niemand sieht. Niemand musste absichtlich nachlässig sein.
Das Problem ist, dass Module vorgeben, Apps zu sein
Die meisten Händler denken über Module so, wie sie über Handy-Apps denken. Eine App ist sandboxed: Sie läuft in ihrem eigenen ummauerten Garten, sie kann nicht in andere Apps hineingreifen, und wenn sie Ihnen nicht gefällt, löschen Sie sie, und Ihr Handy ist genau wie zuvor. Dieses gedankliche Modell ist bequem, und für PrestaShop ist es völlig falsch.
Ein PrestaShop-Modul ist keine sandboxed App. Es ist nicht abgeschottetes PHP, das mit den vollen Rechten Ihres Shops läuft. Einmal installiert und aktiviert, kann es sich in jede Seite einklinken, die gerendert wird, jede Tabelle in Ihrer Datenbank lesen und schreiben — Bestellungen, Kunden, Preise, Konfiguration —, Overrides registrieren, die still das Kernverhalten ersetzen, Dateien in Ihr Theme ablegen, Spalten und Tabellen hinzufügen, Hintergrundjobs planen und in Ihrem Namen externe Dienste aufrufen. Es ist kein Gast in einem ummauerten Garten. Es ist ein Mitarbeiter mit Schlüsseln zum ganzen Gebäude, und Sie haben ihn per Klick auf „Installieren“ eingestellt.
Ein Modul ist keine Funktion, die Sie einschalten. Es ist Code, dem Sie die Schlüssel zu Ihrem Shop übergeben. Die Frage lautet nie „Ist diese Funktion schön“ — sie lautet „Traue ich diesem Code alles zu, was mein Shop kann.“
Nichts davon ist ein Fehler in PrestaShop. Genau diese Macht ist der Grund, warum die Plattform erweiterbar genug ist, um ein ernsthaftes Geschäft darauf zu betreiben. Aber es bedeutet, dass das Sicherheitsmodell, das Sie im Kopf tragen — das App-Modell —, Sie vor nichts schützt.
Konkret gesagt: Ein einziges aktiviertes Modul kann all das auf einmal erreichen — es klinkt sich in jede Seite ein, die gerendert wird, fügt Datenbanktabellen hinzu und verändert sie, legt Override-Dateien über Kernklassen, bearbeitet Ihr Theme, lädt Assets shopweit, plant Hintergrundjobs, liest und schreibt Ihre Bestellungen und Kundendaten und ruft externe Dienste auf. Eine App auf Ihrem Handy kann nichts davon mit dem Handy tun. Ein PrestaShop-Modul kann all das mit Ihrem Shop tun — weshalb „einfach installieren und schauen“ eine größere Entscheidung ist, als sie aussieht.
„In meinem Testshop hat es funktioniert“ ist der Anfang des Ärgers
Die teuersten vier Worte in der Modulentwicklung sind „bei mir hat’s funktioniert“. Ein Entwickler baut ein Modul, installiert es in einem sauberen Testshop, klickt sich durch, sieht es laufen und liefert aus. Das Problem ist, dass ein sauberer Testshop nichts mit einem echten Shop gemein hat.
Ihr echter Shop hat ein eigenes Theme, das Templates überschreibt, die das Modul voraussetzte. Er läuft womöglich im Multishop-Betrieb, wo ein Modul, das nur gegen Shop 1 getestet wurde, in Shop 2 still fehlläuft. Er läuft auf einer bestimmten PHP-Version, die älter oder neuer sein kann als die des Entwicklers. Er hat Dutzende anderer Module, die sich bereits an dieselben Seiten hängen und um dieselbe Ausgabe konkurrieren. Er hat echten Traffic, eine Cache-Schicht, einen Live-Checkout, der echtes Geld einnimmt, und — das Wichtigste — er wird eines Tages aktualisiert, auf eine neue PrestaShop-Version, gegen die das Modul nie getestet wurde. „Es hat einmal funktioniert, in einem Shop, in einer Version“ ist keine Garantie für irgendetwas. Ein Modul muss über all das hinweg weiterlaufen, jahrelang. Das ist ein grundsätzlich schwierigeres Versprechen als „es funktioniert“, und der Großteil des Risikos steckt in diesem Unterschied. Es ist auch der Grund, warum Modulqualität wichtiger ist als Modulmenge, und die verborgene Hälfte davon, was PrestaShop wirklich langsam macht.
Was übrig bleibt, wenn Sie deaktivieren oder deinstallieren
Hier ist die Überzeugung, die den größten Schaden anrichtet: „Wenn es Probleme macht, deinstalliere ich es einfach, und alles ist wieder normal.“ Manchmal stimmt das. Oft nicht, und den Unterschied lohnt es sich genau zu verstehen — denn die selbstsichere Version dieser Behauptung ist der Weg, auf dem Shops still kaputtgehen.
Deaktivieren eines Moduls verhindert, dass seine Laufzeit-Hooks feuern. Das hilft wirklich: Das Modul injiziert seine Assets nicht mehr und führt seinen Code nicht mehr auf jeder Seite aus, sodass ein akutes Performance- oder Anzeigeproblem meist sofort nachlässt. Deaktivieren ist im Notfall der richtige erste Schritt. Aber Deaktivieren greift nicht zurück, um etwas rückgängig zu machen, das das Modul bereits getan hat.
Deinstallieren geht weiter und führt die eigene Aufräumroutine des Moduls aus — und diese Routine entfernt nur, was ihr Autor sich die Mühe gemacht hat, per Code zu entfernen. Was nicht zuverlässig von allein zurückkommt:
- Datenbank- und Konfigurationsänderungen. Neue Tabellen, neue Spalten und Konfigurationszeilen können zurückbleiben. Manche Module behalten Ihre Daten bei der Deinstallation absichtlich, damit Sie bei einer Neuinstallation keine Einstellungen verlieren — eine vertretbare Wahl, aber nur, wenn sie es Ihnen sagen.
- Bestell- und Kundendaten. Alles, was im normalen Betrieb in Ihre Bestellungen, Rechnungen oder Kundendaten geschrieben wurde, sind Ihre laufenden Geschäftsdaten. Das Deinstallieren des Moduls löscht sie nicht und sollte es auch nicht — aber es kann sie in einer Form zurücklassen, die nur dieses Modul verstand.
- Overrides und Theme-Änderungen. Dateien, die in
/overrideoder in Ihr Theme abgelegt wurden, können das Modul überdauern. Ein veralteter Override, der nach der Deinstallation an Ort und Stelle bleibt, ist eine klassische Quelle für „mein Shop ist kaputt, und nichts, was ich deaktiviert habe, hat es behoben“. - Externe Integrationen. Daten, die das Modul an einen Drittanbieterdienst geschickt hat — einen Feed, ein CRM, eine Analyse- oder Marketing-Plattform —, sind der Kontrolle Ihres Shops bereits entzogen. Die Deinstallation ändert am anderen Ende nichts.
Der korrekte Satz lautet also: Deaktivieren stoppt die Blutung, aber Deinstallieren macht die Datenbankschreibvorgänge, Konfigurationsänderungen, Bestell- und Kundendaten, Overrides, Theme-Änderungen oder externen Aufrufe, die ein Modul bereits getätigt hat, nicht rückgängig. „Ich deinstalliere es einfach“ ist ein Plan für die Funktion. Es ist kein Plan für den Fußabdruck.
Es hilft, sich die drei Zustände nebeneinander vorzustellen. Deaktivieren stoppt das Laufen des Moduls. Deinstallieren führt seine Aufräumroutine aus. Aber eine ganze Spalte an Dingen — Daten, die in Ihre Bestellungen und Kunden geschrieben wurden, Konfiguration, Overrides, Theme-Änderungen und alles, was bereits an einen externen Dienst gesendet wurde — überlebt beides, es sei denn, der Autor des Moduls hat Code geschrieben, um sie rückgängig zu machen, und Sie haben bestätigt, dass er es getan hat. Genau diese letzte Spalte überrascht die Leute im denkbar schlechtesten Moment.
Diesen Fehler haben wir auch schon gemacht
Es wäre unehrlich, all das so zu schreiben, als passiere es nur anderen. Tut es nicht. Wir bauen und verkaufen PrestaShop-Module als Broterwerb, und wir haben dieselbe Art von Fehler gemacht.
Bei einem unserer eigenen Module wurde ein Front-Office-Skript, das nur eine einzige Funktion brauchte, an einem Hook registriert, der auf jeder Seite feuert, statt nur auf den Controllern, wo die Funktion tatsächlich erscheint. Funktional lief alles, also bestand es die Prüfung und wurde ausgeliefert. Erst ein Performance-Audit Monate später — dieselbe Art von Audit wie in diesem Artikel — ertappte ein kleines Skript, das ohne Grund shopweit auf Seiten lud, die es nie nutzten. Der Preis war nicht dramatisch: ein paar Kilobyte und ein wenig Parse-Zeit auf jeder Seite, über den ganzen Katalog hinweg, bis wir es behoben. Aber er war real, er war unser, und „es funktioniert“ hatte es glatt durchgewunken.
Was sich änderte, war keine Belehrung darüber, sorgfältiger zu sein. Wir machten daraus eine Frage, die die Prüfung für jedes Asset und jeden Hook beantworten muss: Muss das wirklich global sein, oder gehört es auf die Seiten, die es verwenden? Eine Narbe wird zur Regel, und die Regel fängt die nächste ab. Das ist die ehrliche Version von Qualität — nicht „wir machen nie Fehler“, sondern „wir haben das Ding gebaut, das sie abfängt, bevor Sie es tun“. Es ist dieselbe Disziplin, die dahintersteckt, einen echten Shop mit 80+ Modulen auf einen PageSpeed-Score von 99 zu bringen: nicht weniger Module, sondern Module, die in ihrer Spur bleiben — was der gesamte Entwurfsauftrag unserer Performance Revolution-Suite ist.
Ist dann nicht die KI der Bösewicht hier?
Sie erwarten vielleicht, dass ein Modulanbieter das Ganze mit einer Schuldzuweisung an die KI beendet — billiger, KI-generierter Code, der den Markt mit Schrott flutet. Werden wir nicht, denn es wäre zugleich unfair und heuchlerisch. Wir setzen selbst stark auf KI-gestützte Entwicklung. Genau deshalb beurteilen wir ein Modul nicht danach, ob eine KI daran beteiligt war.
KI ist ein Beschleuniger. Sie macht gute Entwicklung schneller, und sie macht nachlässige Entwicklung schneller, und sie hat keine Meinung dazu, welche von beiden Sie gerade betreiben. Den Fehler mit der Schrift auf jeder Seite gab es schon ein Jahrzehnt vor der aktuellen KI-Welle; ein gehetzter Mensch hat reichlich davon geschrieben. Was ein Modul, dem Sie vertrauen können, von einem unterscheidet, dem Sie nicht vertrauen können, waren nie die Werkzeuge des Autors. Es ist die Governance: Gibt es einen benannten Verantwortlichen, wird der Code geprüft, ist er getestet, wird er kompatibel gehalten, während sich PrestaShop weiterbewegt, lassen sich seine Änderungen rückgängig machen, bleibt er innerhalb seines Performance-Budgets, wird ihn jemand nächstes Jahr pflegen. Diese Fragen sind genau gleich gültig, egal ob der Code von einem Menschen getippt, von einem Modell generiert oder — wie es jetzt normal ist — von einem Menschen und einem Modell gemeinsam geschrieben wurde. Verantwortung, Prüfung und Tests sind das Thema. Autorschaft ist eine Ablenkung.
Beurteilen Sie uns nach demselben Maßstab
Auch wir verkaufen Module, daher ließe sich all das leicht als „Kaufen Sie stattdessen bei uns“ lesen. Verlassen Sie sich nicht auf unser Wort — das ist der ganze Geist der Sache. Der faire Zug ist, jeden Anbieter, uns eingeschlossen, an denselben Maßstab zu halten, und die gute Nachricht ist, dass die meisten der wichtigen Prüfungen keinerlei PHP-Kenntnisse erfordern. Sie können sie in einem Browser auf einer Staging-Kopie Ihres Shops durchführen: das Modul installieren, den Netzwerk-Tab Ihres Browsers auf Ihrer Startseite öffnen (nicht auf der Seite des Moduls) und zählen, was sich geändert hat.
Wir haben das vollständige Vorgehen als allgemein verständliche Referenz aufgeschrieben — wie Sie ein PrestaShop-Modul prüfen, bevor Sie es in einem Live-Shop installieren — und wir meinen es als Werkzeug, das Sie ebenso bereitwillig gegen unseren Katalog wie gegen jeden anderen einsetzen sollen. Wenn Sie es lieber von jemandem durchführen lassen möchten, ist genau das die Aufgabe unserer Performance- und Sicherheits-Audits, und unser kostenloser Sicherheitsscan ist ein Einstieg ohne Kosten. Wenden Sie die Checkliste auf uns an. Uns wäre es lieber, Sie täten es.
Häufige Fragen
Löscht die Deinstallation eines Moduls alles, was es angelegt hat?
Nein — nicht zuverlässig. Das Deinstallieren führt die eigene Aufräumroutine des Moduls aus, die nur entfernt, was ihr Autor per Code zu entfernen angelegt hat. Datenbanktabellen, Konfigurationszeilen, Dateien in /override, Theme-Änderungen und alle bereits an einen externen Dienst gesendeten Daten können sämtlich überleben. Es sollte außerdem niemals Ihre Bestellungen oder Kundendaten löschen, denn das sind Ihre laufenden Geschäftsdaten. Gehen Sie davon aus, dass die Deinstallation die Funktion aufräumt, nicht den gesamten Fußabdruck.
Kann ein einziges Modul wirklich meinen ganzen Shop verlangsamen?
Ja. Wenn ein Modul Assets lädt oder Code an einem globalen Hook ausführt — einem, der auf jeder Seite feuert —, wird dieser Preis von jeder Seite bezahlt, auch von Ihrer Startseite und Ihrem Checkout, sogar von Seiten, auf denen die Funktion nie erscheint. Genau so hat eine Schrift, die für eine einzige Admin-Seite gedacht war, am Ende eine ganze Storefront besteuert.
Ist ein Modul unsicher, nur weil KI beim Schreiben geholfen hat?
Nein. KI ist ein Beschleuniger, kein Urteil. Was ein Modul vertrauenswürdig macht, sind Verantwortung, Prüfung, Tests, Kompatibilität, Umkehrbarkeit und Performance-Disziplin — und diese gelten, egal ob der Code von einem Menschen, einem Modell oder beiden geschrieben wurde. Beurteilen Sie die Governance, nicht die Autorschaft.
Wie prüfe ich ein Modul tatsächlich, bevor ich es installiere?
Auf einer Staging-Kopie installieren und beobachten, was sich ändert: neue Drittanbieter-Requests im Netzwerk-Tab Ihrer Startseite, neue Datenbanktabellen, ob der Checkout weiterhin funktioniert und ob es sich sauber deinstallieren lässt. Wir haben das vollständige Schritt-für-Schritt-Vorgehen aufgeschrieben als wie Sie ein PrestaShop-Modul prüfen, bevor Sie es installieren.
Die besten Module sind langweilig
Nach all den Kriegsgeschichten ist die Schlussfolgerung fast antiklimaktisch, und das ist der Punkt. Ein gutes Modul ist langweilig. Es tut die eine Sache, die es beworben hat. Seine Assets laden nur dort, wo sie verwendet werden. Es berührt nur die Daten, die es braucht, sagt Ihnen, was es behält, und räumt auf, was es kann. Es übersteht Ihr nächstes PrestaShop-Upgrade ohne Drama. Und das wahrste Zeichen seiner Qualität ist, dass Sie sechs Monate nach der Installation völlig vergessen haben, dass es da ist.
Aufregung ist in einem Modul fast immer das Geräusch von etwas, das auf einer Seite schiefgeht, die es nie hätte berühren dürfen. Langweilig ist das Ziel. Langweilig ist, wie „es funktioniert einfach“ von innen tatsächlich aussieht — und es lohnt sich, absichtlich danach zu prüfen, bevor ein Fremder mit den Schlüsseln zu Ihrem ganzen Shop einzieht.
Kommentare
Noch keine Kommentare. Seien Sie der Erste!
Stellen Sie als Erster eine Frage oder teilen Sie hilfreiches Feedback.
Kommentar schreiben
Teilen Sie eine Frage, ein Installationsdetail oder Feedback, das anderen Lesern helfen kann.