PrestaShop-Module auswählen, installieren und testen

Was wir empfehlen

Wir würden das fehlende Geschäftsergebnis definieren, native Einstellungen und bereits vorhandene Module prüfen und erst bei verbleibender Lücke ein neues Modul vergleichen. Der richtige Weg hängt von Ihrem bestehenden Shop ab: Einrichtung, Modulversionen, Integrationen, Theme-Anpassungen, Katalog- und Kundendaten, Märkten und dem künftig zuständigen Team. Ein funktionierendes Werkzeug zu ersetzen, braucht einen am konkreten Shop nachweisbaren Nutzen.

Nehmen Sie die gewählte Änderung auf einer geschützten Staging-Kopie vor, die den Produktivbetrieb abbildet. Proben Sie Konfiguration und Rücknahme und planen Sie dann die Live-Umstellung. Vereinbaren Sie, wer die Einführung stoppen darf, welche Nachweise eine Wiederfreigabe erlauben und wie Sie bei nötiger Wiederherstellung Bestellungen oder Integrationsnachrichten abgleichen. Kopieren Sie keine alte Staging-Datenbank über einen laufenden Shop, um eine Moduleinstellung zu veröffentlichen.

Benötigen Sie Kandidatenvergleich und Einführung, testet das PrestaShop Module Selection & Fit Assessment die Wege auf einer kontrollierten Shop-Kopie. Bei bereits gewähltem Modul übernimmt der PrestaShop Module Installation & Configuration Service Installation, vereinbarte Konfiguration und Prüfung des betroffenen Ablaufs.

Eine prüfbare Anforderung formulieren

Geben Sie jedem Kandidaten dieselbe Aufgabenbeschreibung. Beschreiben Sie die heute fehlschlagende Aufgabe, wer sie ausführt und welches Ergebnis die Änderung lohnend macht. Trennen Sie erforderliches Verhalten von optionaler Darstellung, damit eine umfangreiche Funktionsliste keine fehlende Anforderung verdeckt.

• Shop-Kontext: genaue Core-, Web-PHP- und Theme-Versionen, relevante Module und Anpassungen, Sprachen, Währungen, Shops und Kundengruppen.
• Daten- und Integrationsgrenzen: betroffene Katalogfelder, Kundendatensätze oder Bestellstatus, die nächsten Zielsysteme dieser Daten und das jeweils wertführende System.
• Abnahmenachweise: repräsentatives Produkt oder Warenkorb, Reproduktionsschritte, erwartete Kunden- und Mitarbeiterergebnisse und ein Vergleich mit dem aktuellen Shop.
• Betriebliche Vorgaben: wer die Funktion konfiguriert, welche Zugriffe benötigt werden, wie Hintergrundaufgaben überwacht werden und wer nach der Übergabe die Wartung übernimmt.
• Ausstiegsbedingungen: zu exportierende oder aufzubewahrende Einstellungen und Datensätze, Verhalten bei Deaktivierung und Deinstallation und Wiederherstellungsweg bei Fehlschlag.

„Lieferung verbessern“ ist beispielsweise zu allgemein für einen Test. „Nur zulässige Versanddienstleister anbieten, bei Adressänderung eines wiederkehrenden Kunden die Liefergesamtkosten einschließlich Steuern neu berechnen und den gewählten Dienst an unser Bestellsystem exportieren“ gibt dem Anbieter einen konkreten vorzuführenden Ablauf. Ein Screenshot der Versanddienstleisterauswahl beantwortet nur einen Teil dieser Aufgabe.

Genaue PrestaShop- und PHP-Kompatibilität prüfen

Dokumentieren Sie Ihre vollständige PrestaShop-Version, Web-PHP-Version, Theme-Version und installierten Module unter Erweiterte Einstellungen > Informationen und in der Modulverwaltung. Eine Aussage wie „unterstützt 1.7“ ist weniger hilfreich als ein benanntes Release mit getesteter PHP-Kombination.

Die Core-Kompatibilitätsdeklaration ist $this->ps_versions_compliancy in der PHP-Hauptklasse des Moduls. Beispielsweise verwendet diese Deklaration die laufende Shop-Version als Obergrenze:

$this->ps_versions_compliancy = [
    'min' => '1.6.1.0',
    'max' => _PS_VERSION_,
];

Ein angegebener Versionsbereich ist eine Installationsvorgabe, kein Testbericht. Modul-PHP läuft mit den Berechtigungen des Shops und erreicht Datenbank, Kundendaten und beschreibbare Dateien. Browserprüfungen allein belegen daher keine Codesicherheit. Lesen Sie Composers PHP- und Bibliotheksanforderungen gesondert. Die PHP-Laufzeit muss Core, Modul und Abhängigkeiten gemeinsam unterstützen. Neue Syntax kann scheitern, bevor das Modul einen hilfreichen Fehler anzeigt. Senken Sie keine Anforderung im Code ab, um die Prüfung zu umgehen.

Legen Sie für jede Testumgebung ein genaues Core- und PHP-Release fest. Für historische Tests gilt: PrestaShop 1.7.6 unterstützt PHP nur bis 7.2, 1.7.8 bis 7.4 und PrestaShop 8.0 bis 8.2 bis PHP 8.1. Diese alten Kombinationen sind Kompatibilitätsreferenzen, keine aktuellen Hosting-Empfehlungen.

Die PrestaShop-9-Anforderungen unterscheiden 9.0 mit PHP 8.1 bis 8.4 von 9.1 mit PHP 8.1 bis 8.5. Prüfen Sie vor der Wahl der Laufzeit die Anforderungen Ihres genauen Ziel-Releases, einschließlich 9.2. Führen Sie die relevanten Tests sowohl unter 9.2 als auch unter allen älteren unterstützten Releases aus.

