PrestaShop 9.2 oder 9.1.5: Welche Version passt zum nächsten Schritt?
Für einen funktionierenden PrestaShop-9.1.5-Shop geht es bei der Entscheidung nicht einfach darum, ob 9.2 mehr Funktionen bietet. Es geht darum, ob deren Bewertung jetzt ein geschäftliches Problem löst und welche Abhängigkeiten vor einer späteren Produktionsänderung verstanden werden müssen.
Am 26. September 2026 kennzeichnet die offizielle Veröffentlichungsliste 9.1.5 als neueste stabile Version und 9.2.0-rc.1 als Vorabversion. Dadurch sind Produktionswartung und die Bewertung von 9.2 unterschiedliche Tätigkeiten. Offizielle PrestaShop-Veröffentlichungen.
Dieser Vergleich setzt voraus, dass Sie bereits den 9.1-Zweig betreiben oder pflegen. Er ist eine Entscheidungshilfe, keine Upgrade-Anleitung oder allgemeine Einführung in PrestaShop 9.
Sobald die Versionswahl geklärt ist, nutzen Sie den isolierten RC1-Staging-Ablauf, um die Bewertung des Kandidaten in eine kontrollierte Staging-Übung zu verwandeln.
Mit der Aufgabe jeder Version beginnen
Ihr stabiler Shop verarbeitet echte Zahlungen, Kundenkommunikation und Auftragsabwicklung. Seine unmittelbare Anforderung ist zuverlässiger Betrieb mit unterstützten Abhängigkeiten. Eine RC-Umgebung beantwortet eine andere Frage: Kann die nächste Version Ihre Abläufe unterstützen, und was muss angepasst werden?
Lassen Sie nicht eine Umgebung beide Zwecke erfüllen. Ein Versuch, der echte Versandaufträge oder Marketingereignisse sendet, ist nicht mehr bloß explorativ. Ein Produktionsdeployment nur zur Prüfung einer neuen Funktion bringt Folgen mit sich, die nichts mit dem Wert des Experiments zu tun haben.
Die Ankündigung zu 9.1.5 umfasst Wartungs- und Sicherheitsarbeiten am bestehenden Zweig. Ihre Beschreibung von 9.2 als Beta entspricht dem Datum, an dem diese Ankündigung verfasst wurde; der neuere Versionsindex nennt inzwischen RC1. Das erinnert daran, Daten zu vergleichen, statt jede offizielle Seite gleichzeitig als aktuell zu betrachten. Ankündigung zu 9.1.5.
Dokumentieren Sie den tatsächlichen stabilen Ausgangsstand, den Sie erhalten wollen: Kernversion, Modulversionen, Theme, aktive Integrationen und bekannte lokale Änderungen. Ein Vergleich mit einem undokumentierten Shop ist schwer zu interpretieren, weil scheinbare Unterschiede vom Ausgangsstand statt von der neuen Version stammen können.
Ablaufmöglichkeiten statt Funktionszahlen vergleichen
Die folgende Tabelle übersetzt die Richtung von 9.2 in Fragen, die ein Shop beantworten kann. Sie besagt nicht, dass 9.1.5 sämtliche ähnlichen Ergebnisse fehlen; Module und individuelle Entwicklungen können diese bereits liefern.
| Bereich | Frage für den 9.1.5-Shop | Frage für eine 9.2-Bewertung |
|---|---|---|
| Checkout | Erfüllt der aktuelle Kaufablauf die Zahlungs- und Versandanforderungen? | Kann die native Einseitenoption dieselben Regeln erfüllen? |
| Zusätzliche Geschäftsdaten | Wer ist für eigene Tabellen und Integrationskonventionen zuständig? | Könnten ausgewählte Felder den neuen nativen Erweiterungsmechanismus nutzen? |
| Administrative Unterstützung | Welche wiederholten Abfragen beanspruchen Mitarbeiterzeit? | Kann eine begrenzte dialogbasierte Aufgabe überprüfbare Ergebnisse liefern? |
| Backoffice-Anpassung | Welche Seiten und Verhaltensweisen ändern Erweiterungen? | Funktionieren diese Erweiterungen auf den relevanten migrierten Pfaden? |
| Integrationsclients | Welche Schnittstellenverträge werden heute vorausgesetzt? | Welche versionsspezifischen Änderungen erfordern Vertragstests? |
Diese neuen Richtungen werden in der offiziellen Ankündigungsreihe zu 9.2 vorgestellt. Betrachten Sie die Tabelle als Bewertungsrahmen, nicht als Kompatibilitätsgarantie. Funktionsankündigung zur Beta von 9.2.
Diese Unterscheidung ist für die Budgetplanung wichtig. „Die neue Version enthält einen Checkout“ beschreibt Verfügbarkeit. „Unsere Lieferdatumserweiterung und unser Zahlungsmodul bestehen den neuen Ablauf“ beschreibt einen Beleg. Nur die zweite Aussage kann eine shopspezifische Einführungsentscheidung stützen.
Gemeinsame Fehlerbehebungen von echten Versionsunterschieden trennen
Ein langes Änderungsprotokoll kann den scheinbaren Abstand zwischen zwei Versionen übertreiben, wenn jede aufgeführte Fehlerbehebung als exklusiv für einen Zweig gezählt wird. Änderungen können zurückportiert werden. Eine spätere Ankündigung kann außerdem Verbesserungen wiederholen, die bereits während einer Beta besprochen wurden.
Wenn eine bestimmte Fehlerbehebung Ihre Entscheidung motiviert, prüfen Sie die relevanten Veröffentlichungs- oder Commit-Belege für beide Ausgangsstände. Schließen Sie nicht darauf, dass ein Fehler in 9.1.5 existiert, nur weil ihn ein Änderungsprotokoll zu 9.2 erwähnt. Nehmen Sie umgekehrt nicht an, dass zwei ähnlich benannte Korrekturen dasselbe Verhalten abdecken.
Eine praktische Vergleichsnotiz hat vier Felder: das beobachtete Problem, den reproduzierbaren Fall des aktuellen Shops, die möglicherweise passende Änderung im Ursprungsprojekt und das Ergebnis dieses Falls auf dem Kandidaten. So wird keine Version allein anhand eines Issue-Titels gewählt.
Wenn beispielsweise eine Versandintegration nach einer Adressänderung fehlschlägt, bewahren Sie den genauen Warenkorb, die Länder, Modulversionen und Aktionsfolge auf. Ein Änderungsprotokolleintrag zum Versandzustand ist ein Ansatzpunkt für eine Untersuchung. Er ist kein Beweis, dass der Fehler Ihrer Integration behoben wurde.
Unterscheiden Sie außerdem zwischen einer fehlenden und einer defekten Funktion. Unterstützt Ihr bisheriges Modul eine Geschäftsregel, die der Ablauf des Kandidaten nicht bereitstellt, können auch beliebig viele Regressionstests keine Gleichwertigkeit belegen. Diese Lücke erfordert eine Produkt- oder Integrationsentscheidung.
Drei Shops können zu unterschiedlichen Ergebnissen kommen
Ein Händler vor einer saisonalen Kampagne
Stellen Sie sich einen Shop vor, dessen bisheriger Checkout funktioniert und dessen unmittelbare Herausforderung eine große Werbekampagne ist. Sinnvoll ist, die stabile Umgebung zu pflegen und eine separate Kandidatenbewertung zeitlich zu begrenzen. Die Kampagne wird nicht sicherer, weil eine neuere Oberfläche existiert.
Wählen Sie für die erste Bewertung ein oder zwei kritische Szenarien: das Gutscheinverhalten der Aktion und die von Kunden am häufigsten genutzten Zahlungsarten. Zeigen sie Abhängigkeiten mit Arbeitsbedarf, dokumentieren Sie diese für ein späteres Projekt. Die Bewertung hat ihren Zweck erfüllt, ohne die Kampagne zu stören.
Eine Agentur, die ein angepasstes Backoffice pflegt
Eine Agentur kann einen stärkeren Grund für frühe Untersuchungen haben, auch wenn Händler noch nicht für die nächste Version bereit sind. Erweiterungsfehler zu finden, während Rückmeldungen zum Kandidaten noch möglich sind, lässt Zeit für Anpassung und Meldung.
Der Nutzen liegt hier in der Vorbereitung. Ordnen Sie jeder Anpassung ihre Seiten-, Formular-, Grid- oder Routenabhängigkeit zu. Prüfen Sie die relevanten Kandidatenpfade und schätzen Sie den Anpassungsaufwand. Die Entscheidung kann lauten: „Produktion auf 9.1.5 weiter unterstützen und gleichzeitig die Erweiterung auf 9.2 RC1 qualifizieren.“ Das ist ein stimmiger technischer Plan.
Ein Händler, der von einem Drittanbieter-Checkout abhängt
Ein Händler, der für Checkout-Anpassungen bezahlt, möchte möglicherweise die native Alternative bewerten. Beginnen Sie mit einer Gleichwertigkeitsinventur: Felder, Versand-Widgets, Zahlungsverhalten, Fehlerbehebung und Kundenkontoregeln.
Erfüllt der bestehende Checkout spezielle Geschäftsanforderungen, kann die native Option weiterhin Entwicklungsarbeit benötigen. Sind diese Anforderungen gering, könnte ein gezielter Prototyp klären, ob die Alternative tragfähig ist. Keines dieser Ergebnisse folgt allein aus dem Wort „nativ“.
Diese Szenarien dienen der Veranschaulichung. Sie berichten keine Ergebnisse aus Kundenshops und behaupten keinen gemessenen geschäftlichen Vorteil einer Version.
Belege zu Abhängigkeiten vor Annahmen stellen
Stellen Sie Anbietern konkrete Fragen. „Unterstützt Ihr Modul PrestaShop 9?“ ist für einen neuen Checkout oder einen experimentellen Seitenpfad zu allgemein. Fragen Sie, welche Kern- und Modulversionen geprüft wurden, welches Theme verwendet wurde und ob die für Ihren Shop relevante Funktion aktiviert war.
Eine hilfreiche Belegreihenfolge umfasst ein reproduzierbares Testergebnis, eine dokumentierte Supportaussage mit Versionsgrenzen und eine ungeklärte Annahme. Halten Sie diese Kategorien im Vergleich getrennt. Das Schweigen eines Anbieters ist eine offene Abhängigkeit, kein bestandener Test.
Wenden Sie dieselbe Sorgfalt auf interne Module an. Ein Paket, das sich erfolgreich installiert, kann dennoch beim Speichern eines Formulars, Verarbeiten einer asynchronen Benachrichtigung oder Ausführen einer geplanten Aufgabe scheitern. Leiten Sie Abnahmefälle aus tatsächlichen Geschäftsvorgängen ab.
Nutzen Sie eine experimentelle Oberfläche nicht als Begründung für ein langfristiges Supportversprechen. Die Entwicklerhinweise stufen Teile der 9.2-Arbeit ausdrücklich ein. Fixieren Sie die für die Bewertung verwendete Implementierung und prüfen Sie den Vertrag erneut, wenn die stabile Version veröffentlicht ist. Versionsspezifische Entwicklerhinweise.
Die Entscheidung vor der Planung des nächsten Schritts aufschreiben
Eine Versionsentscheidung sollte festhalten, was jetzt geschieht, welche Belege fehlen und was die Entscheidung ändern würde. Zum Beispiel:
Produktion auf ihrem gepflegten stabilen Ausgangsstand belassen. Den Kandidaten-Checkout auf einer wegwerfbaren Installation bewerten. Die Einführung erneut prüfen, sobald eine stabile 9.2-Version verfügbar ist und Zahlungs-, Abhol- und Gutscheinszenarien mit unterstützten Modulversionen bestehen.
Diese Aussage ist hilfreicher als „warten, bis es bereit ist“, weil sie die Bereitschaftsbedingungen nennt. Sie vermeidet auch, sich auf ein erfundenes Veröffentlichungsdatum festzulegen.
Schätzen Sie den Aufwand in getrennten Kategorien: Kompatibilitätsuntersuchung, nötige Codeänderungen, Prüfung der Mitarbeiterabläufe, Vorbereitung einer späteren Bereitstellung und Supportübergabe. Ein kleiner Unterschied der Kernversion garantiert kein kleines Projekt, wenn mehrere Integrationen gleichzeitig ihr Verhalten ändern.
Löst der Kandidat kein aktuelles Problem und pflegen Sie keine betroffenen Erweiterungen, kann vorerst eine kurze Erkundung genügen. Führt er eine für Ihre Planung zentrale Funktion ein, investieren Sie in einen vertieften Prototyp. Bewahren Sie dessen Ergebnisse und Grenzen auf, damit die nächste Bewertung auf Belegen statt Erinnerungen beginnt.
Eine Entscheidungsnotiz benötigt auch eine Ablaufbedingung. Prüfen Sie sie erneut, wenn die offizielle stabile Version erscheint, eine kritische Abhängigkeit Unterstützung veröffentlicht oder sich die Geschäftsanforderung ändert. Ohne einen solchen Auslöser kann eine sinnvolle vorläufige Entscheidung zu einer unbefristeten Annahme ohne Verantwortlichen werden.
Fragen, die den Vergleich nicht allein entscheiden sollten
Ist 9.2 neuer? Ja, aber Versionsstatus und Bereitschaft der Abhängigkeiten bestimmen, wo sie hingehört. Neuheit belegt keine Produktionseignung.
Beweist eine erfolgreiche Neuinstallation Kompatibilität? Sie beweist, dass eine Installation abgeschlossen wurde. Sie beweist nicht, dass Ihr Theme, Ihre Integrationen, Geschäftsregeln oder historischen Daten korrekt funktionieren.
Sollten wir auf einen bestimmten Termin für die stabile Version warten? Nutzen Sie die offizielle Veröffentlichungsankündigung, sobald sie existiert. Ein Bereitschaftsplan sollte Bedingungen nennen und sich nicht auf ein ungeprüftes Datum verlassen.
Die praktische Wahl besteht heute meist aus zwei abgestimmten Wegen: zuverlässigen Betrieb auf dem stabilen Zweig erhalten und die für Ihren Shop relevanten 9.2-Funktionen untersuchen. Eine spätere Produktionsentscheidung kann sich dann auf eine endgültige Version und shopspezifische Belege stützen.
Für den zugrunde liegenden Plattformkontext lesen Sie unseren Leitfaden für ein sicheres Upgrade von PrestaShop 8 auf 9 und wenden Sie die obigen versionsspezifischen Prüfungen auf die Installation an, die Sie bewerten.