Bei der Bewertung von Zen Cart als mögliche Zielplattform legt die Validierung fest, welche Nachweise zeigen müssen, dass Daten, Beziehungen und Geschäftsanforderungen im Ziel funktionieren.
Wenn Zen Cart als Zielplattform eingesetzt werden soll, muss die Validierung mehr beweisen als das bloße Vorhandensein von Datensätzen. Weil Zen Cart selbst gehostet, modulbasiert und nach Jahren produktiven Betriebs oft stark angepasst ist, kann eine Migration vollständig aussehen und dennoch an geschäftskritischen Tests scheitern: Product Choices funktionieren nicht richtig, Rabatte lassen sich nicht erklären, Download-Produkte verlieren ihre Zugriffslogik, EZ-Pages brechen Navigation oder historische Orders erklären nicht mehr, was der Customer tatsächlich bezahlt hat.
Ein sinnvoller Validierungsplan trennt migrierte Records von Zen-Cart-Konfiguration. Products, Customers, Orders, Categories, Coupons, CMS Pages und andere unterstützte Records können im Migrationsergebnis geprüft werden. Payment Module, Shipping Module, Order-Total-Konfiguration, Tax Setup, Template-Verhalten, Plugin-Installation, Server-Bereitschaft und Checkout-Ausführung müssen als Bedingungen der Zielumgebung validiert werden. Die Migration ist erst launchbereit, wenn beide Seiten verstanden sind.
Was die Validierung für Zen Cart beweisen muss
Die Zen-Cart-Validierung sollte zeigen, dass migrierte Daten innerhalb des Betriebsmodells des Zielshops nutzbar bleiben. Der Shop-Betreiber sollte Katalogstruktur wiedererkennen, Customer- und Order-Historie prüfen, Product-Auswahl testen, Inhaltsseiten kontrollieren und bestätigen können, dass kritische kommerzielle Informationen Kundenservice und Go-live-Entscheidungen weiterhin unterstützen.
Die erste Frage lautet nicht, ob jede Datenbankzeile übertragen wurde, sondern ob jeder migrierte Record dieselbe geschäftliche Bedeutung trägt. Ein Product mit Attributen muss weiterhin die richtigen Kaufoptionen anbieten. Eine rabattierte Order muss genug Historie enthalten, um die Transaktion zu erklären. Eine Category-Hierarchie muss Browsing unterstützen. Ein Download-Product muss anders behandelt werden als ein physisches Product. Eine Page mit SEO- oder Vertrauensfunktion muss weiterhin erreichbar sein oder bewusst umgeleitet werden.
| Validierungsziel | Was es beweist | Fehlersignal |
|---|---|---|
| Data Presence | Erwartete Entitäten existieren in Zen Cart. | Counts stimmen, aber wichtige Beispiele fehlen. |
| Data Meaning | Records erklären weiterhin dieselben geschäftlichen Fakten. | Product Optionen, Preise, Order Totals oder Customer-Kontext wirken verändert. |
| Nutzbarkeit im Zielshop | Shop-Mitarbeitende können mit den Datensätzen arbeiten. | Admin-Oberflächen zeigen Daten, unterstützen aber Prüfung oder Kundenservice nicht. |
| Funktionsfähigkeit der Shop-Oberfläche | Customers können navigieren, suchen, auswählen und kaufen. | Navigation, URLs, Attribute oder Product Pages verhalten sich inkonsistent. |
| Abgrenzung des Migrationsumfangs | Probleme sind korrekt klassifiziert. | Lücken der Zielkonfiguration werden als Migrationsdefekte behandelt oder benutzerdefinierte Daten wird fälschlich als unterstützt angenommen. |
Diese Unterscheidung ist bei Zen Cart besonders wichtig, weil das Zielbetriebsmodell eine breite Administrationsfläche umfasst: Products, Attribute, EZ-Pages, Order-Total-Module, Payment Module, Plugins, Templates, Search, SEO und Security. Diese Bereiche erzeugen Validierungsanforderungen über Products, Customers und Orders hinaus. Ein Go-live Prüfung, das sie ignoriert, kann eine technisch abgeschlossene Migration mit einem unbewiesenen Shop freigeben.
Zielumgebung und Admin-Bereitschaft validieren
Ein Zen-Cart-Zielshop muss zunächst als Umgebung validiert werden, bevor das Migrationsergebnis beurteilt wird. Hosting, PHP- und MySQL-Kompatibilität, Dateiberechtigungen, SSL, Admin-Zugriff, Datenbankkonfiguration und Sicherheitsbereitschaft können beeinflussen, ob migrierte Daten nutzbar sind. Ist die Installation instabil, werden Validierungsergebnisse unzuverlässig, weil dieselben Records sich nach Umgebungsänderungen anders verhalten können.
Beginnen Sie mit der administrativen Basis. Bestätigen Sie, dass der Admin-Bereich erreichbar ist, der Shop nicht durch Installations- oder Berechtigungsprobleme blockiert wird, die Datenbankverbindung stabil ist und der Shop-Betreiber oder das technische Team Products, Categories, Customers, Orders, Module und Inhaltsdatensätze prüfen kann. Validierung darf nicht vollständig an die Shop-Oberfläche delegiert werden, weil viele Zen-Cart-Probleme zuerst im Admin-Kontext sichtbar werden.
Die Prüfung der Zielumgebung sollte außerdem trennen, was zur Migration gehört und was zum Store Setup. Fehlt im Checkout eine Zahlungsmethode, weil das Payment Module nicht konfiguriert ist, ist das nicht dasselbe wie ein Order-Data-Migrationsfehler. Erscheinen Shipping Optionen wegen unvollständiger Zone Rules nicht, sollte die Migration nicht für fehlendes Versandverhalten verantwortlich gemacht werden. Verbirgt ein Template Override Daten, kann der migrierte Record korrekt sein, während die Darstellungsebene unvollständig bleibt.
Eine praktische Prüfung der Zielumgebung sollte bestätigen:
- Admin-Zugriff für den Prüfer;
- Zielversion und Serverkompatibilität;
- stabile Database- und Dateiberechtigungen;
- SSL und Zugriff auf die Shop-Oberfläche;
- Zugriff auf Product-, Customer-, Order- und Inhaltsdatensätze;
- Trennung zwischen Migrationsbefunden und Zielkonfigurationsbefunden;
- dokumentierte Verantwortliche für Modul-, Template-, Hosting- und Plugin-Probleme.
Freigabekriterium: Der Zielshop ist stabil genug, dass migrierte Daten konsistent geprüft werden können, und jedes Umgebungs- oder Konfigurationsproblem wird außerhalb des Datenmigrationsergebnisses klassifiziert, sofern es nicht direkt die migrierten Records betrifft.
Categories, Products, Attribute und Downloads validieren
Katalogvalidierung ist der Kern der Zen-Cart-Prüfung. Products können von Categories, Linked Category-Zuordnung, Product Attributes, Optionsnamen, Optionswerte, Attributpreislogik, Specials, Aktionspreise, Mengenrabatte, Download-Regeln, Images, Metadata und Product-Status abhängen. Ein Count Check kann diese Beziehungen nicht beweisen.
Beginnen Sie mit der Category-Struktur. Zen-Cart-Shops können Category-Hierarchien, Linked Products und Product-Listing-Verhalten verwenden, das Browsing und Merchandising beeinflusst. Prüfen Sie Top Categories, untergeordnete Categories, Sortierreihenfolge, Product-Zuordnungen und duplizierte oder verknüpfte Platzierungen so, dass die beabsichtigte Nutzungserlebnis der Shop-Oberfläche erhalten bleibt. Ein Product kann migriert sein und trotzdem für Customers unsichtbar werden, wenn es in der falschen Category erscheint oder eine sekundäre Platzierung verliert.
Product-Attribute benötigen Grenzfälle, nicht nur gewöhnliche Products. Wählen Sie Stichproben mit einfachen Products, Products mit Pflichtattribute, preisverändernden Attributen, Attribute mit nur einem Wert, Download-Dateien, Specials oder Aktionspreise sowie Mengenrabatte oder Großhandelspreise. Der Prüfer sollte Product sowohl im Admin als auch in der Shop-Oberfläche öffnen, um gespeicherte Information und Kaufverhalten zu validieren.
| Katalog-Sample | Zu validieren |
|---|---|
| Einfaches Product | Name, Modell, Preis, Tax Class, Status, Category-Zuordnung, Bild, Metadata. |
| Attributreiches Product | Optionsnamen, Optionswerte, Pflichtauswahlen, Preisanpassungen, Anzeigereihenfolge. |
| Download-Product | Download-Zuordnung, Erwartung an den Order-Zugriff, dateibezogene Behandlung, Nutzbarkeit nach Checkout. |
| Linked Product | Platzierung über Categories, Canonical-Browse-Erwartung, Duplicate Risk. |
| Discounted Product | Specials, Aktionspreise, Mengenrabatt, gegebenenfalls Group-Pricing-Erwartung. |
| Image-heavy Product | Hauptbild, zusätzliche Bilder, Filename-Verhalten, Darstellung in der Shop-Oberfläche. |
Attributvalidierung sollte auf Kundenauswahl fokussieren. Existiert im Quellshop ein Größen-, Farb-, Format- oder Download-Option, darf der Ziel-Product diesen Text nicht nur irgendwo speichern. Customer oder Shop-Mitarbeitende müssen dieselbe kommerzielle Auswahl interpretieren können. Wenn ein Attribut Preis, Gewicht, Auslieferungsmethode, Download-Zugriff oder Interpretation der Order beeinflusst, benötigt es gezielte Validierung.
Freigabekriterium: Repräsentative Katalogstichproben zeigen korrekte Category-Zuordnung, Product Identity, Product-Status, Preiskontext, Images, Attributes, Download-Verhalten und Auswahllogik der Shop-Oberfläche.
Customers, Adressen, Orders und kommerzielle Historie validieren
Customer- und Order-Validierung muss beweisen, dass der migrierte Shop Kundenservice, Finanzprüfung und Referenz nach dem Go-live unterstützt. Historische Zen-Cart-Orders können Status, Customer-Details, Adressen, Products, im Checkout gewählte Attributes, Rabatte, Coupons, Gift Certificates, Versandkosten, Steuerpositionen, Fees, Zahlungsbezeichnungen und Order-Total-Module enthalten. Eine migrierte Order mit nur Products und Grand Total kann für operative Kontinuität unzureichend sein.
Beginnen Sie mit Customer-Identität und Adressdatensätzen. Prüfen Sie Customer-Namen, E-Mail-Adressen, Rechnungsadressen, Lieferadressen, Telefonfelder, Kontostatus und relevante Customer-Group- oder Pricing-Kontexte. Hatte die Quelle benutzerdefinierte Customer-Felder, Mitgliedschaftsbezeichnungen, B2B-Identifikatoren, Hinweise auf Steuerbefreiung oder Integrationsschlüssel, muss geklärt werden, ob sie im unterstützten Migrationsumfang lagen oder nicht standardmäßige Behandlung benötigen.
Order-Validierung sollte Beispiele enthalten, die kommerzielle Bedeutung beweisen. Prüfen Sie bezahlte Orders, stornierte Orders, erstattete oder teilweise korrigierte Orders, Orders mit Coupons, Gift-Certificate-Orders, Orders mit besonderen Versandmethoden, Orders mit Steuerabweichungen sowie Orders mit Product Attributes oder Downloads. Ziel ist nicht, jedes historische Modulverhalten als aktive Zielfunktion zu rekonstruieren. Ziel ist, die Order nachvollziehbar zu halten.
| Order-Nachweis | Validierungsfrage |
|---|---|
| Product-Positionen | Bleiben Positionen, Mengen, Attribute und Preise nachvollziehbar? |
| Order Totals | Sind Rabatte, Tax, Shipping, Fees, Coupons und Credits verständlich? |
| Statushistorie | Können Mitarbeitende den Order-Lebenszyklus nachvollziehen? |
| Customer- und Address-Daten | Kann der Kundenservice den Käufer und Ziel der Auftragsabwicklung identifizieren? |
| Payment- und Shipping-Labels | Bewahren Labels historische Methodeninformation, ohne aktive Konfiguration vorzutäuschen? |
| Externe Referenzen | Bleiben benötigte Gateway-, ERP-, Marketplace- oder Kundenservice-IDs verfügbar? |
Freigabekriterium: Repräsentative Customers und Orders bleiben für Kundenservice, Finanzen und Betrieb interpretierbar, wobei historische Evidenz klar von aktiver Zielkonfiguration getrennt ist.
Inhalte, Navigation, URLs, Search und SEO-Kontinuität validieren
Zen-Cart-Content kann über EZ-Pages, Define Pages, Product- und Category-Beschreibungen, Sideboxes, Templates, Language Files und Plugins verteilt sein. Die Validierung muss prüfen, ob launchrelevante Inhalte weiterhin erreichbar sind und ob Navigation und URLs die beabsichtigte Funktion erhalten.
Priorisieren Sie Richtlinienseiten, Lieferinformationen, Rückgabeinformationen, Markenseiten, Kaufratgeber, Landingpages und SEO-kritische Seiten. Wenn solche Pages als CMS Pages migriert oder über einen anderen Inhaltspfad behandelt werden, prüfen Sie Titel, Slugs oder URLs, interne Links, Formatierung, Metadata, Images und Navigationsplatzierung. Wird eine Page nicht migriert, entscheiden Sie über manuelle Neuerstellung, Weiterleitungsplanung oder bewusste Entfernung aus dem Migrationsumfang für den Go-live.
Validierung von Suche und SEO sollte Product-Namen, Modellnummern, Category-Namen und häufige Suchanfragen von Customers umfassen. Zen-Cart-Suche und SEO-Einstellungen beeinflussen, was Customers nach dem Go-live finden. Wenn Products zuvor über SKU-ähnliche Begriffe, Long-Tail Names, Attributes oder Category Terms gefunden wurden, sollten diese Suchvorgänge im Zielshop getestet werden.
URL-Validierung benötigt einen praktischen Weiterleitungsplan. Nicht jede Quell-URL kann oder sollte exakt erhalten bleiben, insbesondere wenn die Quellplattform ein anderes Routing-Modell verwendet. wichtige Product-, Category- und Content-URLs sollten jedoch vor dem Go-live geprüft werden, damit klar ist, welche URLs erhalten bleiben, welche umgeleitet und welche bewusst verändert werden.
Freigabekriterium: Kritischer Content ist vorhanden oder bewusst behandelt, wichtige Navigationspfade bleiben nutzbar, Suchstichproben finden erwartete Products und SEO-sensitive URLs besitzen eine klare Entscheidung zur Beibehaltung oder Weiterleitung.
Module, Plugins, Templates und Anpassungen validieren
Zen-Cart-Migrationen betreffen häufig Shops mit Plugins, benutzerdefinierten Templates, Override-Dateien, geänderten Modulen, benutzerdefinierten Feldern oder zusätzlichen Datenbanktabellen. Diese Elemente müssen als Abgrenzungen des Migrationsumfangs validiert werden. Datenmigration kann unterstützte Records übertragen, installiert aber nicht automatisch Plugins, rekonstruiert keine Template-Overrides, implementiert Modulverhalten nicht neu und bewahrt keine benutzerdefinierten Tabellen, sofern diese Arbeit nicht über den passenden Migrationspfad geprüft und akzeptiert wurde.
Plugin-Validierung sollte zwei Fragen beantworten. Erstens: Besitzt ein Quell-Plugin Daten, die erhalten werden müssen? Zweitens: Benötigt der Zielshop ein Zen-Cart-Plugin, Modul oder eine individuelle Implementierung, um Geschäftsverhalten nach der Migration zu reproduzieren? Das sind unterschiedliche Fragen. Die erste kann Datenextraktion und nicht standardmäßige Behandlung betreffen. Die zweite kann Zielimplementierung außerhalb des Migrationsumfangs betreffen.
Template-Validierung sollte prüfen, ob Daten sichtbar und nutzbar sind, nicht ob die neue Shop-Oberfläche visuell identisch mit der alten aussieht. Wenn migrierte Product Descriptions, Attributes, Images, Prices oder Inhaltsseiten im Admin vorhanden, aber in der Shop-Oberfläche unsichtbar sind, kann die Ursache Template-Konfiguration und nicht Datenmigration sein. Erwartet ein benutzerdefiniertes Template Felder, die nicht migriert oder unterstützt wurden, muss der Migrationsumfang gegebenenfalls überprüft werden.
Externe Abhängigkeiten sollten ebenfalls getestet oder dokumentiert werden. ERP-Exporte, Versanddatenfeeds, Buchhaltungssysteme, E-Mail-Systeme, Analytics, Marketplace-Tools und Reporting-Integrationen können von IDs, Status, SKU-Formaten, Order-Nummern oder benutzerdefinierte Felder abhängen. Müssen diese Werte stabil bleiben, sollten sie vor einer breiteren Migration anhand von Stichproben geprüft werden.
Freigabekriterium: plugin-eigene Daten, Modulverhalten, Template-Darstellung, benutzerdefinierte Felder und externe Identifikatoren sind entweder validiert, bewusst ausgeschlossen oder an nicht standardmäßige Behandlung beziehungsweise Zielimplementierung eskaliert.
Repräsentative, breitere und spätere Zen-Cart-Ergebnisse validieren
Repräsentative Tests sollten die Zen-Cart-Strukturen sichtbar machen, die Kauf- oder historische Bedeutung am ehesten verändern. Das Sample sollte ein Product mit mehreren Attributtypen, gegebenenfalls Attributpreislogik oder Bestand, eine Pflichtauswahl, ein Download-Product, ein Product in mehreren Categories, einen Customer mit mehreren Adressen, eine Order mit Coupons, Gift Certificates, Taxes oder ungewöhnlichen Status, eine EZ-Page oder Richtlinienroute und einen plugin-basierten oder Datensatz mit benutzerdefiniertem Feld enthalten.
Migration im größeren Umfang sollte beweisen, dass die genehmigte Interpretation von Attributes, Downloads, Customers, Orders, Categories, Coupons, Reviews, Inhalte und Plugins über Produktionsdaten hinweg vollständig bleibt. Prüfen Sie seltene Attributes, deaktivierte Products, alte Customers, Gast-Orders, historische Downloads, tiefe Category Paths, alte Coupons, Reviews, priorisierte Inhalte und jede Plugin- oder Entscheidung zu benutzerdefinierten Tabellen. Historische Orders und Download-Referenzen müssen verständlich bleiben, dürfen aber nicht als Beweis dafür gelten, dass aktive Zahlungs-, Versand-, Steuer-, Checkout-, E-Mail-, Download-Berechtigungs- oder Template-Modul-Konfiguration eingerichtet sind.
| Nachweisstufe | Zen-Cart-Nachweis | Fehlersignal |
|---|---|---|
| Repräsentativer Migrationstest | Repräsentative Attributes, Downloads, Customers, Orders, Inhalte, URLs und Plugin-Datensätze können erklärt werden. | Sample enthält nur einfache Products und gewöhnliche Orders. |
| Migration im größeren Umfang | Seltene, ältere, deaktivierte und hochwertige Records folgen dem genehmigten Modell im größeren Umfang. | Anzahlen stimmen, während Attributausnahmen, alte Orders, Downloads oder priorisierte Routes unbewiesen bleiben. |
| Freigabenachweis | kundenbezogene und Admin-Szenarien sind wiederholbar, jeder offene Punkt hat eine Entscheidung und eine verantwortliche Person. | Freigabe hängt vom Quellshop oder von undokumentierten Plugin-Annahmen ab. |
Spätere Aktionen erfordern proportionale Revalidierung:
| Spätere Aktion | Erforderliche Zen-Cart-Revalidierung |
|---|---|
| Unter der akzeptierten Konfiguration fortfahren | Bestätigen, dass spätere Products, Customers, Orders, Blog Posts, Attributes, Downloads und Routes der genehmigten Interpretation folgen. |
| Mit überarbeiteter Konfiguration fortfahren | Geänderte Filter, Zuordnungen, Datenkategorieauswahl, Attribute-Entscheidungen, Plugin-Felder, Inhalte und Routen erneut prüfen und betroffene Kauf- und Admin-Szenarien wiederholen. |
| Ein eigenständiges neues Migrationsergebnis erzeugen | Neue Validierungsbasis für Products, Optionen, Customers, Orders, Inhalte, URLs, Module und Integrationen erstellen, bevor das neue Ergebnis freigegeben wird. |
Zen-Cart-Go-live-Bereitschaft mit Pass, Watch oder Block entscheiden
Freigabe zum Go-live für Zen Cart sollte Evidenz als Pass, Watch oder Block klassifizieren. Jeder Status sollte das konkrete geprüfte Product, Attribute, Download, Customer, Order, Route, Plugin oder benutzerdefiniertes Feld benennen.
| Entscheidungsstatus | Erforderliche Evidenz | Bedeutung für Go-live |
|---|---|---|
| Pass | Erwartetes Katalog-, Historie-, Content- oder plugin-basiertes Ergebnis ist reproduzierbar und es bleibt keine wesentliche Unsicherheit. | Der geprüfte Bereich unterstützt den Go-live. |
| Watch | Migrationsergebnis ist nutzbar, aber eine dokumentierte nicht blockierende Template-, Content-, Merchandising-, Plugin- oder Konfigurationsaufgabe bleibt offen. | Go-live darf nur mit verantwortlicher Person, Frist und Nachweis der Nachprüfung fortfahren. |
| Block | Product kann nicht korrekt gekauft werden, Download oder Order ist irreführend, priorisierte Route schlägt fehl oder vereinbarter Ergebnis ist unbrauchbar. | Freigabe zum Go-live wird bis zur Korrektur oder formal akzeptierten Änderung des Migrationsumfangs zurückgehalten. |
Für Zen Cart vergleichen Sie vereinbarte Ergebnisse mit genehmigten Attributfiltern, Plugin-Zuordnungen, Regeln für benutzerdefinierte Tabellen und Konfigurationsergebnisse. Vereinbarte nicht standardmäßige Migrationsergebnisse werden gegen akzeptierte Plugin-Datensätze, benutzerdefinierte Tabellen, externe Identifikatoren, individuelle Transformationen oder besondere Attributbeziehungen geprüft. Validierung bestätigt das vereinbarte Ergebnis und impliziert keine zusätzliche Implementierungsarbeit.
Das Prüfprotokoll sollte erwartete Funktionsweise, beobachtetes Ergebnis, Entscheidungsstatus, verantwortliche Person, Behandlungspfad und Nachweis der erneuten Prüfung dokumentieren. So bleibt Zielkonfiguration von Migrationsdefekten getrennt, und die Go-live-Entscheidung ist über Katalog-, Betriebs-, Technik-, Content- und Marketing-Verantwortliche hinweg nachvollziehbar.
Fazit
Die Zen-Cart-Validierung sollte Geschäftskontinuität beweisen, nicht nur technische Fertigstellung. Die Zielumgebung muss stabil sein, der Katalog Product-Bedeutung erhalten, Orders nachvollziehbar bleiben, Content und URLs Navigation für Customers unterstützen und Plugins oder Anpassungen korrekt klassifiziert sein.
Der stärkste Validierungsprozess nutzt repräsentative Ergebnisse repräsentativer Tests, um zu entscheiden, was bereit ist, was genehmigte Migrationsanpassungen benötigt, was nicht standardmäßige Behandlung erfordert und was zur Einrichtung der Zielumgebung gehört. Migration im größeren Umfang sollte erst freigegeben werden, wenn sowohl migrierte Daten als auch Zen-Cart-Konfigurationsverantwortung verstanden sind.
Häufige Fragen
Was sollte bei einer Zen-Cart-Migration zuerst validiert werden?
Beginnen Sie mit repräsentativen Attributes, stock- oder preissensitiven Choices, Download-Products, Customer- und Order-Historie, priorisiertem Content und einem plugin-basierten oder Fall mit benutzerdefiniertem Feld. Diese Records zeigen strukturelle Probleme früher als reine Prüfungen der Datensatzanzahl.
Reichen Datensatzanzahlen für die Freigabe einer breiteren Migration aus?
Nein. Anzahlen zeigen das Vorhandensein von Datensätzen, aber nicht Funktionsweise der Attribute, Bedeutung von Downloads, historische Order-Lesbarkeit, Kontinuität der Routen, Verantwortung für Plugins oder Nutzbarkeit der Live-Shop-Oberfläche.
Wie sollten Download-Products validiert werden?
Validieren Sie Product Type, Datei- oder Referenzbeziehung, historischen Kaufkontext und gegebenenfalls vorhandene Zugriffsnachweis. Berechtigungen für die aktive Auslieferung und Download-Konfiguration bleiben separate Verantwortung des Zielshop.
Was trennt die Validierung historischer Zen-Cart-Orders von der Freigabe des Live-Checkout?
Historische Validierung beweist, dass Positionen, Attribute, Summen, Steuern, Rabatte, Status, Zahlungsbezeichnungen und Versandbezeichnungen verständlich bleiben. Live-Checkout Module und operative Einstellungen benötigen getrennte Konfigurationsnachweise.
Wann ist ein Zen-Cart-Befund ein Block?
Block gilt, wenn Product-Auswahl oder Pricing falsch ist, ein Download oder eine Order irreführend ist, ein priorisierter Pfad ausfällt oder eine genehmigte Migrationsanpassung beziehungsweise ein nicht standardmäßiger Migrationsoutput unbrauchbar ist.
Was muss nach einer späteren Zen-Cart-Migrationsaktion erneut validiert werden?
Alle betroffenen Products, Customers, Orders, Blog Posts, Attributes, Downloads, URLs, Plugin-Felder und benutzerdefinierte Beziehungen. Eine geänderte Konfiguration oder ein separates neues Ergebnis benötigt umfassenderen Nachweis als eine unveränderte Fortsetzung.