PrestaShop 9.2 Feature-Flags: beide Back-Office-Pfade testen
Ein Feature-Flag verändert den getesteten Codepfad. Zwei Tester können dieselbe PrestaShop-Version ausführen, scheinbar dieselbe Back-Office-Seite öffnen und dennoch unterschiedliche Implementierungen testen. Ohne ein Flag-Verzeichnis können ihre Ergebnisse widersprüchlich wirken.
In der Ankündigung von Version 9.2 RC1 verweist PrestaShop Tester auf Erweiterte Einstellungen → Neue und experimentelle Funktionen. Prüfen Sie auf dieser Seite die in der installierten Kandidatenversion verfügbaren Schalter. Mit Stand vom 26. September 2026 ist das zugehörige Release weiterhin eine Vorabversion. Offizielle RC1-Hinweise zu Feature-Flags.
Dieser Artikel behandelt die Bedienung und das Testen von Flags. Der ergänzende Artikel zur Symfony-Migration behandelt den Erweiterungscode hinter migrierten Seiten.
Wenn ein Schalter eine migrierte Verwaltungsseite auswählt, berücksichtigen Sie die Symfony-Migrationsprüfungen für Modulentwickler, damit der Test dem tatsächlichen Erweiterungsvertrag folgt.
Verfügbarkeit, Reife und Aktivierung unterscheiden
Drei getrennte Fragen werden oft in „Ist die Funktion bereit?“ zusammengefasst. Ist die Implementierung in diesem Paket enthalten? Welchen Reifegrad weist das Projekt ihr zu? Ist sie in dieser Installation aktiviert?
Eine innerhalb eines Flag-Systems als stabil gekennzeichnete Funktion kann dennoch in einem Release Candidate ausgeliefert werden. Eine experimentelle Fähigkeit kann auch nach einem stabilen Core-Release optional bleiben. Ein installiertes Modul kann ebenfalls Verhalten bereitstellen, das seiner eigenen Konfiguration unterliegt.
Bewahren Sie in einem Testprotokoll alle drei Fakten auf. „Länder getestet“ ist unvollständig, wenn der alte und der migrierte Pfad nebeneinander existieren können. „Mit aktiviertem migriertem Länder-Pfad in diesem Kandidaten-Build getestet“ beschreibt eine aussagekräftige Umgebung.
Leiten Sie den Flag-Zustand nicht aus einem Screenshot ab. Eine Seite kann nach der Migration optisch ähnlich aussehen. Lesen Sie die Konfiguration und prüfen Sie gegebenenfalls die aktive Route oder Implementierung mit den unterstützten Diagnosemöglichkeiten der installierten Anwendung.
Nehmen Sie ebenso wenig an, dass das Deaktivieren einer Funktion Datenänderungen rückgängig macht, die während ihrer Aktivierung vorgenommen wurden. Ein Schalter wählt Verhalten aus; er ist nicht automatisch ein Transaktionsrollback oder Datenbank-Downgrade.
Wissen, welche Pfade der Test abdecken soll
Die Entwicklerhinweise zu Version 9.2 nennen die folgenden Schalter für migrierte Seiten:
| Seite | Dokumentiertes Flag |
|---|---|
| Länder | country |
| Warenrücksendung | merchandise_return |
| Ein Modul einhängen | hook_module_v2 |
| Schnellzugriff | quick_access |
| Übersetzungen des E-Mail-Textes | email_body_translation |
| Steuerregeln | tax_rules_group |
Diese Namen stammen aus der versionsspezifischen Dokumentation, deren Absatz zum Release-Status noch ältere Beta-Formulierungen enthält. Verwenden Sie für den Release-Status die neuere RC-Ankündigung und prüfen Sie die Schalter im exakt installierten Build. Flag-Referenz für Version 9.2.
Die Tabelle verspricht nicht, dass jedes Flag unbegrenzt bestehen bleibt. Ein Flag kann entfernt werden, wenn ein Pfad zur Standardimplementierung wird. Verankern Sie keine dauerhafte Supportrichtlinie im Code, die auf der fortgesetzten Verfügbarkeit eines alten Schalters beruht.
Bestimmen Sie für jede von Ihrem Team angepasste Seite, ob Sie den aktuellen Pfad, den alternativen Pfad oder beide testen müssen. Unbeteiligte Schalter zu testen erzeugt unnötige Informationen. Einen Schalter zu übersehen, der eine angepasste Seite steuert, hinterlässt eine echte Abdeckungslücke.
Eine Ausgangsbasis vor jeder Änderung erfassen
Dokumentieren Sie Core-, Modul- und Theme-Versionen, den aktuellen Shop-Kontext und sämtliche relevanten Flag-Zustände. Erstellen Sie vor Vorgängen, die persistente Daten ändern können, eine wiederherstellbare Testmomentaufnahme.
Verwenden Sie einen kleinen Testdatensatz, der auf den Zweck der Seite abgestimmt ist. Für Länder könnte dies ein synthetischer Konfigurationseintrag und das davon abhängige Shop-Verhalten sein. Für Schnellzugriff könnte es ein Testlink und ein Mitarbeiter mit eingeschränkten Berechtigungen sein. Der Testdatensatz sollte das erwartete Ergebnis sichtbar machen.
Ändern Sie einen relevanten Schalter und wiederholen Sie dann denselben Geschäftsvorgang. Halten Sie andere Variablen nach Möglichkeit konstant. Wenn Sie gleichzeitig mehrere Fähigkeiten aktivieren, Module aktualisieren und Berechtigungen ändern, lässt sich ein Fehler nicht mehr eindeutig zuordnen.
Eine Basisnotiz sollte auch den Sitzungszustand beschreiben. Offene Tabs und zwischengespeicherte Ressourcen entsprechen möglicherweise nicht dem neu ausgewählten Pfad. Beginnen Sie den Vergleich mit einer frischen Navigation und bestätigen Sie die aktive Implementierung, bevor Sie Belege sammeln.
Verlassen Sie sich bei der ursprünglichen Einstellung nicht auf Ihr Gedächtnis. Das Verzeichnis ermöglicht einem anderen Tester, den Vergleich später zu reproduzieren.
Das Geschäftsverhalten beider Pfade vergleichen
Testen Sie bei einem Verwaltungsformular das erste Laden, einen Validierungsfehler, erfolgreiches Speichern und erneutes Laden. Testen Sie bei einer Tabelle die relevante Liste, Filter und Zeilenaktionen. Testen Sie bei der Navigation den Link und die Berechtigungen des Mitarbeiters, der ihm folgt.
Die gewünschte Aussage ist meist eine Geschäftsinvariante: Dieselbe beabsichtigte Einstellung wird im selben Umfang gespeichert oder derselbe autorisierte Vorgang betrifft denselben Datensatz. Pixelgenaue Gleichheit ist nicht zwangsläufig das Ziel einer Migration.
Nehmen Sie einen Negativfall auf. Ein Mitarbeiter ohne Schreibrecht sollte es auf dem alternativen Pfad nicht erhalten. Ein ungültiger Wert sollte nicht akzeptiert werden, nur weil sich der Formularrenderer geändert hat. Ein shopspezifischer Speichervorgang sollte sich nicht auf alle Shops ausweiten.
Verwenden Sie ein Vergleichsprotokoll:
| Fall | Basispfad | Migrierter Pfad | Entscheidung |
|---|---|---|---|
| Gültige Testdaten speichern | Gespeichertes Ergebnis | Gespeichertes Ergebnis | Gleichwertig oder erklärte Abweichung |
| Ungültige Testdaten ablehnen | Validierungsverhalten | Validierungsverhalten | Keine unbeabsichtigte Persistenz |
| Eingeschränkter Mitarbeiter | Zulässige Vorgänge | Zulässige Vorgänge | Berechtigungsgrenze bewahrt |
| Nach dem Speichern neu laden | Angezeigter Wert und Umfang | Angezeigter Wert und Umfang | Persistenz bestätigt |
Eine Abweichung kann beabsichtigt sein. Dokumentieren Sie, warum sie akzeptabel ist, statt die neue Seite zu zwingen, einen alten Fehler oder eine undokumentierte Anpassung nachzuahmen.
Das Zurückschalten als separates Experiment behandeln
Ein häufiger Fehler ist anzunehmen, dass bei einem fehlerhaften neuen Pfad das Deaktivieren seines Flags die alte Umgebung vollständig wiederherstellt. Die alte Route kann erneut aktiv werden, doch während des Experiments bearbeitete Datensätze können geändert bleiben.
Schalten Sie nach dem Test des neuen Pfads nur über die unterstützte Oberfläche zurück und prüfen Sie denselben Testdatensatz. Bestätigen Sie, dass der alte Pfad den resultierenden Zustand lesen kann. Warnt die Kandidatendokumentation vor irreversiblen oder sich weiterentwickelnden Datenstrukturen, setzen Sie die entbehrliche Umgebung zurück, statt Reversibilität vorauszusetzen.
Löschen Sie keine Datenbankzeilen und ändern Sie den Flag-Speicher nicht manuell, um einen von der Anwendung nicht mehr angebotenen Schalter zu erzwingen. Das kann einen nicht unterstützten Mischzustand erzeugen und spätere Fehler irreführend machen.
Wenn ein Modul beide Pfade unterstützt, testen Sie, dass es dieselbe geschäftliche Wirkung nicht zweimal ausführt. Eine Kompatibilitätsschicht, die alte und neue Integrationen gleichzeitig registriert, kann sorgfältige Dispatch-Logik benötigen. Das Flag allein beweist nicht, dass das Modul einen Pfad korrekt ausgewählt hat.
Die Entfernung von Flags planen
Eine Supportstrategie nach dem Muster „Kunden sollen die neue Seite abschalten“ kann ein vorübergehender Workaround sein, ist aber kein dauerhafter Implementierungsplan. Verschwindet der alte Pfad später, verschwindet der Workaround mit ihm.
Verfolgen Sie, welche Anpassungen noch vom alten Pfad abhängen und welche Nachweise erforderlich sind, um diese Abhängigkeit zu entfernen. Nennen Sie das zuständige Modul oder die Agentur und den betreffenden Geschäftsvorgang.
Wird ein Flag in einer späteren Version entfernt, aktualisieren Sie Testnamen und Dokumentation. Ein Test, der angeblich einen deaktivierten alten Pfad prüft, obwohl der Schalter nicht mehr existiert, schafft falsche Sicherheit. Bevorzugen Sie verhaltensorientierte Fallnamen und dokumentieren Sie den Implementierungspfad als Umgebungsmetadaten.
Supportteams sollten das Flag-Verzeichnis mit jedem Vorfall aufbewahren. Früh danach zu fragen kann erklären, warum ein Problem in einem Shop reproduzierbar ist und in einem anderen nicht, ohne zufälliges Caching verantwortlich zu machen oder Module neu zu installieren.
Ein unterbrochenes Flag-Experiment behandeln
Angenommen, ein Tester aktiviert eine migrierte Seite, bearbeitet Testdaten und wird unterbrochen, bevor er das Ergebnis dokumentiert. Ein anderer Tester sollte den aktiven Zustand nicht aus dem unfertigen Bericht ableiten. Prüfen Sie den Schalter, öffnen Sie die Testdaten erneut und vergleichen Sie sie vor dem Fortfahren mit der gespeicherten Ausgangsbasis.
Verwenden Sie ein Experimentprotokoll mit drei ausdrücklichen Phasen: vorbereitet, durchgeführt und geprüft. Vorbereitet bedeutet, dass der Anfangszustand dokumentiert ist. Durchgeführt bedeutet, dass Aktionen und Beobachtungen erfasst wurden. Geprüft bedeutet, dass das Ergebnis interpretiert wurde und der endgültige Umgebungszustand bekannt ist.
Dies ist eine einfache Koordinationspraxis, keine neue PrestaShop-Funktion. Sie ist besonders hilfreich, wenn mehrere Personen eine Staging-Installation teilen und Funktionsschalter mehr als eine Testsitzung beeinflussen.
Vermeiden Sie konkurrierende Pfadvergleiche am selben gemeinsamen Testdatensatz. Wenn eine Person das Flag oder die übergeordnete Konfiguration ändert, kann sie das Ergebnis einer anderen ungültig machen. Verwenden Sie nach Möglichkeit getrennte entbehrliche Instanzen für unabhängige Experimente oder reservieren Sie die Umgebung für das betreffende Testfenster.
Geben Sie am Ende eines Experiments an, ob die Umgebung wiederhergestellt, für eine Fehlerreproduktion aufbewahrt oder stillgelegt wurde. Ein bewahrter Fehlerzustand kann ein hilfreicher Beleg sein, sollte aber gekennzeichnet werden, damit der nächste Tester ihn nicht mit der üblichen Ausgangsbasis verwechselt.
Diese Protokolle machen eine Flag-Änderung zu einem wiederholbaren Experiment. Sie ermöglichen außerdem, eine unterbrochene Untersuchung von einem Kandidatenfehler zu unterscheiden, wenn eine spätere Sitzung eine unerwartete Seite vorfindet.
Ein Schalter sollte Erkenntnisse liefern
Zweck der Bewertung eines Kandidaten-Flags ist herauszufinden, ob ein bestimmter Pfad einen bestimmten Vorgang unterstützt. Beenden Sie jedes Experiment mit dokumentiertem aktivem Zustand, Ergebnis und etwaigen daraus entstandenen Datenänderungen.
Scheitert ein Pfad, bewahren Sie einen minimal reproduzierbaren Fall auf. Besteht er, nennen Sie den getesteten Umfang, statt allgemeine Einsatzbereitschaft zu behaupten. Wurde er nie erprobt, lassen Sie ihn ausdrücklich ungetestet.
Feature-Flags ermöglichen eine schrittweise Migration, machen Versionsnummern allein aber weniger aussagekräftig. Ein sorgfältiges Verzeichnis und ein Vergleich beider Pfade verwandeln diese zusätzlichen Zustände in nützliche Nachweise statt verborgener Unsicherheit.
Zum Kontext der zugrunde liegenden Plattform sehen Sie sich unseren Leitfaden zur Modulentwicklung für PrestaShop 9 an und wenden Sie die obigen versionsspezifischen Prüfungen auf die Installation an, die Sie bewerten.