Prüfen Sie override/, Installations- und Upgrade-Skripte, Dienstdefinitionen sowie alle außerhalb des Moduls kopierten Dateien. Ein leeres Override-Verzeichnis sagt nur, dass herkömmliche Overrides fehlen. Suchen Sie auch nach Hook-Registrierungen und vergleichen Sie diese anschließend mit den tatsächlich je Shop installierten Registrierungen.

Staging und eine wiederherstellbare Sicherung vorbereiten

Ihre Staging-Kopie sollte in Core, PHP samt Erweiterungen, Datenbank-Engine, Theme, Modulen, Shop-Einstellungen und Serverkonfiguration der Produktion entsprechen. Vergleichen Sie Multishop-Kontext, Sprachen, Währungen, Caching und ausgehende Verbindungen. Eine saubere Demo ist nützlich, um eine Funktion kennenzulernen; sie bildet die Wechselwirkungen Ihres Shops nicht nach.

Schützen Sie die Kopie vor öffentlichem Zugriff und Suchindexierung. Entfernen oder anonymisieren Sie Kundendaten, soweit praktikabel. Deaktivieren Sie echte Zahlungseinzüge, Kunden-E-Mails, Produktions-Webhooks und zeitgesteuerte Integrationen. Verwenden Sie Zahlungs-Sandbox-Zugangsdaten und ein kontrolliertes Postfach.

1. Sichern Sie vollständige Shop-Dateien und Datenbank gemeinsam, einschließlich Overrides, Theme-Anpassungen und Konfiguration.
2. Bewahren Sie das genaue aktuelle Modul-ZIP, die Version und gegebenenfalls einen Konfigurationsexport auf.
3. Speichern Sie Sicherungen außerhalb des öffentlichen Web-Stammverzeichnisses und bestätigen Sie, dass Sie sie wiederherstellen können.
4. Dokumentieren Sie einen Ausgangszustand für die zu testenden Seiten und Abläufe.

Bei einer InnoDB-Datenbank kann ein Entwickler aus einem privaten Sicherungsverzeichnis einen konsistenten logischen Dump wie den folgenden erstellen. Ersetzen Sie Datenbank und Konto durch Ihre tatsächlichen Werte; koordinieren Sie Schreibvorgänge und nicht transaktionale Tabellen separat.

mysqldump --single-transaction -u backupuser -p prestashop > before-module.sql

Siehe den Staging-Leitfaden und den Backup-Leitfaden für die umfassendere Vorbereitung.

ZIP installieren und Upload-Fehler diagnostizieren

Öffnen Sie in PrestaShop 8 und 9 Module > Modulverwaltung > Modul hochladen und laden Sie das gelieferte installierbare ZIP hoch. Behalten Sie den technischen Ordnernamen bei. Beispielsweise gehört mprcanonicalmanager/mprcanonicalmanager.php unter modules/mprcanonicalmanager/, mit den Abhängigkeiten und weiteren Verzeichnissen neben der Hauptdatei.

Ein Repository-Download kann ein zusätzliches äußeres Verzeichnis enthalten oder fertig gebaute Abhängigkeiten auslassen. Verwenden Sie das für die Installation vorgesehene Release-Paket. Das Kopieren von Dateien allein führt install() nicht aus; diese Methode kann Tabellen anlegen, Hooks registrieren, Verwaltungsseiten hinzufügen und Vorgaben initialisieren.

Schlägt der Browser-Upload fehl, vergleichen Sie die Archivgröße mit den wirksamen Web-Werten von upload_max_filesize und post_max_size. Letzterer muss auch den Rest der POST-Anfrage aufnehmen. „Informationen“ zeigt einige PHP-Werte; ermitteln Sie post_max_size aus den Hosting-PHP-Einstellungen oder einer privaten Diagnose der Web-Laufzeit. CLI-php -i kann eine andere Konfiguration lesen.

; Example limits for a ZIP smaller than 64 MB
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300

Dies sind Beispiele, keine Mindestanforderungen für jedes Modul. Prüfen Sie auch Größenlimits für Anfrageinhalte von Proxy und Webserver, temporären Speicher, Entpackplatz, benötigte Erweiterungen und Schreibrechte. Verwenden Sie php_value-Anweisungen in .htaccess nur, wenn Apaches PHP-Integration sie unterstützt; sie sind keine allgemeine PHP-FPM-Lösung.

Entpacken Sie das ZIP bei Bedarf lokal und laden Sie sein einzelnes technisches Modulverzeichnis per SFTP hoch. Installieren Sie es dann in der Modulverwaltung. Prüfen Sie Eigentümer und Zugriff des wirksamen PHP-Benutzers, statt Schreibrechte für alle zu vergeben.

Beobachten Sie während der Installation var/logs/ sowie PHP-FPM- und Webserver-Protokolle. Erweiterte Einstellungen > Logs ist eine weitere mögliche Quelle, frühe Fehler erreichen diese Protokollierung aber möglicherweise nie. Ein auf der Festplatte sichtbares Modul kann beim Erstellen von Tabellen, Registrieren von Hooks, Laden von Abhängigkeiten oder einem anderen Installationsschritt fehlgeschlagen sein. Bewahren Sie den Fehler auf und prüfen Sie den Teilzustand vor einem erneuten Versuch. Löschen Sie Modultabellen oder Autorisierungsrollen nicht blind.

