Die Modul-Risiko-Scorecard: 12 Prüfungen vor der Installation

Sie müssen keinen PHP-Code lesen können, um zu beurteilen, ob ein PrestaShop-Modul für Ihren Live-Shop sicher ist. Der größte Teil des Schadens, den ein schlechtes Modul anrichtet, ist über den Browser und Ihr Back Office sichtbar – wenn Sie wissen, wo Sie hinsehen müssen. Dies ist die Checkliste, die wir verwenden, geschrieben so, dass ein Shop-Betreiber sie ohne Entwickler durchgehen kann.

Der Gedanke dahinter ist einfach. Ein Modul ist nicht abgeschotteter Code, der mit den vollen Rechten Ihres Shops läuft: Es kann auf jeder Seite Assets laden, in Ihre Datenbank schreiben, das Kernverhalten verändern und andere Server ansprechen. Statt der Verkaufsseite zu vertrauen, beobachten Sie also, was das Modul tatsächlich tut – auf einer sicheren Kopie Ihres Shops – und bewerten es. Zehn von zwölf grünen Häkchen bedeuten ein Modul, das Sie mit Zuversicht installieren können. Doch die Punktzahl ist nicht die ganze Geschichte: Manche Zeilen sind harte Ausschlusskriterien. Ein Warnsignal beim Checkout oder bei Kundendaten, beim Umkehrbarkeitstest, bei einer neuen externen Domain oder bei nicht offengelegten Overrides bedeutet, dass das Modul von Ihrem Live-Shop fernbleibt, bis der Anbieter es erklärt – ganz gleich, was die übrigen Zeilen sagen.

Führen Sie dies zuerst auf einer Staging-Kopie durch – niemals auf dem Live-Shop. Duplizieren Sie Ihren Shop (die meisten Hoster bieten einen Staging-Klon per Klick an) oder verwenden Sie eine Wegwerf-Installation mit Ihrem Theme und Ihren übrigen Modulen. Das Modul soll auf dieselbe unaufgeräumte Realität treffen wie Ihr echter Shop: Ihr Theme, Ihre Sprach- und Währungseinrichtung, Ihre vorhandenen Module, Ihre PrestaShop- und PHP-Versionen. Ein Modul, das sich nur auf einer leeren Installation ordentlich verhält, sagt Ihnen etwas.

Die zwölf Prüfungen

1. Externe Domains und CDNs

So führen Sie sie durch: Öffnen Sie die Startseite Ihres Shops – nicht die Einstellungsseite des Moduls – in Ihrem Browser, drücken Sie F12, um die Entwicklertools zu öffnen, klicken Sie auf den Reiter Netzwerk und laden Sie die Seite neu. Sortieren Sie nach Domain. Notieren Sie jede Domain, die nicht Ihre ist. Installieren Sie nun das Modul und laden Sie erneut. Ist eine neue Drittanbieter-Domain aufgetaucht?

Bestanden: keine neuen externen Domains auf Seiten, die die Funktion nicht nutzen. Fehlerbild: Das ist genau die Falle aus unserem Essay – ein Modul, das auf jeder Seite eine Schriftart, ein Skript oder einen Tracker von einem fremden Server lädt und damit DNS-Abfragen, Gewicht, ein Datenschutzrisiko und eine Abhängigkeit von einem Server hinzufügt, den Sie nicht kontrollieren. Ist dieser Server eines Tages langsam oder ausgefallen, kann die Darstellung Ihres Shops mit ihm ins Stocken geraten oder sich verschlechtern.

Wenn Sie sie lieber exakt zählen möchten, statt die Liste mit dem Auge zu prüfen, fügen Sie dies in denselben Reiter Konsole der Entwicklertools ein und drücken Enter – es listet jede Domain auf, die nicht Ihre ist, und wie viele Anfragen jede gestellt hat:

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource')) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

Es zählt jeden Host, der nicht Ihre Hauptdomain ist – einschließlich etwaiger CDN-Subdomains, die Sie selbst betreiben und die Sie bedenkenlos ignorieren können. Führen Sie es vor der Installation des Moduls aus und danach erneut: Jeder wirklich neue Host ist ein neuer Dritter, von dem Ihr Shop nun abhängt.

