Ein kommerzielles Modul auf Kompatibilität mit PrestaShop 9.2 vorbereiten

Die Kompatibilitätsaussage eines kommerziellen Moduls ist ein Versprechen an Händler bezüglich einer Kombination aus Software und Verhalten. „Lässt sich auf PrestaShop 9.2 installieren“ ist eine wesentlich engere Aussage als „unterstützt den nativen Bezahlvorgang, migrierte Verwaltungsseiten und den Multistore-Betrieb“.

Für das am 26. September 2026 verfügbare 9.2 RC1 sollten Anbieter Kandidatentests genau beschreiben. Eine bestandene RC-Prüfung rechtfertigt nicht, die noch unveröffentlichte stabile Version als unterstützt zu bezeichnen. Dieser Artikel erklärt, wie ein bestehendes Modulprodukt qualifiziert wird, nicht wie sein Grundgerüst erstellt wird.

Wenn das Modul an Zahlung oder Lieferung beteiligt ist, nehmen Sie den QA-Plan für One Page Checkout in die Kompatibilitätsmatrix auf, statt nur die Installation zu testen.

Definieren Sie den Unterstützungsumfang vor dem Entwurf der Matrix

Schreiben Sie auf, welche Fähigkeiten das Modul tatsächlich bietet und welche Kombinationen Kunden voraussichtlich verwenden. Ein Zahlungsmodul hat andere kritische Abläufe als ein Modul zur Kataloganreicherung. Eine reine Back-Office-Erweiterung benötigt möglicherweise keine vollständige Matrix der Shop-Themes, eine Checkout-Erweiterung dagegen sicherlich.

Trennen Sie verpflichtende Unterstützung von optionaler Kompatibilität. Wenn das Modul derzeit nur einen bestimmten Checkout-Ablauf unterstützt, sagen Sie dies ausdrücklich. Wenn Multistore nicht unterstützt wird, darf die Installation in einem Multistore-Shop nicht das Gegenteil nahelegen.

Listen Sie die genauen Abhängigkeiten hinter der Aussage auf: Core, Laufzeitumgebung, native Module, gegebenenfalls Theme und Integrationsversion des externen Dienstes. Halten Sie experimentelle Abhängigkeiten sichtbar, statt sie in einen breiten Versionsbereich einzubeziehen.

Eine nützliche Aussage zum aktuellen Meilenstein lautet „mit 9.2.0-rc.1 unter diesen benannten Kombinationen und Einschränkungen getestet“. Sie erklärt frühen Testern die vorhandenen Nachweise, ohne Produktionsreife des Kandidaten zu unterstellen.

Richten Sie die Matrix an Risiken aus, nicht an jeder möglichen Kombination

Beginnen Sie mit den geschäftlichen Auswirkungen des Moduls. Welcher Vorgang kann Geld, Bestand, Kundendaten oder den Shopbereich verändern? Welche Erweiterungspunkte haben sich im Kandidaten geändert? Welche externen Abhängigkeiten können verspätete oder doppelte Ergebnisse erzeugen?

Verwenden Sie eine Matrix, die jedes Risiko mit Nachweisen verknüpft:

Wählen Sie anschließend repräsentative Kombinationen. Testen Sie die niedrigste und höchste Laufzeitversion, für die Sie Unterstützung zusagen, mit den Abhängigkeitskombinationen, die Unterschiede am ehesten sichtbar machen. Ergänzen Sie gezielte Fälle, wenn der Code abhängig von der Plattformversion verzweigt.

Behaupten Sie nicht, dass eine paarweise Matrix jede Kombination beweist. Sie ist eine Abdeckungsstrategie, deren Einschränkungen dokumentiert bleiben sollten.

Behandeln Sie Checkout und migrierte Seiten als getrennte Integrationsbereiche

Prüfen Sie bei einem Checkout-Modul sowohl den unterstützten Kaufablauf als auch die abhängigen Zahlungs- oder Versanddienstleisterinteraktionen. Testen Sie Neuladen, geänderte Adresse, fehlgeschlagenes Absenden und wiederholte Initialisierung. Ein Modul, das nur auf das anfängliche Laden der Seite reagiert, kann sich im nativen Einseitenablauf anders verhalten.

Erfassen Sie bei Hummingbird oder einem Child-Theme die Theme-Revision und relevante Überschreibungen. Der Template- und DOM-Vertrag des Checkouts ist eine konkrete Integrationsabhängigkeit und nicht lediglich eine Stilpräferenz. Offizieller Theme-Vertrag für den Checkout.

Bestimmen Sie bei Verwaltungserweiterungen die migrierten Seiten und aktiven Flags. Testen Sie das vorgesehene Speichern von Formularen, Tabellenfilter und die Berechtigungsgrenzen von Mitarbeitern auf jedem unterstützten Ablauf. Verwenden Sie einen ausschließlich als SuperAdmin ausgeführten Basistest nicht als Nachweis für die Abläufe gewöhnlicher Mitarbeiter.