Öffnen Sie nach erfolgreicher Installation „Konfigurieren“, geben Sie die benötigten Händlereinstellungen ein, speichern Sie und laden Sie neu. Prüfen Sie Berechtigungen, Übersetzungen, Menüeinträge und den vorgesehenen Shop-Kontext.

Funktions- und Regressionstests durchführen

Leiten Sie aus dokumentierter Funktionsliste und Aufgabenbeschreibung eine Prüfliste mit Soll-Ergebnissen ab. Testen Sie das dauerhafte Speichern von Einstellungen, Berechtigungen und alle betroffenen Seitentypen. Verwenden Sie vor und nach der Installation dieselben Testdaten. Bewahren Sie Modul-ZIP, Konfiguration, Testschritte, Soll- und Ist-Ergebnisse sowie anonymisierte Nachweise gemeinsam auf, damit ein Anbieter einen Fehler reproduzieren kann.

1. Legen Sie ein Produkt von seiner Produktseite, einer Kategorie und Suchergebnissen aus in den Warenkorb. Diese Einstiegspunkte können unterschiedliches Markup und JavaScript haben, auch wenn ihre Warenkorbänderung denselben CartController erreicht.
2. Schließen Sie den Kauf im Sandbox-Modus ab. Bestätigen Sie Produkte, Varianten, Adressen, Lieferoptionen, Steuern, Rabatte, Währung und Summen sowohl in der Bestellung als auch im Zahlungssystem.
3. Registrieren Sie einen Kunden, prüfen Sie die erwartete E-Mail, melden Sie sich ab und erneut an. Prüfen Sie den Kontoverlauf.
4. Testen Sie die von Ihrem Shop unterstützten Suchen, einschließlich Produktnamen, Artikelnummern und EANs, sofern indexiert.
5. Öffnen Sie Bestelldetails in der Verwaltung. Prüfen Sie Versanddienstinformationen, Tabs, Notizen und die relevanten Mitarbeiterberechtigungen.
6. Leeren Sie den Warenkorb und wiederholen Sie wichtige Interaktionen mobil, einschließlich eines schmalen Ansichtsbereichs wie 375 Pixel.
7. Wechseln Sie jede relevante Sprache, Währung und jeden Shop. Bestätigen Sie, dass Einstellungen und Inhalte im vorgesehenen Geltungsbereich bleiben.

Prüfen Sie in den Browser-Entwicklerwerkzeugen Konsolenfehler, fehlgeschlagene AJAX-Anfragen, Asset-404-Antworten und unerwartete externe Hosts. Besuchen Sie Seiten, auf denen die Funktion erscheint, und solche, auf denen sie nichts tun sollte. Prüfen Sie Modul-Template-Kopien eines Themes unter themes/your-theme/modules/, wenn eine aktualisierte Funktion nicht erscheint.

Prüfen Sie geplante Aufgaben und Webhooks separat. Bestätigen Sie deren Authentifizierung, Häufigkeit, Ziel und Fehlerbehandlung. Eine erfolgreich geladene Seite beweist nicht, dass Hintergrundarbeit erfolgreich ist.

Ein Modul trotz erfolgreicher Demo im eigenen Shop prüfen

Angenommen, Sie testen einen Produktempfehlungsblock in einem mehrsprachigen Shop mit Varianten und Bestellexport. Die Demo beweist, dass Empfehlungen erscheinen. Ihr Abnahmetest muss außerdem nachweisen, dass Kunden weiterhin den gewünschten Artikel kaufen und Mitarbeiter die richtige Bestellung erhalten.

Funktionierte das Hinzufügen zum Warenkorb in Kategorien vor der Installation und schlägt nun fehl, sichern Sie diesen Vergleich und stoppen Sie die Einführung. Grenzen Sie das Zusammenspiel mit den folgenden Konfliktprüfungen ein und wiederholen Sie nach der Korrektur denselben Test. Eine bestandene Prüfung der Empfehlungsanzeige gleicht keinen defekten Kaufweg aus.

Assets, Abfragen und externe Abhängigkeiten messen

Vergleichen Sie wiederholte Seitenaufrufe unter gleichen Bedingungen. Trennen Sie Ergebnisse mit kaltem und warmem Cache. Dokumentieren Sie Serverantwortzeit, Anfragezahl, Übertragungsgröße und langsame Abfragen. Legen Sie ein Akzeptanzbudget für Ihren Shop fest, statt eine feste Millisekundenschwelle als allgemeingültig zu betrachten.

Module haben unterschiedliche Auswirkungen. Ein Verwaltungswerkzeug fügt möglicherweise keine Shop-Assets hinzu; eine bedingte Funktion läuft vielleicht nur bei ausgewählten Anfragen. Zählen Sie die tatsächlich ausgeführten Hooks, Abfragen und Assets. Profilieren Sie wiederholte Datenbankaufrufe innerhalb von Produktschleifen und synchrone externe Anfragen während des Seitenrenderings.

Debug-Modus und Profiling sind getrennt. Der ältere Abfrage- und Zeitprofiler verwendet _PS_DEBUG_PROFILING_ in config/defines.inc.php. Der Symfony-Profiler gilt bei entsprechender Konfiguration für geeignete Symfony-Anfragen. Keiner garantiert eine zeitliche Aufschlüsselung jeder Shop-Anfrage oder jeder fehlschlagenden Anfrage. Nutzen Sie Profiling kurzzeitig auf geschütztem Staging.

Bevorzugen Sie registerStylesheet() und die entsprechende Skript-API für Asset-Verwaltung und CCC-Integration. Prüfen Sie auch ausdrückliche Versionierung und Invalidierung bei der Bereitstellung. Registrierung garantiert nicht automatisch Cache-Busting, und ein roher Link wird nicht allein durch Cache-Leeren zu einer 404-Antwort.