Das ist die wertvollste Prüfung der Liste, denn sie fängt genau den Fehler aus unserem Essay ab: ein Modul, das jeder Seite unbemerkt eine Drittanbieter-Domain hinzufügt. Erscheint hier ein Host, den Sie nicht bewusst hinzugefügt haben, halten Sie inne und fragen Sie den Anbieter nach dem Grund, bevor er je Ihren Live-Shop erreicht.

2. Globale Front-Office-Assets

So führen Sie sie durch: Filtern Sie im selben Netzwerk-Reiter nach CSS und JS und vergleichen Sie die Anzahl auf Ihrer Startseite vor und nach der Installation. Prüfen Sie dann eine Seite, die das Modul beeinflussen soll, und eine, die es nicht betrifft.

Bestanden: Die Stylesheets und Skripte des Moduls werden nur auf den Seiten geladen, die sie nutzen. Fehlerbild: Ein „kleines“ Modul, das seine Assets an einem globalen Header-Hook registriert, belastet jede Seite des Shops – einschließlich des Checkouts – für eine Funktion, die auf einer einzigen Seite lebt. Multiplizieren Sie das mit einem Dutzend nachlässiger Module, und Sie haben einen langsamen Shop ohne einen einzelnen Schuldigen.

3. Overrides

So führen Sie sie durch: Schauen Sie vor der Installation per FTP oder über den Dateimanager Ihres Hosters in den Ordner /override Ihres Shops (Sie prüfen nur, ob Dateien auftauchen – Sie müssen sie nicht lesen). Installieren Sie das Modul und schauen Sie erneut nach.

Bestanden: keine neuen Dateien in /override (ein Standardordner enthält bereits Platzhalter-Dateien index.php – Sie suchen nach neuen). Fehlerbild: Overrides liegen in /override und verändern das Verhalten von PrestaShop-Kernklassen und -Controllern. Zwei Module, die dieselbe Klasse überschreiben, geraten in Konflikt – und, entscheidend, ein Override, der nach der Deinstallation zurückbleibt, ist eine der Hauptursachen für „mein Shop ist kaputt und das Deaktivieren hat es nicht behoben“. Gute Module nutzen Hooks und Services, statt den Kern zu überschreiben.

4. Verwendete Hooks

So führen Sie sie durch: Gehen Sie im Back Office zu Design › Positionen (die Hook-Ansicht) und sehen Sie sich an, wo sich das Modul registriert hat. Meist können Sie die Hooks eines Moduls auch auf seiner Konfigurationsseite einsehen.

Bestanden: Die Hooks passen zur Funktion. Ein Versandmodul hängt sich in Versand und Checkout ein; ein Produkt-Tab-Modul in die Produktseite. Fehlerbild: ein Modul, das sich in jede Seite einhängt – displayHeader, displayFooter überall – „für alle Fälle“, obwohl seine Funktion nur an einer Stelle erscheint. Jeder dieser Hooks ist Code, der bei jedem Seitenaufruf läuft.

5. Änderungen am Datenbankschema

So führen Sie sie durch: Notieren Sie im Datenbank-Werkzeug Ihres Hosters (phpMyAdmin oder Ähnliches) die Anzahl der Tabellen vor der Installation. Installieren Sie und sehen Sie nach, was hinzugefügt wurde – Sie prüfen Namen, nicht Inhalte.

Bestanden: Neue Tabellen sind klar dem Modul zugeordnet (ein erkennbares Präfix) und im Idealfall dokumentiert. Eine Handvoll gut benannter Tabellen ist völlig normal und in Ordnung. Fehlerbild: Ein Modul, das unbeschriftete Tabellen verstreut oder auf nicht offengelegte Weise in die Kerntabellen von PrestaShop schreibt, ist eines, das Sie später nicht sauber nachvollziehen können.