Prüfen Sie, dass Kompatibilitätscode nicht zweimal ausgeführt wird, wenn alte und neue Hooks registriert sind. Das Ausbleiben eines fatalen Fehlers reicht nicht aus, wenn eine Aktion doppelte Schreibvorgänge oder Benachrichtigungen erzeugt.

Ein Anbieter sollte jede Kompatibilitätsanpassung einem fehlgeschlagenen Fall oder einer dokumentierten Vertragsänderung zuordnen können. Vermeiden Sie umfangreiche Neufassungen, deren Nutzen sich nicht belegen lässt.

Prüfen Sie Laufzeitannahmen und versionsspezifische Dienste

Laufzeitkompatibilität umfasst Code, der nur in ungewöhnlichen Lebenszyklusphasen ausgeführt wird: Installation, Deinstallation, geplante Aufgaben, Fehlerbehandlung und Anbieter-Callbacks. Prüfen Sie diese Abläufe mit den Laufzeitversionen des angegebenen Unterstützungsbereichs.

Die Arbeiten in 9.2 ergänzen die Unterstützung für PHP-Dienstdefinitionen und versionsspezifische YAML-Dienstdateien. Damit lässt sich die Verdrahtung der Dienste anpassen und zugleich die Unterstützung älterer Versionen erhalten. Das ausgewählte Ladeverhalten muss jedoch in der passenden Implementierung geprüft werden. Änderung der versionsspezifischen Dienstkonfiguration.

Wenn Sie diesen Mechanismus einsetzen, testen Sie den Dienstcontainer auf jedem angegebenen Plattformzweig. Bestätigen Sie, welche Datei ausgewählt wird und dass kein Dienst nur deshalb existiert, weil der lokale Cache eines Entwicklers eine alte Definition behalten hat. Nehmen Sie nicht an, dass mehrere alternative Dienstdateien alle zusammengeführt werden.

Prüfen Sie für Zusagen zu PHP 8.5 die Syntax und führen Sie die relevanten Tests auf PHP 8.5 selbst aus. Die Core-Kompatibilität validiert nicht automatisch die Abhängigkeiten eines Moduls. Die RC-Versionshinweise listen PHP-8.5-bezogene Korrekturen auf. Dies unterstreicht die Notwendigkeit versionsspezifischer Tests statt einer pauschalen Schlussfolgerung. Änderungsprotokoll des Versionskandidaten.

Prüfen Sie auch Annahmen über endliche Wertemengen. Die Änderung des Produktzustands in 9.2 fügt Werte hinzu, die ein Modul mit fest codierter Zulassungsliste ablehnen oder falsch bezeichnen kann. Wenn Ihr Modul Zustände liest, vergleichen Sie seine unterstützten Werte mit der tatsächlichen Enumeration des Kandidaten und definieren Sie das Verhalten bei einem unbekannten Wert. Änderung des Produktzustands.

Testen Sie den Fortbestand von Kundendaten bei Lebenszyklusvorgängen

Installieren Sie die veröffentlichte Modulversion in einer entbehrlichen Basisumgebung, erstellen Sie repräsentative Daten und wenden Sie anschließend das Kandidatenupdate des Moduls über den unterstützten Mechanismus an. Prüfen Sie, dass bestehende Werte ihre Bedeutung behalten und neue Standardwerte keine bewusst gesetzten Einstellungen überschreiben.

Wiederholen Sie den Aktualisierungsversuch, soweit der Lebenszyklus dies zulässt. Ein teilweise abgeschlossenes Update darf keine doppelten Definitionen, Indizes oder Geschäftsdatensätze erzeugen. Dokumentieren Sie, wie das Modul einen unterbrochenen Schritt erkennt und sich davon erholt.

Testen Sie Deaktivieren und erneutes Aktivieren getrennt von der Deinstallation. Händler deaktivieren ein Modul häufig bei der Diagnose eines anderen Problems; diese Aktion sollte der dokumentierten Aufbewahrungsrichtlinie folgen. Wenn eine Deinstallation Daten entfernen kann, machen Sie die Richtlinie ausdrücklich deutlich und prüfen Sie sie mit synthetischen Datensätzen.

Berücksichtigen Sie bei Extra Properties oder individuellen Tabellen Shop- und Sprachvarianten. Eine Migration, die nur den Standardshop erhält, kann in einem einfachen Testdatensatz erfolgreich wirken und zugleich Informationen verlieren, die für einen Multistore-Kunden wichtig sind.

Verwenden Sie keine destruktive Bereinigung, nur damit sich das Paket während der Entwicklung sauber neu installieren lässt. Das kommerzielle Lebenszyklusverhalten muss die Kundenerwartungen und die veröffentlichte Richtlinie des Moduls widerspiegeln.

Validieren Sie das auslieferbare Artefakt

Führen Sie die Abnahmetests gegen das Archiv aus, das Kunden herunterladen werden. Eine Entwicklungskopie kann erzeugte Ressourcen, Drittanbieterabhängigkeiten oder Konfigurationsdateien enthalten, die im gepackten Modul fehlen.