Mit diesem Browserkonsolenbeispiel können Sie die von der aktuellen Seite beobachteten Ressourcen-Hosts auflisten:

const hosts = {};
for (const entry of performance.getEntriesByType('resource')) {
    const host = new URL(entry.name, location.href).host;
    if (host && host !== location.host) {
        hosts[host] = (hosts[host] || 0) + 1;
    }
}
console.table(hosts);

Prüfen Sie neben Drittanbietern auch eigene CDN-Subdomains. Diese Liste erfasst im Browser beobachtete Ressourcen, weder Server-zu-Server-Verkehr noch jede Form der Datenübertragung. Fragen Sie, warum ein neuer Host benötigt wird, welche Daten er erhält und wie sich die Funktion bei seiner Nichterreichbarkeit verhält. Wiederholen Sie die Beobachtung mit relevanten Einwilligungs- und Anmeldestatus, da Anfragen erst nach Interaktion oder Berechtigungsänderung erscheinen können.

Simulieren Sie auf Staging mit der Anfragesperre des Browsers einen nicht verfügbaren funktionsspezifischen externen Host und testen Sie die Seite erneut. Dokumentieren Sie, ob die optionale Funktion erkennbar ausfällt und Navigation sowie Kauf weiter funktionieren. Dies prüft nur die Browserabhängigkeit. Lassen Sie den Entwickler serverseitige Zeitüberschreitungen und fehlgeschlagene Hintergrundaufrufe gesondert proben.

Updates testen und einen vollständigen Rollback vorbereiten

Lesen Sie Änderungsprotokoll und Anforderungen vor dem Dateiaustausch. Sichern Sie Dateien und Datenbank, dokumentieren Sie die installierte Version und behalten Sie beide ZIPs. Testen Sie ein Upgrade von der tatsächlichen Produktionsversion, nicht nur eine Neuinstallation des neuen Releases.

Nutzen Sie den unterstützten Update- oder ZIP-Upload-Ablauf der Modulverwaltung. Prüfen Sie, dass die installierte Datenbankversion erhöht wird und die passenden Migrationen upgrade/install-X.Y.Z.php abgeschlossen werden. Das Kopieren neuer Dateien per SFTP allein beweist nicht, dass Migrationen ausgeführt wurden.

Die Konfiguration liegt oft in der Datenbank, Upgrade-Code kann sie aber ändern oder entfernen. Vergleichen Sie gespeicherte Einstellungen, eigene Tabellen, Hooks, Berechtigungen und Theme-Template-Kopien nach dem Update. Betrachten Sie „Zurücksetzen“ gesondert: Es kann ein Modul deinstallieren und neu installieren, wobei der Umgang mit Daten von Implementierung und Datenbeibehaltungsoptionen abhängt. Es ist kein sicherer Ersatz für eine Migration.

Proben Sie Neuinstallation, Upgrade, Deaktivierung, Reaktivierung und Deinstallation als getrennte Vorgänge auf entbehrlichen Kopien. Vergleichen Sie jedes Ergebnis mit der dokumentierten Aufbewahrungsregelung. Eine saubere Deinstallation darf Bewertungen oder Integrationsdatensätze bewusst erhalten. Alles zu löschen ist nicht automatisch richtig. Exportieren Sie benötigte Daten, bevor Sie eine löschende Bereinigung testen.

Bevorzugen Sie Erweiterte Einstellungen > Leistung > Cache leeren. Ein koordiniertes Leeren per CLI kann ebenfalls geeignet sein:

php bin/console cache:clear --env=prod

Führen Sie den Befehl aus dem Shop-Stammverzeichnis mit der richtigen PHP-Binärdatei und dem richtigen Dateisystembenutzer aus. Ist eine Dateisystemwiederherstellung nötig, stoppen Sie eingehende Zugriffe und Worker, bestätigen Sie Cache-Pfade und Eigentümer, bauen Sie den Cache neu auf und prüfen Sie den Shop vor der Wiederöffnung. Der PrestaShop-Cache ist regenerierbar; gleichzeitige Anfragen, fehlende Abhängigkeiten und Berechtigungen können den Neuaufbau scheitern lassen. Koordinieren Sie Web-OPcache sowie Full-Page-, Proxy- oder CDN-Caches separat.

Wenn Sie zur vorherigen Version zurückkehren müssen

1. Versetzen Sie einen betroffenen Live-Shop in Wartung und stoppen Sie Aufgaben, die zugehörige Daten schreiben können.
2. Sichern Sie den fehlerhaften Zustand, Protokolle und aktuelle Transaktionsdetails zur Diagnose.
3. Stellen Sie ein sauberes vorheriges Modulverzeichnis wieder her, ohne Versionen zu mischen. Bewahren Sie die verdrängte Kopie außerhalb des öffentlichen Modulverzeichnisses auf.
4. Stellen Sie den passenden Datenbankzustand wieder her oder wenden Sie eine vom Entwickler gelieferte Rückwärtsmigration an. Dateien allein können Schema- oder Datenänderungen nicht rückgängig machen.
5. Gleichen Sie seit der Sicherung entstandene Bestellungen, Zahlungen und Bestandsänderungen ab. Überschreiben Sie neue Live-Transaktionen nicht mit einem alten Gesamtsnapshot des Shops.
6. Leeren Sie die relevanten Caches und wiederholen Sie Funktions-, Konfigurations- und Kassentests.