Wenn Sie Datenbankzugriff haben (phpMyAdmin oder die Kommandozeile), können Sie genau auflisten, was ein Modul hinzugefügt hat. Notieren Sie die Liste vor der Installation, führen Sie sie danach erneut aus und vergleichen Sie:

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables — list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

Eine kurze, klar präfixierte Liste ist gesund. Eine Streuung unbeschrifteter Tabellen – oder nicht offengelegte Schreibzugriffe auf Kerntabellen wie ps_orders oder ps_customer – ist das, wonach Sie Ausschau halten. (ps_ ist das Standard-Tabellenpräfix; setzen Sie Ihres ein, falls Sie es geändert haben, und verwenden Sie den technischen Namen des Moduls anstelle von mymodule.)

6. Aufräumen bei der Deinstallation

So führen Sie sie durch: Deinstallieren Sie nach Ihrer Schemaprüfung das Modul und sehen Sie sich die Datenbank erneut an. Was hat es entfernt und was zurückgelassen?

Bestanden: Das Modul entfernt, was es angelegt hat – oder legt in seiner Dokumentation klar dar, was es bewusst behält und warum (das Aufbewahren Ihrer Einstellungen für eine spätere Neuinstallation ist eine legitime Entscheidung, sofern offengelegt). Fehlerbild: stille Überbleibsel. Verwaiste Tabellen, Konfigurationszeilen und alte Dateien, die sich jedes Mal ansammeln, wenn Sie ein Modul testen. Das ist die Zeile, in der „Ich deinstalliere es einfach“ leise scheitert.

7. Cron-Jobs und Webhooks

So führen Sie sie durch: Prüfen Sie die Dokumentation und Konfigurationsseite des Moduls auf alles, was nach einem Zeitplan läuft oder im Hintergrund einen externen Dienst aufruft – Synchronisierungen, Feeds, Aufräumaufgaben, „Konto verbinden“-Integrationen.

Bestanden: Hintergrundaufgaben sind offengelegt, und Sie können sie abschalten. Fehlerbild: nicht offengelegte Hintergrundaktivität – eine Aufgabe, die Ihre Datenbank nach Zeitplan belastet, oder ein Webhook, der Ihre Daten irgendwohin schickt, ohne dass Sie es merken. Sie können nicht steuern, von dessen Existenz Sie nichts wissen.

8. Berührungspunkte mit Checkout, Bestellungen und Kundendaten

So führen Sie sie durch: Geben Sie mit dem im Staging installierten Modul eine vollständige Testbestellung von Anfang bis Ende auf. Suchen Sie nach einem Produkt. Öffnen Sie eine Produktseite. Öffnen Sie die wichtigsten Back-Office-Ansichten. Funktioniert alles noch genauso wie zuvor?

Bestanden: Checkout, Suche, Produktseiten und Verwaltung sind unbeeinträchtigt, es sei denn, das ist buchstäblich die Aufgabe des Moduls. Fehlerbild: Ein Modul, das den Bestellablauf oder Kundendatensätze berührt, berührt Ihren Umsatz und Ihre Compliance-Pflichten. Ein Checkout, der bricht – oder still falsch rechnet – kostet Sie echtes Geld an dem Tag, an dem er ausgeliefert wird, nicht im Labor.

9. Multishop, Sprache und Währung

So führen Sie sie durch: Wenn Sie mehr als einen Shop, mehr als eine Sprache oder mehr als eine Währung betreiben, testen Sie das Modul in jedem Fall. Wechseln Sie den Shop, die Sprache, die Währung und nutzen Sie die Funktion.

Bestanden: Das Modul respektiert Ihre Einrichtung – korrekt pro Shop, übersetzt pro Sprache, richtige Beträge pro Währung. Fehlerbild: Ein Modul, das gegen „Shop 1, Englisch, Euro“ gebaut und getestet wurde und diese Annahmen fest verdrahtet. Es sieht in der Demo gut aus und fällt bei Ihrem zweiten Shop oder den Preisen Ihrer polnischen Kunden auseinander.

10. PrestaShop- und PHP-Kompatibilität

So führen Sie sie durch: Lesen Sie die Kompatibilitätsangabe auf der Produktseite und gleichen Sie sie mit Ihrer PrestaShop-Version (1.7, 8.x oder 9.x) und Ihrer PHP-Version ab.

