Wenn Zen Cart als mögliche Zielplattform ausgewählt wird, sollte die Vorbereitung den tatsächlichen Quellshop verständlich machen, bevor die Migrationskonfiguration festgelegt wird. Eine langjährig betriebene Installation kann native Products, verknüpfte Categories, Attribute, Downloads, Customer Pricing Groups, Order Totals, EZ-Pages, Define Pages, Templates, Plugins, Overrides, Sprachdateien und benutzerdefinierte Datenbankfelder miteinander kombinieren. Die Storefront kann konsistent wirken, obwohl die zugrunde liegenden Datensätze auf mehrere technische und fachliche Verantwortungsbereiche verteilt sind.
Ziel der Vorbereitung ist, diese Umgebung in kontrollierte Quellnachweise zu überführen. Für jeden wichtigen Bereich sollten die auszuführende Aktion, die verantwortliche Person, der erforderliche Nachweis und das Bereitschaftskriterium definiert werden. So lassen sich gewöhnliche Datensätze, Plattformkonfiguration, plugin-basierte Daten und benutzerdefiniertem Code voneinander trennen, bevor die Migrationskonfiguration beginnt.
Quellzugriff herstellen und die Zen-Cart-Umgebung dokumentieren
Beginnen Sie mit der eindeutigen Identifikation der Installation. Dokumentieren Sie Zen-Cart-Version, Hosting-Umgebung, Datenbank, Document Root, Admin-Pfad, aktive Sprachpakete, Währungen, Tax Zones, Templates, Plugins, Overrides und externe Synchronisationen. Derselbe sichtbare Shop kann sich unterschiedlich verhalten, wenn eine Installation aktuelle native Funktionen verwendet und eine andere von älteren Plugins oder direkten Dateiänderungen abhängt.
Bereiten Sie den für den ausgewählten Migrationspfad erforderlichen Quellzugriff vor. Datenbank-, Hosting-, Admin- oder Dateizugriff sind keine beliebig austauschbaren Optionen. Die technisch verantwortliche Person sollte den zur tatsächlichen Installation passenden Zugriff bereitstellen und verfügbar bleiben, wenn Berechtigungen, Allowlists, Dateipfade oder Datenbankpräfixe geklärt werden müssen.
| Aktion | Verantwortlich | Nachweis | Bereitschaftskriterium |
|---|---|---|---|
| Exakte Zen-Cart- und PHP-Umgebung dokumentieren | Verantwortliche für Hosting oder Technik | Versions-Screenshots, Umgebungsnotiz, Datenbankversion | Quellinstallation und Kompatibilitätskontext sind eindeutig. |
| Quellzugriff bestätigen | Verantwortliche für Zugriff | Verbindungsstatus, Allowlist-Details, Datenbankpräfix, Hinweis zum Dateistammverzeichnis | Die erforderliche Verbindung zur Quelle erreicht den richtigen Shop. |
| Templates, Overrides und Plugins inventarisieren | Entwickler oder Agentur | Aktives Template, Plugin-Liste, Override-Verzeichnisse, Liste modifizierter Dateien | Native Daten und codeabhängiges Verhalten lassen sich trennen. |
| Sprachen, Währungen, Tax Zones und Einheiten dokumentieren | Verantwortliche Person für Commerce | Settings-Nachweise und Liste aktiver Sprachen | Shopweite Werte, die Product- und Order-Bedeutung beeinflussen, sind dokumentiert. |
| Imports und externe Synchronisationen identifizieren | Verantwortliche Person für Integrationen | Feed-Zeitplan, Liste externer Systeme, Last-Run-Details | Werte, die sich während der Vorbereitung ändern können, haben eine benannte Autorität. |
Erstellen Sie nach Erfassung dieser Nachweise ein Änderungsprotokoll. Der laufende Handel kann fortgeführt werden, doch neue Plugins, Datenbankänderungen, umfangreiche Attributumbauten oder URL-Änderungen sollten dokumentiert werden, damit das vorbereitete Quellmodell nicht unbemerkt veraltet.
Products, Attribute, Downloads und Preisbeziehungen vorbereiten
Zen Cart verwendet Product-Attribute für auswählbare Werte, kundenseitige Texteingaben, Datei-Uploads, reine Informationen, Preis- oder Gewichtsanpassungen und Download-Dateien. Option Names, Option Values und die Attributzuweisung zu einem Product sind getrennte Datensätze. Manche Installationen verwenden außerdem Variantenbestands- oder abhängige Attributfunktionen, entweder nativ in aktuellen Versionen oder über Plugins.
Erstellen Sie ein Product-Inventar mit Product ID, Modell oder SKU, Status, Preis, Tax Class, Menge, Bestandsverhalten, Gewicht, Product Type, Manufacturer, Master Category, verknüpfte Categories, Bildern, Specials, Featured-Status, Mengenrabatten, Customer Pricing Groups, Attributen und gegebenenfalls Download-Referenzen. Die Nachweise sollten zeigen, welche Werte eine verkaufbare Auswahl identifizieren und welche nur beschreibend oder kundenseitig eingegeben sind.
| Quellmuster | Vorbereitung | Nachweis | Bereitschaftskriterium |
|---|---|---|---|
| Auswählbare Größe, Farbe oder Format | Option Name, Option Value, Attributzuweisung, Sortierung und Pflicht-/Standardstatus erfassen | Repräsentative Product IDs und Attributexport | Auswahlvokabular und Product-Beziehung sind vollständig. |
| Preis- oder gewichtsveränderndes Attribut | Anpassung, Prefix, Base-Price-Inclusion, Discount-Behandlung und zugehöriges Product erfassen | Preisbeispiel und Attributeinstellungen | Der kommerzielle Effekt ist explizit statt aus dem Label abgeleitet. |
| Text- oder Dateieingabe | Kaufspezifische Eingabe von wiederverwendbaren Optionenwerten trennen | Product-Liste und repräsentative Order Lines | Buyer-entered Data wird nicht mit bestandsgeführter Variante verwechselt. |
| Download-Product | Datei, Attribut, Expiry Days, Download-Anzahl und Speicherort dokumentieren | Product-/File-Manifest und zugängliche Originaldateien | Product-to-Download-Beziehung und Quelldatei sind verfügbar. |
| Variantenbestand oder Abhängigkeitsregel | Native oder Plugin-Verantwortung, Kombinationen, SKU und Quantity identifizieren | Kombinationstabelle oder Plugin-Export | Unabhängige Bestand- und Abhängigkeitsbeziehungen sind dokumentiert. |
| Customer-Group- oder Mengenpreis | Product, Gruppe, Schwelle, Betrag und Zeitraum dokumentieren | Inventar der Preisbeziehungen | Bedingte Preise werden nicht auf den Basispreis reduziert. |
Normalisieren Sie Attributlabels nicht und führen Sie Optionenwerte nicht ohne fachliche Freigabe zusammen. Ähnliche Namen können unterschiedliche Preis-, Bestands-, Download- oder Order-Line-Bedeutung tragen.
Categories, verknüpfte Products, Manufacturers und Auffindbarkeit dokumentieren
Zen-Cart-Products besitzen eine Master Category und können zusätzlich mit weiteren Categories verknüpft werden. Category-Hierarchie, Platzierung verknüpfter Products, Navigation nach Manufacturer, Specials, Featured Products, New-Product-Listings und Suche können gemeinsam Auffindbarkeit beeinflussen. Die Vorbereitung sollte Katalogklassifikation von Template-Menüs und Sideboxes trennen.
Bereiten Sie den Category-Hierarchie mit IDs, übergeordnete Beziehungen, Status, Sprachinhalt, Bildern, Sortierung, Product-Type-Restriktionen und wichtigen Routes vor. Für jedes Product in mehreren Categories dokumentieren Sie Master Category und verknüpfte Categories. Eine zusätzliche Verknüpfung darf nicht mit einem Product-Duplikat verwechselt werden.
| Bereich der Auffindbarkeit | Verantwortlich | Nachweis | Bereitschaftskriterium |
|---|---|---|---|
| Category-Hierarchie | Verantwortliche Person für den Katalog | Export der über- und untergeordneten Beziehungen und Liste beibehaltener Categories | Jede erhaltene Category hat eine bekannte übergeordnete Category und Zweck. |
| Master und verknüpfte Categories | Verantwortliche Person für Merchandising | Product-to-Category-Beziehungen | Gemeinsame Platzierung ist sichtbar, ohne Product-Duplikate zu erzeugen. |
| Manufacturer Records | Verantwortliche Person für Marken | Manufacturer-Liste, Product-Zuordnungen, Hinweise zu öffentlichen Routes | Öffentliche Markenbedeutung ist von internen Supplier-Daten getrennt. |
| Specials, Featured und New Listings | Verantwortliche Person für Merchandising | Aktive Product-Listen und Datumsregeln | Zeit- oder statusabhängiges Merchandising ist identifiziert. |
| Menüs und Sideboxes | Verantwortliche Person für die Shop-Oberfläche | Screenshots und Layout-/Modulhinweise | Darstellung ist von Katalogbeziehungen getrennt. |
Customers, Pricing Groups, Adressen und Order-Historie vorbereiten
Bei Customers sollten Account-Identität, Address-Book-Einträge, Autorisierungsstatus, Newsletter-Präferenz, Pricing Group, gegebenenfalls Wholesale Level, Gift-Certificate-Balance, Reviews und externe Identifikatoren getrennt dokumentiert werden. Eine Customer Pricing Group kann kommerzielles Verhalten beeinflussen und sollte als Beziehung statt als bloßes Label erfasst werden.
Die Vorbereitung der Orders dient dem Erhalt historischer Nachweise. Wählen Sie Orders, die Guest und Registered Checkout, Attribute, Downloads, Rabatte, Coupons oder Gift Certificates, Tax, Shipping- und Zahlungsbezeichnungen, Kommentare, Statushistorie, unterschiedliche Billing- und Shipping-Adressen sowie plugin-generierte Order Totals abbilden. Order-time Adressen und Product-Beschreibungen bleiben von aktuellen Customer- und Katalogdatensätzen getrennt.
| Datensatzbereich | Vorbereitung | Nachweis | Bereitschaftskriterium |
|---|---|---|---|
| Customer-Identität | Duplikate, Autorisierungsstatus, Pricing Groups und externe Schlüssel identifizieren | Liste der Customer-Ausnahmen | Identitätsausnahmen haben eine verantwortliche Person und eine Entscheidung. |
| Address Books | Wiederverwendbare Customer-Adressen von Order-Snapshots trennen | Beispiele für Customer- und Order-Adressen | Aktuelle Account-Daten und Transaktionshistorie werden nicht vermischt. |
| Pricing- oder Wholesale-Gruppen | Membership und jede beeinflusste Product-/Preisbeziehung erfassen | Group-to-Rule Matrix | Kommerzielle Bedeutung ist über den Gruppennamen hinaus dokumentiert. |
| Order Status und Kommentare | Labels, Reihenfolge, Kundensichtbarkeit und repräsentative Orders erfassen | Statusinventar | Historische Zustände können ohne alleinige Abhängigkeit vom Label interpretiert werden. |
| Order Totals | Subtotal, Tax, Shipping, Discount, Gift Certificate, Fee und Plugin-Zeilen identifizieren | Repräsentative Total-Sets | Jede wesentliche Anpassung hat einen bekannte verantwortliche Person in der Quelle. |
| Download-Historie | Gekaufte File Attributes, verbleibenden Zugriff und Order-Beziehung dokumentieren | Download-bezogene Orders | Kontext digitaler Käufe ist Teil des Quellnachweises. |
Historische Datensätze sollten nicht nur zur Vereinheitlichung verändert werden. Anomalien werden separat dokumentiert, wenn sie die ursprüngliche Transaktion erklären.
Plugins, Overrides, Templates und benutzerdefinierte Daten inventarisieren
Zen-Cart-Plugins können Felder, Tabellen, Preisregeln, Bestandslogik, Order Totals, SEO Routes, Customer Properties, Reports, Feeds oder Integrationen hinzufügen. Overrides und direkte Modifikationen können Verhalten ebenfalls verändern, ohne einen offensichtlichen Plugin-Datensatz zu erzeugen. Die Vorbereitung muss erfassen, welche Geschäftsdaten jede Komponente besitzt.
Erstellen Sie ein Abhängigkeitsverzeichnis mit Plugin-Name, Version, Zweck, Aktivstatus, betroffenen Entitäten, Datenbankerweiterungen, modifizierten oder überschriebenen Dateien, externen Systemen und der Person, die bestätigen kann, ob das Verhalten weiterhin benötigt wird. Verwenden Sie „Zen-Cart-Plugin“ oder den konkreten Komponentenamen, damit Plattform-Erweiterungen nicht mit Add-ons des Migrationsservice verwechselt werden.
| Auswirkung der Abhängigkeit | Vorzubereitender Nachweis | Bereitschaftskriterium |
|---|---|---|
| Attribute- oder Variant-Stock-Erweiterung | Kombinationsdatensätze, Product-Schlüssel, SKU- und Quantity-Felder | Jede aktive Kombination besitzt einen definierten verantwortliche Person in der Quelle. |
| Order-Total- oder Checkout-Modul | Konfigurationsübersicht und repräsentative historische Orders | Historische Werte lassen sich von aktueller Shop-Konfiguration trennen. |
| SEO- oder URL-Plugin | Rewrite-Einstellungen, Route-Beispiele und Redirect-Tabellen | Wichtige Quellpfade können rekonstruiert werden. |
| Customer- oder Loyalty-Erweiterung | Felder, Salden, Transaktionshistorie und Customer-Schlüssel | Aktive Kontodaten besitzt eine explizite Zielentscheidung. |
| ERP-, Marketplace- oder Auftragsabwicklung-Integration | External IDs, Synchronisationsrichtung und Authority | Weiterverwendete Systeme können dasselbe Product, denselben Customer oder dieselbe Order identifizieren. |
| Template-abhängiger Inhalt | Template-Pfade, Screenshots und Inhaltsquelle | Geschäftsinhalte sind vom Darstellungscode getrennt. |
EZ-Pages, Define Pages, Media und URL-Nachweise vorbereiten
Zen-Cart-Inhalte können über EZ-Pages, Define Pages, Product- und Category-Beschreibungen, Banner, Sideboxes, Template-Dateien und Sprachdateien erscheinen. Erstellen Sie ein Inventar mit verantwortliche Person für Inhalte, Sprache, aktueller Route, Menü- oder Sidebox-Platzierung, eingebetteten Links, Bildern und gewünschtem Zielzustand.
Dokumentieren Sie priorisierte Product-, Category-, Manufacturer-, EZ-Page-, Policy-, Contact- und Informations-URLs. Native Product- und Category-Pfade können IDs und Category Paths verwenden, während SEO-Plugins sie durch umgeschriebene Routes ersetzen. Das Route-Inventar sollte deshalb angeben, ob jeder wichtige Pfad native, plugin-generated, static oder externally redirected ist.
Sichern Sie Originalbilder und Download-Dateien mit ihren Pfaden. Die Datenbank kann Dateinamen enthalten, ohne die Dateien selbst zu enthalten. Markieren Sie fehlende Dateien, externe Bild-URLs, Unterschiede in Groß-/Kleinschreibung und generierte Thumbnails, die keine Originaldateien der Quelle sind.
Ein wiederherstellbares Zen-Cart-Quellpaket erstellen
Bewahren Sie einen wiederherstellbaren Zen-Cart-Quellzustand, bevor strukturelle Bereinigung oder Migrationsausführung beginnt. Das Paket sollte Datenbank, relevanten Dateibaum, Download-Verzeichnis, Konfigurationsreferenzen, Template- und Plugin-Evidenz sowie einen Umgebungsnotiz enthalten, der auf denselben Shop-Zustand verweist.
| Paketbestandteil | Verantwortlich | Nachweis | Bereitschaftskriterium |
|---|---|---|---|
| Datenbank-Backup | Database Administrator | Timestamped Dump und Hinweis zum Datenbankpräfix | Dump ist vollständig und gehört zum vorgesehenen Shop. |
| Dateien und Downloads | Verantwortliche für Hosting oder Technik | Dateiarchiv oder zugängliche Quelldateistruktur | Originalbilder, Downloads, Templates, Overrides und Plugins sind verfügbar. |
| Umgebungsprotokoll | Technisch verantwortliche Person | Hinweis zu PHP, Datenbank, Server und Zen-Cart-Version | Versionsabhängiges Verhalten kann interpretiert werden. |
| Zugriffsverzeichnis | Projektverantwortliche Person | Verantwortliche für Zugriff und Verbindungsstatus | Erforderlicher Zugriff ist verfügbar, ohne Credentials in Dokumentation offenzulegen. |
| Änderungsprotokoll | Shop-Administrator | Änderungen nach dem Stichtag der Nachweiserfassung | Späte strukturelle Änderungen können bewusst eingearbeitet werden. |
Repräsentative Migrationstest-Stichproben auswählen
Bereiten Sie ein kompaktes Stichprobenmanifest mit Quell-IDs, geschäftlicher Zweck, verknüpften Dateien und erwarteten Quellbeziehungen vor. Es sollte gewöhnliche Datensätze ebenso enthalten wie Beziehungen, die besonders leicht missverstanden werden. Das Zen-Cart-Stichprobenmanifest ist bereit, wenn jede Erwartung an die Quelle, Plugin- oder Attributabhängigkeit, verknüpfte Datei und jeder Identifikator vollständig ist und einem Prüfer zugeordnet wurde.
Nehmen Sie mindestens auf:
- ein einfaches Product, ein inaktives Product und ein verknüpftes Multi-Category-Product;
- ein attributreiches Product mit Preis- oder Gewichtseffekten;
- Text- oder Dateieingaben, Variant Bestand oder abhängige Attribute, sofern vorhanden;
- ein Download-Product mit Quelldatei und Kaufhistorie;
- Products mit Specials, Quantity Pricing oder Customer-Group Pricing;
- Customers aus relevanten Pricing- oder Authorization-Gruppen;
- Orders mit Attributen, Kommentaren, unterschiedlichen Adressen, Gift Certificates, ungewöhnlichen Totals und Downloads;
- priorisierte native und rewritten URLs;
- einen aktiven plugin-basierten Record und ein Beispiel für template-abhängigen Content.
Abschließendes Bereitschaftskriterium für Zen Cart anwenden
Zen Cart ist für den nächsten Migrationsschritt bereit, wenn die Quelle ohne undokumentierte Annahmen erklärt werden kann.
| Frage zur Bereitschaft | Erforderliches Ergebnis |
|---|---|
| Ist die exakte Installation bekannt? | Version, Hosting, Datenbank, Sprachen, Template, Overrides und Plugins sind dokumentiert. |
| Sind Product-Beziehungen vollständig? | Attribute, Downloads, Categories, Pricing, Media und Bestand Extensions sind abgebildet. |
| Sind Customers und Orders interpretierbar? | Gruppen, Adressen, Status, Totals, Kommentare und externe IDs haben klar benannte Verantwortliche. |
| Sind Plugins und benutzerdefinierte Daten klassifiziert? | Jede aktive Abhängigkeit besitzt Geschäftszweck und Zielentscheidung. |
| Sind Inhalte und Routen inventarisiert? | EZ-Pages, Define Pages, Media und wichtige native oder rewritten URLs sind dokumentiert. |
| Sind Backups und Zugriff bereit? | Quellpaket ist wiederherstellbar und erforderlicher Zugriff verfügbar. |
| Ist die Stichprobe Set repräsentativ? | Gewöhnliche und komplexe Datensätze sind mit Quell-IDs und erwarteten Beziehungen gelistet. |
Ungeklärte Punkte gehören in ein Entscheidungsprotokoll mit verantwortlicher Person und Fälligkeitsdatum. Die Vorbereitung ist unvollständig, solange eine kritische Plugin-Tabelle, Download-Datei, Category-Verknüpfung, Preisbeziehung oder externe Kennung nur als unbekannt beschrieben wird.
Fazit
Die Vorbereitung auf Zen Cart ist am stärksten, wenn der Shop als verbundener Katalog und historische Datenbasis statt als flacher Product Export verstanden wird. Attribute, Downloads, verknüpfte Categories, Customer Pricing Groups, Order Totals, EZ-Pages, Plugins, Overrides, Templates und Originaldateien benötigen jeweils klare Verantwortung und einen vollständiges Nachweispaket.
Ein wiederherstellbares Quellpaket, ein repräsentatives Stichprobenmanifest und ein explizites Bereitschaftskriterium schaffen die Grundlage für die Migrationskonfiguration.
Häufige Fragen
Warum müssen Zen-Cart-Attribute getrennt von Product Fields vorbereitet werden?
Attribute verbinden Option Names und Option Values mit Products und können Preis, Gewicht, Pflichtauswahl, Käufereingabe, Downloads oder Bestand beeinflussen. Eine flache Product-Zeile kann diese Beziehungen nicht zuverlässig erhalten.
Was ist der Unterschied zwischen einer Master Category und einer Linked Category?
Ein Product besitzt eine Master Category und kann mit weiteren Categories verknüpft werden. Beide Beziehungen sollten dokumentiert werden, damit zusätzliche Platzierung nicht mit einem Product-Duplikat verwechselt oder bei der Katalogvorbereitung verloren wird.
Enthält ein Zen-Cart-Datenbank-Backup Bilder und Download-Dateien?
Nein. Die Datenbank speichert normalerweise nur Referenzen. Originalbilder, Downloads, Templates, Overrides und Plugin-Dateien müssen zusätzlich aus dem Dateisystem vorbereitet werden.
Wie sollten Zen-Cart-Plugin-Daten dokumentiert werden?
Dokumentieren Sie Plugin, Version, betroffene Entitäten, Fields oder Tables, repräsentative Quell-IDs, externe Abhängigkeiten und den weiterbestehenden Geschäftszweck. Aktive Daten brauchen explizite Verantwortung; veraltete Records können für Archive oder Exclusion markiert werden.
Welche Orders gehören in das Stichprobensatz der Quelle?
Nehmen Sie gewöhnliche Orders ebenso auf wie Orders mit Attributen, Rabatten, Gift Certificates, unterschiedlichen Billing- und Shipping-Adressen, Kommentaren, ungewöhnlichen Totals, Downloads und externen Referenzen. Diese zeigen Beziehungen, die einfache Orders nicht sichtbar machen.
Sollten rewritten Zen-Cart-URLs als native Product URLs behandelt werden?
Nicht automatisch. Dokumentieren Sie, ob jeder wichtige Route native, durch ein SEO-Plugin erzeugt, static oder extern redirected ist. Diese Verantwortung bestimmt, welche Evidenz zur Reproduktion der Pfadbeziehung benötigt wird.