Verwenden Sie „Deinstallieren“ oder „Löschen“ nicht als Downgrade-Schritt, sofern Sie die Bereinigung nicht verstehen. Ein Modul kann seine Tabellen und Einstellungen absichtlich entfernen. Besorgen Sie das genaue vorherige ZIP aus einem Release-Archiv oder vom Support, statt anzunehmen, dass jedes Konto ältere Versionen bereitstellt.

Fehler eingrenzen und überlappende Anpassungen auflösen

Reproduzieren Sie den Fehler auf Staging mit beiden verdächtigen Modulen, mit jedem einzeln und mit keinem. Dokumentieren Sie den Zustand nach jeder Änderung. Deaktivieren Sie bei einer größeren Menge eine kontrollierte Gruppe und grenzen Sie dann weiter ein. Testen Sie Abhängigkeiten und Kombinationen: Das zuletzt aktivierte Modul kann eine Wechselwirkung sichtbar machen, ohne deren alleinige Ursache zu sein.

Mehrere Module können einen Hook gemeinsam nutzen. Die Position kann für die Anzeigeausgabe wichtig sein, aber eine andere Reihenfolge ist keine allgemeine Lösung. Vergleichen Sie Warenkorbänderungen, Rückgabedaten, Event-Listener, CSS-Selektoren, mitgelieferte Bibliotheken, Templates und Konfiguration. Hooks und Symfony-Dienste verringern die direkte Core-Kopplung; sie garantieren keinen konfliktfreien Betrieb.

Der Core kann Overrides zusammenführen, die derselben Klasse unterschiedliche Methoden hinzufügen. Überlappende Methoden, Eigenschaften oder Konstanten können einen ausdrücklichen Konflikt auslösen. Führen Sie nicht zwei Methoden vorab in der Annahme zusammen, der nächste Installer werde sie akzeptieren. Vereinbaren Sie einen Kompatibilitätspatch mit einem Verantwortlichen für die gemeinsame Implementierung und einem dokumentierten Installations-, Upgrade- und Entfernungsverfahren.

Prüfen Sie Override-Dateien, deren Zugehörigkeitskommentare, aktive Override-Einstellungen und Klassenindex-Pfadeinträge. Eine Klassennamensliste allein identifiziert keine Verantwortlichen und beweist nicht, dass eine Datei verwaist ist. Eine Datei auf der Festplatte wird nicht automatisch auf jeder Seite ausgeführt; ein Override wird verwendet, wenn seine zugeordnete Klasse geladen wird.

Ist das Backoffice nicht erreichbar, nutzen Sie nach Möglichkeit die normale Deaktivierungsaktion oder den unterstützten Konsolenbefehl. Das Umbenennen eines Modulverzeichnisses ist eine Dateiisolierung für Notfälle und benötigt einen dokumentierten Rückweg. Es deinstalliert keine Overrides und macht kompilierte Dienste und Datenbankänderungen nicht rückgängig. Bewahren Sie Protokolle vor dem Cache-Leeren auf. Prüfen Sie bei einer leeren Antwort HTTP-Status und Serverprotokolle; nutzen Sie Debug-Ausgaben nur auf einer geschützten Kopie und schalten Sie sie anschließend aus, da sie sensible Konfiguration offenlegen können.

Siehe PrestaShop-Fehlerbehebung für die Wiederherstellung nach Symptom.

Prüfungen am Release-Paket automatisieren

Nutzen Sie bei der Modulentwicklung PHPUnit für unabhängig testbare Geschäftslogik wie Berechnungen und Formatierer. Ergänzen Sie Integrationstests für Installation, Migrationen, Hooks und shopbezogene Speicherung. Nutzen Sie Browsertests für wesentliche Kundenabläufe wie Anmeldung, Hinzufügen zum Warenkorb und Bestellabschluss.

Erstellen Sie eine Matrix der genau unterstützten Core-, PHP-, Datenbank- und Theme-Kombinationen. Beziehen Sie aktuelle Ziel-Releases und das älteste Release ein, dessen Unterstützung Sie tatsächlich zusagen. Speichern Sie Testergebnisse mit dem genauen Release-ZIP oder Commit, nicht nur einem Quellcode-Kompatibilitätsbereich.

Eine CI-Pipeline kann das Archiv bauen, Abhängigkeiten und Syntax prüfen, es auf sauberen Shops installieren, von unterstützten vorherigen Modulversionen aktualisieren und Browser-Smoke-Tests ausführen. Statische Prüfungen auf veraltete APIs ergänzen Laufzeittests, ersetzen sie aber nicht. Testen Sie Deinstallation und dokumentierte Datenaufbewahrung auf entbehrlichen Kopien.

Angebote, Anbieter und Kaufbedingungen bewerten

Vergleichen Sie Angebote anhand Ihrer Aufgabenbeschreibung. Prüfen Sie dieselbe Funktion mit Ihrem eigenen Katalog über eine verfügbare Demo oder Testversion. Installieren Sie Kandidaten getrennt, bevor Sie eine geplante Kombination testen. Eine Anbieterdemo zeigt das vorgesehene Verhalten. Fragen Sie nach kontrollierten Testmöglichkeiten für Ihren tatsächlichen Shop und ob die Lizenz eine private Staging-Installation erlaubt.