Bestanden: Der Anbieter nennt die genauen Versionen, die das Modul unterstützt, und hält das aktuell, wenn PrestaShop neue Versionen veröffentlicht. Fehlerbild: „kompatibel mit allen Versionen“. Kein ernstzunehmendes Modul wird gegen jede jemals ausgelieferte PrestaShop- und PHP-Version getestet; diese Behauptung ist Marketing, und es ist die Zeile, die am ehesten an dem Tag bricht, an dem Sie Ihren Shop aktualisieren.

11. Changelog und Support-Spur

So führen Sie sie durch: Suchen Sie vor dem Kauf nach einem datierten Changelog und einem echten Support-Kanal.

Bestanden: Das Modul hat eine sichtbare Historie von Aktualisierungen und einen Weg, einen Menschen zu erreichen, der es pflegt. Fehlerbild: kein Changelog und kein Support bedeutet keinen Eigentümer. Ein Modul ohne Wartung ist ein Modul, das bei einem PrestaShop- oder PHP-Upgrade irgendwann aufhört zu funktionieren, ohne dass jemand es repariert – und Sie erfahren es zum denkbar ungünstigsten Zeitpunkt.

12. Der Umkehrbarkeitstest

So führen Sie sie durch: Das ist die gesamte Checkliste in einer Bewegung, im Staging. Erstellen Sie eine Momentaufnahme Ihres Shops. Installieren Sie das Modul. Deaktivieren Sie es. Deinstallieren Sie es. Vergleichen Sie den Shop mit Ihrer Momentaufnahme.

Bestanden: Installieren → deaktivieren → deinstallieren lässt den Shop im Wesentlichen so, wie er war – keine übrig gebliebenen Dateien, keine verwaisten Tabellen, keine kaputten Seiten. Fehlerbild: alles, was nicht zurückkommt. Wenn ein Modul auf einer Testkopie nicht sauber entfernt werden kann, lässt es sich ganz sicher nicht sauber aus Ihrem Live-Shop unter Druck entfernen.

Warnsignale – und was jedes davon tatsächlich bedeutet

Sie werden nicht immer Zeit für alle zwölf haben. Dies sind die Abkürzungen – Signale, die für sich genommen einen viel genaueren Blick rechtfertigen. Jedes steht für eine konkrete Art, wie Dinge schiefgehen:

Keines davon ist ein Beweis, dass ein Modul schlecht ist. Günstiger und einfacher Code kann völlig gut sein; ein kleiner Anbieter kann hervorragend sein. Das Problem ist nie der Preis oder der Autor – es ist unverwaltetes Risiko. Ein Warnsignal bedeutet nur, dass das Risiko nicht für Sie verwaltet wurde, sodass Sie es selbst verwalten müssen, bevor es Ihren Live-Shop erreicht.

Wo die offiziellen Standards hineinpassen

PrestaShop selbst veröffentlicht die technischen Regeln, denen ein gut gebautes Modul folgen soll. Sie müssen sie nicht umsetzen, aber sie sind nützlich, um einen Anbieter darauf hinzuweisen, und sie decken sich mit vielem von dem, was oben steht. PrestaShop veröffentlicht die Technical Development Standards, denen ein gut gebautes Modul folgen soll – Override-Disziplin, Kerntabellen- und Asset-Performance-Hygiene, Sicherheit und Versionskompatibilität – neben den Quality Standards hinter dem Verified+-Abzeichen auf dem Addons-Marktplatz. Keiner davon ist für sich genommen eine Garantie – viele gute Module leben außerhalb des Marktplatzes, und ein Abzeichen ersetzt nicht die obigen Beobachtungen –, aber sie sind ein sinnvoller Teil des Gesamtbildes. Wenn Sie über den Marktplatz kaufen, erklärt unser PrestaShop-Addons-Käuferleitfaden, wie man ein Angebot liest.

Eine sichere Installationsreihenfolge, von Anfang bis Ende

Zusammengenommen ist das Ganze eine ruhige Abfolge:

• Sichern Sie Ihren Live-Shop – Dateien und Datenbank.
• Installieren Sie auf einer Staging-Kopie, die Ihr echtes Theme, Ihre Module und Einstellungen widerspiegelt.
• Erstellen Sie eine Momentaufnahme des Staging-Shops und führen Sie dann die zwölf Prüfungen oben durch.
• Beobachten Sie den Netzwerk-Reiter auf Ihrer Startseite auf neue Domains und shopweite Assets.
• Geben Sie eine Testbestellung auf und beanspruchen Sie Suche, Produktseiten und Verwaltung.
• Deinstallieren Sie und vergleichen Sie mit Ihrer Momentaufnahme – bestätigen Sie, dass er sauber zurückkommt.
• Erst dann installieren Sie im Live-Shop, während einer ruhigen Phase, und prüfen Ihre wichtigsten Seiten noch einmal.

Häufige Fragen

Brauche ich einen Entwickler, um ein Modul zu prüfen?

Für die meisten dieser Prüfungen nein. Drittanbieter-Anfragen zählen, den Checkout testen und den Test installieren → deaktivieren → deinstallieren durchführen – all das können Sie auf einer Staging-Kopie über Browser und Back Office erledigen. Ein paar Prüfungen – der Blick in /override, das Auflisten von Datenbanktabellen – erfordern Datei- oder Datenbankzugriff, den Ihr Hoster oder Entwickler Ihnen einrichten kann, aber Sie müssen nie Code lesen.

Wenn ein Modul auf dem offiziellen PrestaShop-Marktplatz ist, ist es automatisch sicher?

Die Marktplatz-Validierung und das Verified+-Abzeichen sind ein echtes, nützliches Signal – sie prüfen viele dieser Dinge für Sie. Aber sie ersetzen nicht, das Modul auf Ihrem eigenen Shop, mit Ihrem Theme und Ihren übrigen Modulen, in Aktion zu beobachten. Viele gute Module leben auch außerhalb des Marktplatzes. Führen Sie die Prüfungen so oder so durch.

Das Modul ist kostenlos – ist das für sich genommen ein Warnsignal?

Nein. Kostenlose und günstige Module können hervorragend sein, und teure können nachlässig sein. Der Preis sagt Ihnen nichts darüber, wie sich der Code verhält. Die Bewertung dreht sich um verwaltetes Risiko, nicht um Kosten: Ein kostenloses Modul, das diese Prüfungen besteht, ist sicherer als ein bezahltes, das durchfällt.

Wenn ich nur für eine Prüfung Zeit habe, welche ist es?

Öffnen Sie den Netzwerk-Reiter Ihrer Startseite und zählen Sie neue Drittanbieter-Domains nach der Installation. Es dauert eine Minute, braucht keinen Code und fängt die häufigste und schädlichste Art von nachlässigem Modul ab – jenes, das jede Seite für eine Funktion belastet, die Sie selten zu sehen bekommen.

Ausgeschrieben klingt das nach viel; in der Praxis ist es ein Nachmittag, und er ist weitaus günstiger als der Nachmittag, den Sie sonst damit verbringen würden, herauszufinden, warum Ihr Shop langsam geworden ist oder warum eine Seite nicht zurückkommt, nachdem Sie das Modul entfernt haben, das sie kaputt gemacht hat. Für die Geschichte dahinter, warum das wichtig ist – und einen ehrlichen Bericht über einen Fehler, den wir selbst gemacht haben – lesen Sie was ein PrestaShop-Modul anrichten kann, das die Deinstallation nicht rückgängig macht. Und ja: Führen Sie diese Checkliste auch gegen unsere Module durch. Genau dafür ist sie da. Wenn Sie möchten, dass wir sie für Sie durchführen, bauen unser kostenloser Sicherheitsscan und unser Performance-Audit auf genau diesen Prüfungen auf – und wenn Sie möchten, dass Ihr Shop diese Dinge fortlaufend überwacht statt nur zum Installationszeitpunkt, ist das die Aufgabe von Performance Revolution und Security Revolution.