Prüfen Sie die Archivstruktur und die erforderlichen Dateien. Bestätigen Sie die Installation über das unterstützte Back Office oder den Bereitstellungsablauf und das Laden der Ressourcen ohne Entwicklungswerkzeuge. Behalten Sie Tests und Build-Artefakte nur dort bei, wo der Verteilungsprozess sie bewusst benötigt.

Prüfen Sie, dass keine Zugangsdaten, lokalen Umgebungsdateien oder Produktionsauszüge enthalten sind. Dies ist eine konkrete Paketprüfung und kein Grund, sachfremde Compliance-Inhalte in die Benutzeroberfläche des Produkts aufzunehmen.

Erfassen Sie die Artefaktprüfsumme oder Build-Kennung zusammen mit den Testergebnissen. Wenn ein Paket nach der Qualifizierung neu erstellt wird, ermitteln Sie Inhaltsänderungen und wiederholen Sie betroffene Prüfungen. Eine Versionsbezeichnung allein unterscheidet nicht zwei verschiedene Archive mit derselben Nummer.

Geben Sie einer Unterstützungseinschränkung eine durch Tests prüfbare Grenze

Eine Einschränkung sollte das ausgeschlossene Verhalten benennen und nicht nur erklären, dass bestimmte Funktionen nicht unterstützt werden. Wenn eine Erweiterung den bisherigen Verwaltungsablauf unterstützt, aber nicht den migrierten, erfassen Sie die betroffene Seite und den Test, der die Lücke belegt. Wenn eine Zahlungsintegration eine bestimmte Einseiteninteraktion ausschließt, nennen Sie diese Interaktion und die unterstützte Alternative.

Stellen Sie eine Umgehung über ein Flag nicht als dauerhafte Garantie dar. Sie kann bei der Kandidatenbewertung nützlich sein, doch eine künftige Version kann den alten Ablauf entfernen. Benennen Sie einen Verantwortlichen für die Anpassung und verfolgen Sie die Bedingung, unter der die Einschränkung aufgehoben wird.

Bewahren Sie bei externen Abhängigkeiten die versionsspezifische Erklärung des Anbieters zusammen mit Ihren Ergebnissen auf. Wenn der Anbieter später die Unterstützung zurückzieht oder einen Vertrag ändert, macht der Nachweisbestand deutlich, welche Kundenkombinationen überprüft werden müssen.

Dies verbessert auch die Einordnung von Supportfällen. Ein Vorfall innerhalb der angegebenen Matrix ist eine mögliche Regression. Ein Vorfall außerhalb ist weiterhin eine Untersuchung wert, sollte aber nicht mit einer bereits qualifizierten Kombination verwechselt werden.

Beschreiben Sie den Unterschied in für Händler verständlichen Begriffen: Vorgang, Versionen und praktische Auswirkung. Interne Namen von Testsammlungen helfen Ingenieuren, sollten jedoch nicht die einzige Erklärung für den Kunden sein.

Veröffentlichen Sie Einschränkungen, die Händlern bei Entscheidungen helfen

Versionshinweise sollten nennen, welches Verhalten neu unterstützt wird, welche Kombinationen geprüft wurden und was weiterhin ausgeschlossen ist. „Verschiedene Kompatibilitätsverbesserungen“ sagt Händlern wenig darüber, ob ihr Checkout- oder Multistore-Ablauf abgedeckt ist.

Bieten Sie frühen Testern eine kurze Reproduktionsvorlage: Core-, Modul- und Theme-Versionen, aktive Flags, Shopkontext und Aktionsfolge. Dies reduziert Supportgespräche, die nur der Rekonstruktion der Umgebung dienen.

Vergleichen Sie nach der offiziellen Veröffentlichung der stabilen Version 9.2 deren abschließende Änderungen mit dem qualifizierten Kandidaten und führen Sie die betroffenen Teile der Matrix erneut aus, bevor Sie die Unterstützungsaussage erweitern. Ein bestandener Kandidatentest ist wertvolle Vorbereitung, bleibt aber an das Kandidatenartefakt gebunden.

Eine belastbare Kompatibilitätsaussage ist daher ein Nachweispaket: ein begrenzter Unterstützungsvertrag, gezielte Regressionsfälle, ein verifiziertes auslieferbares Archiv und ehrliche Einschränkungen. Das hilft Händlern bei der Bereitstellungsentscheidung und gibt dem Anbieter eine überschaubare Supportgrenze.

Zum Kontext der zugrunde liegenden Plattform lesen Sie unseren Leitfaden zur Modulentwicklung für PrestaShop 9 und wenden Sie die obigen versionsspezifischen Prüfungen auf die bewertete Installation an.

Bei der Auswahl einer Erweiterung sehen Sie sich die PrestaShop-9-Module von PrestaSuite an und gleichen Sie die dokumentierte Versionsunterstützung und die Integrationsanforderungen mit Ihren eigenen Testergebnissen ab.