• Kompatibilität: Beschaffen Sie genaue Core-, PHP- und Theme-Anforderungen einschließlich bekannter Einschränkungen.
• Wartung: Lesen Sie datierte Releases, Reaktionen auf Fehlermeldungen und Sicherheitskorrekturen. Ein altes Release-Datum benötigt Kontext; es beweist allein keine Aufgabe des Projekts.
• Dokumentation: Suchen Sie nach Anforderungen, Einrichtung, Datenaufbewahrung, Hintergrundaufgaben und Wiederherstellungsschritten.
• Bewertungen: Bevorzugen Sie Beschreibungen einer echten Konfiguration und eines Supportergebnisses gegenüber einem Sternedurchschnitt.
• Codezugriff: Prüfen Sie, ob Ihr Entwickler ihn prüfen und warten kann. Undokumentierte Core-Änderungen oder undurchsichtige Abhängigkeiten sollten untersucht werden.
• Sicherheit: Suchen Sie den genauen technischen Namen und die Version bei Friends of Presta und in Sicherheitshinweisen des Betreuers. Fehlende veröffentlichte Warnungen beweisen keine Sicherheit. Vergleichen Sie betroffene Versionen, Schweregrad und verfügbare Korrekturen. Die reine Anzahl von Warnungen kann auch die Intensität der Untersuchung widerspiegeln.

Marketplace-Prüfungen und Qualitätsprogramme sind nützliche Signale, Ihr Shop benötigt trotzdem Staging-Tests. Ein Direktanbieter, Marketplace-Verkäufer, gepflegtes Open-Source-Projekt oder individueller Entwickler kann jeweils geeignet sein. Vergleichen Sie Lizenzumfang, Preis einschließlich Steuern, Verlängerung, Updates, Support, individuelle Arbeiten und Streitbeilegungsbedingungen für das tatsächliche Angebot. Bewerten Sie Implementierung und Wartung des tatsächlichen Moduls.

Die Marketplace-FAQ zu Support und Updates beschreibt Business Care und Erstattungsbedingungen für dort gekaufte Add-ons. Bei den erfassten Käufen enthält der Kauf das erste Jahr Business Care mit automatischer Verlängerung. Erstattungen müssen schriftlich beantragt werden. Die Berechtigung umfasst bestimmte Probleme innerhalb eines Monats; bei Fehlfunktionen ist der vorherige Verkäuferkontakt relevant. Prüfen Sie diese Bedingungen vor Zahlung erneut für Ihren konkreten Kauf, das Produkt und Land, dokumentieren Sie Bedingungen und Datum und bewahren Sie den Supportverlauf auf. Setzen Sie weder eine Erstattung noch eine bestimmte Antwortzeit voraus.

Kostenlose Angebote können Community-Projekte, Lite-Versionen, an einen Dienst gebundene Integrationen oder eingestellte Produkte sein. Lesen Sie ihre tatsächlichen Grenzen und Supportpflichten. Die Pflicht, ein Konto bei einem Drittanbieter anzulegen, kann berechtigt sein. Prüfen Sie Datenzweck, Empfänger, Aufbewahrung und Vertragsbedingungen, statt die Kontoregistrierung als Beleg für das Sammeln von Daten zu behandeln.

Schätzen Sie Gesamtkosten anhand Ihrer tatsächlichen Lizenz-, Umsetzungs-, Hosting-, Wartungs-, Support- und Migrationskosten. Kostenlos bedeutet nicht grundsätzlich unsicher, und kostenpflichtig garantiert keinen langfristigen Support. Berücksichtigen Sie Mitarbeiterschulung, laufende externe Dienste, Datenexport und Entfernung. Vergleichen Sie Kandidaten über denselben Zeitraum anhand der tatsächlichen Anbieterbedingungen und der Kostensätze Ihres Teams.

Ein kostenloses Werkzeug kann eine klar definierte Aufgabe erfüllen: Security Scan meldet lokale Sicherheitsbefunde mit Fundorten und Schweregrad und bietet manuelle Korrekturschritte. Es repariert weder den Shop noch bescheinigt es die Sicherheit eines Modulkandidaten. Nutzen Sie Befunde zur gezielten Untersuchung und weisen Sie das relevante Verhalten anschließend auf Staging nach.

Was Sie den Entwickler oder die Agentur fragen sollten

• Welche Version haben Sie mit genau dieser Core-, PHP- und Theme-Kombination getestet und welche installierten Module oder Integrationen erfordern gesonderte Kompatibilitätsarbeit?
• Können Sie den Abnahmeablauf mit unseren repräsentativen Daten einschließlich Fehler- und Wiederherstellungsweg vorführen, statt nur einen Einstellungsbildschirm zu zeigen?
• Deckt die Lizenz unsere Shops und private Staging-Domain ab und wer erhält Downloads, Updates und Support bei einem Agenturwechsel?
• Welche Einstellungen, Tabellen, Overrides, geplanten Aufgaben und externen Dienste ändern sich und was bleibt nach Deaktivierung oder Deinstallation?
• Wer behebt Wechselwirkungen zwischen Anbietern, welche Supportarbeit ist enthalten und wer wartet eine individuelle Kompatibilitätskorrektur?
• Welche Nachweise erhalten wir bei der Übergabe und wer verantwortet Rollback und Abgleich neuer Bestellungen bei einem fehlgeschlagenen Start?

Bereits installierte Module prüfen

Erfassen Sie aktive und inaktive Module, Verantwortliche, Versionen, Geschäftszweck, Abhängigkeiten und Updatebereitschaft. Kennzeichnen Sie jedes zum Beibehalten, Konfigurieren, Aktualisieren, Ersetzen oder Stilllegen und benennen Sie einen Entscheidungsverantwortlichen. Entfernen Sie redundante Funktionen erst nach einer Abhängigkeitsprüfung. Deaktivieren Sie zunächst für einen umkehrbaren Test, deinstallieren Sie dann über die unterstützte Aktion und entfernen Sie ungenutzte Dateien gemäß Aufbewahrungsplan.

Schließen Sie aus einem leeren Shopblock nicht auf fehlende Nutzung. Ein scheinbar untätiges Modul kann Bestellungen exportieren, eine Verwaltungsaktion anbieten oder gelegentlich einen Feed ausführen. Fragen Sie den zuständigen Mitarbeiter und beobachten Sie den relevanten geplanten Lauf vor der Stilllegung. Eine Abhängigkeit ohne sichtbares Widget zu entfernen, kann eine funktionierende Integration beschädigen.

Normales Deaktivieren verhindert den standardmäßigen ModuleFrontController-Pfad für ein inaktives Modul. Es entfernt keine eigenständigen PHP-Endpunkte, installierten Overrides oder sämtlichen Integrationscode. Restdateien verdienen eine Sicherheitsprüfung, auch wenn sie keine gemessenen Laufzeitkosten verursachen.

Diese schreibgeschützten Beispiele verwenden ps_. Setzen Sie Ihr tatsächliches Präfix ein. Prüfen Sie bei Multishop auch Shop-Zuordnungen; das globale Aktiv-Kennzeichen ist kein vollständiges Inventar je Shop.

SELECT name, version, active
FROM ps_module
ORDER BY active ASC, name;

SELECT hm.id_module, hm.id_hook, h.name AS hook_name
FROM ps_hook_module hm
LEFT JOIN ps_module m ON m.id_module = hm.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.id_module IS NULL;

SELECT m.name, COUNT(*) AS registrations
FROM ps_hook_module hm
JOIN ps_module m ON m.id_module = hm.id_module
GROUP BY m.name
ORDER BY registrations DESC;

Hook-Registrierungen können separate Shop-Zeilen enthalten, und eine hohe Anzahl beweist keine aufwendige Ausführung. Untersuchen Sie verwaiste Registrierungen, statt Zeilen von Hand zu löschen. Vergleichen Sie die Datenbankstruktur vor und nach Installation und Deinstallation, einschließlich dokumentierter beibehaltener Daten. Dateiprüfungen unter override/classes/ und override/controllers/ ergänzen das Datenbankinventar.

Bevorzugen Sie bei der Prüfung von SQL-Code Parameterbindung, wo verfügbar. Prüfen Sie in älterem Code kontextgerechte Wertmaskierung, Ganzzahlumwandlungen und Kennungsbehandlung. Verfolgen Sie, wie nicht vertrauenswürdige Eingaben jede Abfrage erreichen und wie dieser Kontext geschützt wird.

Funktionen anhand tatsächlicher Shop-Lücken wählen

Prüfen Sie zuerst native Möglichkeiten. Es gibt weder ein allgemeines unverzichtbares Modulpaket noch eine Produktzahlschwelle, die eine Erweiterung zwingend macht.

Die Dokumentation zum nativen One-Page-Checkout erläutert die Kompatibilitätsänderungen in 9.2. Konfigurationsdetails finden Sie auf den verlinkten Modulhilfeseiten.

Startentscheidungen treffen, bevor sie Live-Datensätze betreffen

Legen Sie stabile URL-Regeln fest, bevor Sie Links veröffentlichen. Der Core erzeugt URLs aus aktuellen Routen und Entitätsdaten; Produkte speichern beim Anlegen keine unveränderliche vollständige URL. Numerische IDs erzeugen für sich keine doppelten Inhalte. Prüfen Sie Standardkategorien, Canonical-Weiterleitung und Theme-erzeugte Links, bevor Sie Routen ändern. Ordnen Sie alte veröffentlichte URLs zu, wenn eine Änderung Weiterleitungen erfordert.

Legen Sie Metadaten- und strukturierte Datenregeln früh fest und prüfen Sie dann die tatsächliche Ausgabe. Bestehende Entitäten können in SEO Revolution Metadatenvorlagen per Massenbearbeitung erhalten. Unterscheiden Sie gespeicherte Metadatenänderungen von dynamischer Ausgabe. Sie müssen nicht alles manuell nachpflegen.

Vereinbaren Sie Rechnungsregeln mit Ihrem Buchhalter, bevor Sie Rechnungen ausstellen. Die Erstellung hängt von Rechnungseinstellungen und dem Rechnungskennzeichen eines Bestellstatus ab. Der Core unterstützt Präfixe, eine Startnummer und jährliches Zurücksetzen. Beachten Sie beim Ändern ausgestellter Dokumente oder der Nummerierung die Korrektur- und Prüfregeln Ihres Rechtsraums.

Entscheiden Sie, welche Kundendaten Sie bei der Registrierung tatsächlich benötigen. Der native B2B-Modus bietet Unternehmens- und Identifikationsfelder. Individuelle Daten benötigen eine passende Felderweiterung und einen rechtmäßigen Erhebungszweck. Customer Extra Info (IP Ban) ist kein Werkzeug zur Erstellung von Registrierungsfeldern. Planen Sie, wie bestehende Kunden neu erforderliche Daten ergänzen können.

Richten Sie Analyse- und Search-Console-Zugang nach Möglichkeit vor Kampagnen ein. Tracking kann nicht erhobene Interaktionsereignisse nicht nachbilden. Beachten Sie Einwilligungsanforderungen und prüfen Sie die Ausgangslage, bevor Sie sie für Entscheidungen nutzen. Testen Sie die Kasse vor dem Start; ein kostenpflichtiger Ersatz benötigt einen nachgewiesenen Funktions- oder Kompatibilitätsvorteil für Ihren Shop.

Ergänzen Sie Chat, Kundenbindung, Social-Widgets und andere Darstellungsfunktionen, wenn Sie deren Zweck benennen und Wirkung messen können. Installieren Sie jeweils nur eine Änderung. Wiederholen Sie nach der Live-Bereitstellung kritische Prüfungen und überwachen Sie Protokolle. Benötigen Sie Hilfe mit einem MPR-Modul, senden Sie Version, Umgebung, Reproduktionsschritte, Soll- und Ist-Ergebnisse sowie anonymisierte Protokolle an den Support.

Über den Produktiveinsatz der getesteten Änderung entscheiden

Nutzen Sie Testergebnisse als Freigabeentscheidung, nicht als Durchschnittsnote. Ein offener Checkout-Fehler, falscher Kundendatenzugriff, ungeklärte Datenübertragung oder unbewiesener Wiederherstellungsweg blockiert den Start auch bei sonst bestandenen Prüfungen. Dokumentieren Sie geringere Einschränkungen ausdrücklich mit Verantwortlichem und vereinbarter Maßnahme.

1. Schreiben Sie das getestete Paket fest und dokumentieren Sie Version, Abhängigkeiten, Einstellungen und genaue verwendete Shop-Konfiguration. Prüfen Sie produktive Änderungen seit Erstellung der Kopie.
2. Holen Sie die Abnahme der Kunden- und Mitarbeiterergebnisse durch den fachlich Verantwortlichen ein. Sorgen Sie dafür, dass Bestellbearbeiter Änderungen und Fehleranzeigestellen kennen.
3. Wählen Sie das Einführungsfenster, sichern Sie die zugehörigen Dateien und Datenbank und bestätigen Sie die geprobten Rücknahmeschritte. Pausieren Sie betroffene Aufgaben und Zugriffe, soweit die Migration dies erfordert.
4. Führen Sie die unterstützte Installation oder Aktualisierung mit dokumentierter Konfiguration im Produktivbetrieb aus. Prüfen Sie Shop-Kontext, Zugangsdaten und Endpunkte. Sandbox-Werte aus Staging dürfen nicht unbemerkt zu Live-Einstellungen werden.
5. Führen Sie die zum Modul passenden kritischen Live-Prüfungen über gegebenenfalls autorisierte Anbieterabläufe aus. Prüfen Sie neben der sichtbaren Seite auch die entstandene Bestellung, E-Mail oder den nachgelagerten Datensatz.
6. Nehmen Sie betroffene Aufgaben bewusst wieder auf, überwachen Sie Protokolle und Integrationswarteschlangen und benennen Sie den Verantwortlichen für fehlgeschlagene Prüfungen. Erhalten und prüfen Sie bei Rücknahme der Änderung die während des Zeitfensters entstandenen Transaktionen.

Übergeben Sie dem Team endgültige Einstellungen, aufbewahrtes Paket, Testnachweise, bekannte Grenzen, Supportkontakt und Wiederherstellungsverfahren. Wiederholen Sie relevante Prüfungen nach der nächsten Core-, PHP-, Theme- oder Integrationsänderung. Ein alter Abnahmebericht beschreibt nur die damals erfolgreich getestete Konfiguration.

Häufige Fragen von Shopbetreibern

Wie viele Module sind zu viele?

Identifizieren Sie anhand des Verzeichnisses Module ohne Geschäftszweck oder Betreuer und anhand gemessener Tests aufwendige Wechselwirkungen. Die Anzahl allein zeigt weder die Gesundheit eines stark genutzten Shops noch einen schweren Fehler in einem fast leeren Shop.

Kann ich die Prüfungen selbst durchführen?

Sie können sichtbares Verhalten, gespeicherte Einstellungen und Browseranfragen auf Staging vergleichen. Lassen Sie einen Entwickler Schemaänderungen, Berechtigungen, serverseitige Aufrufe und Migrationen prüfen, die Sie nicht beurteilen können. Eine erfolgreiche Browserprüfliste liefert nützliche Nachweise, aber kein vollständiges Code- oder Sicherheitsaudit.

Garantieren Marketplace-Siegel, Kauflizenz oder aktueller Scan Sicherheit?

Nein. Jeder Aspekt beantwortet nur einen Teil der Kaufentscheidung. Verlangen Sie Nachweise für Ihre konkrete Konfiguration, untersuchen Sie kritische Befunde und stellen Sie vor dem Start Betreuung und Wiederherstellungsweg sicher.

Sollte ich ein altes Modul aktualisieren oder ersetzen?

Prüfen Sie, ob ein unterstütztes Update die Anforderung erfüllt und Daten sowie Anpassungen erhält. Andernfalls vergleichen Sie Ersatz oder abgegrenzte Entwicklung einschließlich Migrations- und Entfernungskosten. Bewahren Sie während der Probe die wiederherstellbare Version auf.

Beweist eine erfolgreiche Deinstallation einen funktionierenden Rollback?

Testen Sie die Wiederherstellung, die Sie nach einem fehlgeschlagenen Upgrade tatsächlich nutzen würden. Eine Deinstallation kann Datensätze löschen; ein Downgrade kann passende Dateien und Datenbankänderungen verlangen. Testen Sie die Deinstallation auf einer entbehrlichen Kopie und verwenden Sie für Geschäftsdaten das dokumentierte Wiederherstellungsverfahren.

Kann ich diese Funktionen einem bereits laufenden Shop hinzufügen?

Ja. Grenzen Sie die Auswirkungen auf bestehende Datensätze, veröffentlichte URLs, ausgestellte Dokumente und angeschlossene Systeme ab und proben Sie die Änderung auf einer Kopie. Nutzen Sie bei Bedarf unterstützte Massenaktualisierungen oder Migrationen und terminieren Sie die Umstellung. Eine zusätzliche Funktion erfordert nicht automatisch einen Neuaufbau des Shops.