Wenn J2Store als Zielplattform bewertet wird, muss sein Datenmodell als Joomla-integrierte Commerce-Struktur verstanden werden. J2Store integriert Commerce-Funktionen in Joomla, statt jeden kommerziellen Wert in einem eigenständigen Product-Objekt zu speichern. Joomla-Artikel können als Products dienen, während Joomla-Kategorien, Aliasse, Menüs, Benutzer, Zugriffsebenen, Medien, Module und Templates einen großen Teil des Inhalts- und Storefront-Kontexts bereitstellen. J2Store ergänzt anschließend Preis, SKU, Bestand, Produkttyp, Optionen, Customer-, Checkout- und Order-Beziehungen, durch die der Artikel verkaufbar wird.
J2Store ist heute ein eingestelltes Projekt mit archiviertem Repository; J2Commerce ist der aktive Nachfolger. Diese Lebenszyklusentwicklung löscht das Datenmodell bestehender J2Store-Shops jedoch nicht. Sie macht die Interpretation der Quelle umso wichtiger: Alte Datensätze, Apps, Plugins, Overrides und individuelle Tabellen müssen als Legacy-Geschäftsnachweise verstanden werden und dürfen nicht automatisch mit einer aktuellen Zielstruktur gleichgesetzt werden.
Die Beziehung zwischen Artikel und Product
Die prägende Beziehung in J2Store ist die Verbindung zwischen einem Joomla-Artikel und seinen Commerce-Daten. Der Artikel trägt die Inhaltsidentität, J2Store die Verkaufsidentität. Werden beide in einer Migration voneinander getrennt, können doppelte Products, verwaiste Commerce-Datensätze oder Artikelseiten entstehen, die nicht mehr als Products funktionieren.
| Geschäftsfunktion | Joomla-Ebene | J2Store-Ebene |
|---|---|---|
| Produkttitel und ausführlicher Inhalt | Artikeltitel, Inhalt, Metadaten, Sprache, Veröffentlichungsstatus | Commerce-Datensatz referenziert den verkaufbaren Artikel |
| Inhaltsgruppierung | Joomla-Kategorie, Tags, Menükontext | Produktlisten, Filter oder App-Logik können diese Gruppierung verwenden |
| Kommerzielle Identität | Begrenzte CMS-Zuständigkeit | Produkttyp, SKU, Preis, Steuer, Bestand, Gewicht, Abmessungen |
| Käuferauswahl | Darstellung über Artikel- oder Template-Ausgabe | Optionen, Varianten, benutzerdefinierte Felder oder app-eigene Datensätze |
| Käuferkonto | Joomla-Benutzer und Benutzergruppen | Customer, Adressen, Checkout-Felder und Orders |
| Storefront-URL | Alias, Kategorie, Menüeintrag, Router, Sprache | Produktstatus bestimmt, ob Kaufoptionen verfügbar sind |
Artikel-ID und J2Store-Product-Beziehung sollten während der Migration als eine logische Identität behandelt werden. Beide Tabellen zu behalten, aber ihre Verbindung zu verlieren, ist keine echte Bewahrung.
Produkttypen, Optionen und spezialisierte Commerce-Datensätze
J2Store-Installationen können einfache, variable, konfigurierbare, herunterladbare, virtuelle, abonnementbasierte, buchungsbezogene, teilzahlungsbasierte und weitere spezialisierte Verkaufsmodelle abbilden. Manche Modelle entstehen durch Core-Produkttypen, andere durch Apps oder Plugins. Die sichtbaren Bezeichnungen im Storefront zeigen nicht die vollständige zugrunde liegende Struktur.
Ein Quell-Product sollte vor der Übertragung in getrennte Bedeutungen zerlegt werden:
| Quellelement | Mögliche Zuständigkeit in J2Store | Zu klärende Übertragungsfrage |
|---|---|---|
| Name, Beschreibung, eingebettete Medien | Joomla-Artikel | Welche Inhalte gehören zur kanonischen Produktseite? |
| SKU, Preis, Bestand, Gewicht | J2Store-Product- oder Variantendatensatz | Gilt der Wert gemeinsam oder nur für eine bestimmte Auswahl? |
| Größe, Farbe, Material, Gravur | Option, Variante, Artikelinhalt oder App-Datensatz | Verändert die Auswahl SKU, Bestand, Preis, Auftragsabwicklung oder nur die Darstellung? |
| Digitale Datei | Herunterladbares Product oder App-Beziehung | Welcher Kauf- und Order-Status gewährt Zugriff? |
| Abonnementplan | App-eigene Product-, Plan-, Verlängerungs- und Zugriffsdaten | Welche wiederkehrenden und kontobezogenen Beziehungen müssen fortbestehen? |
| Buchungszeitfenster | App-eigene Zeitplan-, Ressourcen-, Kapazitäts- und Reservierungsdaten | Welcher Datensatz beschreibt die verkaufbare Leistung und welcher die konkrete Reservierung? |
| Anzahlung oder Rate | Zahlungsplan- und Saldodatensätze | Wie hängen ursprünglicher Gesamtbetrag, bezahlter Betrag, Restbetrag und Status zusammen? |
Eine Product-Option sollte nicht allein nach ihrem Namen übertragen werden. Ein Wert wie „Größe“ kann eine bestandsführende Variante, einen Preisaufschlag, eine beschreibende Abmessung oder einen Versandfaktor darstellen. Die Zielstruktur muss sich nach der geschäftlichen Funktion richten.
Spezialisierte Datensätze brauchen besondere Aufmerksamkeit, weil J2Store-Erweiterungen ihre Daten außerhalb gewöhnlicher Product- und Order-Tabellen speichern können. Ein Abonnement-Product ohne Plan- und Berechtigungsdatensätze wird zu einem normalen Einmalkauf. Ein Buchungs-Product ohne Reservierungsdaten bleibt lediglich eine Seite, die eine Dienstleistung beschreibt.
Kategorien, Menüs, Module und Routen
Die Katalogstruktur von J2Store stützt sich stark auf Joomla. Eine Kategorie aus der Quelle kann mehrere mögliche Bedeutungen im Ziel haben: Artikelklassifikation, Käufernavigation, dynamische Gruppierung, Filtereingabe, Zugriffsgrenze oder Landingpage-Kontext.
| Quellstruktur | Beziehung in J2Store/Joomla | Zu bewahrende Bedeutung |
|---|---|---|
| Produktkategorie | Joomla-Kategorie, der Product-Artikel zugeordnet sind | Klassifikation und kategoriebasierte Navigation |
| Collection oder Abteilung | Kategorie, Tag, Modulabfrage, Menüeintrag oder App-Regel | Gruppierungslogik und Auffindbarkeit |
| Marke oder Hersteller | Produktfeld, Tag, Kategorie, Inhaltsseite oder Erweiterung | Darstellung, Filter, Route und externe Identität |
| Hervorgehobene Products | Modulkonfiguration oder App-Abfrage | Auswahlregel statt einer statisch kopierten Liste |
| Eingeschränkter Katalog | Joomla-Zugriffsebene, Benutzergruppe oder Erweiterung | Welche Benutzer Products sehen oder kaufen dürfen |
| Kampagnen-Landingpage | Joomla-Artikel, Menüeintrag, Module und Product-Links | Inhaltskomposition und kanonische Route |
Der Joomla-Menükontext beeinflusst das Routing. Derselbe Artikel kann über verschiedene Menüpfade, Kategoriepfade oder Aliasse erreichbar sein. Die Migration sollte das bevorzugte Produktziel identifizieren und von alternativen Routen unterscheiden, die weitergeleitet oder stillgelegt werden sollen.
Module und Template-Overrides sind keine Product-Datensätze. Sie können bestimmen, welche Products erscheinen, welche Felder sichtbar sind und wie Optionen oder Preise dargestellt werden. Abhängigkeiten von migrierten Kennungen sollten dokumentiert werden, ihre Darstellungslogik bleibt jedoch eine separate Zielstruktur.
Customers, Joomla-Benutzer und Kontokontext
J2Store-Customer-Daten können über Joomla-Benutzer, Benutzergruppen, Customer-Datensätze, Adressen, Checkout-Felder und historische Orders verteilt sein. Eine Customer-E-Mail-Adresse reicht nicht aus, um die Kontobeziehung wiederherzustellen.
Ein registrierter Customer kann Folgendes besitzen:
- eine Joomla-Benutzer-ID und einen Login-Status;
- Mitgliedschaft in Joomla-Benutzergruppen;
- eine oder mehrere Rechnungs- und Lieferadressen;
- wiederverwendbare Profil- oder Steuerwerte;
- individuelle Registrierungs- oder Checkout-Felder;
- Orders, die mit Benutzer oder E-Mail verknüpft sind;
- app-eigene Mitgliedschafts-, Abonnement-, Bonus- oder Zugriffsdatensätze.
Eine Gast-Order kann dieselben Kontakt- und Adressfelder enthalten, ohne dass je ein dauerhaftes Joomla-Benutzerkonto existiert hat. Für jeden historischen Gast nachträglich ein registriertes Konto anzulegen, kann die Identitätssemantik verändern und doppelte oder unzugängliche Konten erzeugen.
| Customer-Wert | Passende Zuständigkeit | Grund |
|---|---|---|
| Loginname, E-Mail, Aktivierungsstatus | Joomla-Benutzer | Steuert die dauerhafte Authentifizierungsidentität |
| Benutzergruppenrolle | Joomla-Benutzergruppenbeziehung | Kann Zugriff, Preise oder Erweiterungsfunktionen steuern |
| Wiederverwendbare Adresse | J2Store-Customer-/Adressdatensatz | Gehört zum Customer-Lebenszyklus |
| Rechnungs- und Lieferadresse eines Gasts | Historische Order | Gehört zu genau dieser Transaktion |
| Steuer-ID oder Firmendaten | Je nach Verwendung Customer-, Adress- oder Order-Feld | Zuständigkeit hängt davon ab, ob der Wert wiederverwendbar ist |
| Marketingeinwilligung oder Mitgliedschaftsstatus | Joomla-Profil, Erweiterung oder externes System | Benötigt ein klar benanntes nutzendes System |
Passwörter sollten als Identitätsthema und nicht als gewöhnliches Customer-Feld behandelt werden. Ob Anmeldedaten weiterhin verwendbar sind, hängt vom Authentifizierungsmodell von Quelle und Ziel sowie von der erhaltenen Joomla-Benutzerbeziehung ab.
Orders als historische Nachweise
J2Store-Orders bewahren mehr als eine Kopfsumme. Sie können Product- und Options-Snapshots, SKUs, Mengen, Einzelpreise, Rabatte, Coupons, Steuern, Versand, Zahlungsbezeichnungen, Adressen, individuelle Checkout-Werte, Notizen, Statusinformationen und Referenzen aus Erweiterungen enthalten.
Eine historische Order sollte verständlich bleiben, selbst wenn das ursprüngliche Product später verändert wird oder eine Erweiterung nicht mehr aktiv ist. Dafür müssen Snapshot-Werte an der Order erhalten bleiben, anstatt nur aus dem aktuellen Katalog rekonstruiert zu werden.
| Order-Beziehung | Bedeutung, die erhalten bleiben sollte |
|---|---|
| Order zu Customer oder Gast | Wer die Order aufgegeben hat und ob ein dauerhaftes Konto bestand |
| Order zu Position | Was gekauft wurde, einschließlich ausgewählter Optionen und aufgezeichnetem Namen/SKU |
| Position zu Preis und Rabatt | Wie die historische Zwischensumme zustande kam |
| Order zu Steuer und Versand | Welche Beträge und Bezeichnungen die Gesamtsumme erklären |
| Order zu Zahlungsdatensatz | Historische Zahlungsart und Anbieterreferenz, sofern gespeichert |
| Order zu Statushistorie | Operative Interpretation der Transaktion im Zeitverlauf |
| Order zu App-Datensatz | Kontext zu Abonnement, Buchung, Dateizugriff, Ratenzahlung oder Auftragsabwicklung |
Historische Zahlungs- und Versandbezeichnungen stellen keine aktive Gateway- oder Carrier-Funktion wieder her. Sie gehören als Nachweise zum Order-Datensatz. Aktive Checkout-Konfiguration gehört in die Zielumgebung.
Beziehungen zwischen Inhalt, Sprache, Medien und SEO
J2Store-Produktseiten übernehmen die Inhaltsmöglichkeiten von Joomla. Product-Artikel können formatierte Beschreibungen, eingebettete Medien, benutzerdefinierte Felder, Metadaten, Aliasse, Sprachzuweisungen, Zugriffseinstellungen und Content-Plugins enthalten. Ein Product-Export aus der Quelle zeigt möglicherweise nicht, welche Werte echter Produktinhalt und welche durch Template oder Erweiterung erzeugt sind.
Das Zielmodell sollte Medien nach ihrer Rolle klassifizieren:
- im Artikel eingebettetes Bild;
- primäres Product-Bild;
- Bild in einer Product-Galerie;
- optionsspezifisches Bild;
- herunterladbare Datei;
- Asset einer Landingpage oder eines Moduls.
Sprachbeziehungen gehen ebenfalls über übersetzten Text hinaus. Mehrsprachige Joomla-Sites können getrennte Artikel, Kategorien, Menüs, Module, Aliasse und Sprachzuordnungen verwenden. Der Übersetzungsverbund sollte über Inhalts- und Commerce-Ebene hinweg erhalten bleiben.
SEO-Kontinuität hängt von der Beziehung zwischen Artikelalias, Kategoriepfad, Menüeintrag, Routerverhalten, Metadaten und möglichen Canonical- oder Redirect-Erweiterungen ab. Eine Quell-URL sollte nicht automatisch zu einem Alias-Feld werden, wenn ihr Pfad durch Menü- oder Kategoriebeziehungen erzeugt wurde. Das Ziel braucht einen kanonischen Verantwortlichen und einen definierten Weiterleitungspfad für wertvolle Alternativrouten.
Apps, Plugins, individuelle Tabellen und externe Systeme
Ältere J2Store-Shops werden häufig stark durch Apps und Plugins geprägt. Erweiterungen für Abonnements, Buchungen, Teilzahlungen, Bonusprogramme, Product-Bundles, Uploads, Checkout-Felder, Zahlung, Versand, Steuern, Berichtswesen und Integrationen können Datensätze außerhalb des grundlegenden Product-Customer-Order-Modells erzeugen.
| Abhängigkeit | Verdeckte oder verteilte Datensätze | Anforderung an die Übertragung |
|---|---|---|
| Abonnement- oder Mitgliedschafts-App | Pläne, Abrechnungsreferenzen, Verlängerungen, Zugriffsstatus, Benutzergruppen | Beziehung zwischen Product, Customer, Plan und Berechtigung erhalten |
| Buchungs-App | Ressourcen, Termine, Kapazitäten, Reservierungen, Teilnehmer | Verkaufbares Product von der gebuchten Instanz unterscheiden |
| Teilzahlungs-App | Zahlungspläne, Raten, Salden, Transaktionsverknüpfungen | Finanzielle Beziehung kohärent halten |
| Individuelle Checkout-Felder | Customer-Werte, Adresswerte, Order-Metadaten, Eingaben auf Positionsebene | Jedes Feld seinem tatsächlichen Lebenszyklusverantwortlichen zuordnen |
| Zahlungs- oder Versand-Plugin | Konfiguration, Anbieterreferenzen, Methodenbezeichnungen, individuelle Statuswerte | Aktive Konfiguration von historischen Order-Nachweisen trennen |
| ERP-, CRM-, Buchhaltungs- oder Lagerintegration | Externe IDs, Synchronisationsstatus, Zuordnungstabellen | Dauerhafte Schlüssel erhalten und externen Verantwortlichen benennen |
| Template-Override oder Modul | Darstellungsregeln und Annahmen über Kennungen | Darstellung auf Basis der übertragenen Datensätze neu aufbauen |
Durch den archivierten Status von J2Store haben Legacy-Erweiterungen möglicherweise kein aktives Gegenstück mehr. Die Datenmodellfrage bleibt dennoch objektiv: Welche Datensätze tragen geschäftliche Bedeutung, und wo soll diese Bedeutung nach der Migration leben? Datensätze ohne Zielsystem sollten bewusst archiviert oder stillgelegt werden, statt als undurchsichtiger technischer Ballast kopiert zu werden.
Herkunft von Legacy-Datensätzen und Archivverantwortung
Bei J2Store-Migrationen werden häufig zwei Ziele benötigt: ein operatives Zielmodell und ein historisches Archiv. Nicht jede Legacy-Tabelle muss zu einem aktiven Objekt im Ziel werden, doch Datensätze, die Orders, Berechtigungen, Steuernachweise oder Historie externer Systeme erklären, können langfristig aufbewahrt werden müssen.
Die Entscheidung sollte sich nach geschäftlicher Herkunft und nicht nach dem Alter einer Tabelle richten. Eine alte Product-ID kann für die Storefront irrelevant sein, aber historische Order-Positionen mit Buchhaltungsexporten verbinden. Ein App-Datensatz steuert möglicherweise kein aktives Verhalten mehr, erklärt aber eine Mitgliedschaftsperiode oder einen offenen Ratenbetrag. Ein doppelter Alias muss vielleicht nicht als Live-Inhalt bestehen bleiben, benötigt aber weiterhin eine Weiterleitung.
| Legacy-Datensatz | Verwendung im operativen Ziel | Verwendung im Archiv |
|---|---|---|
| Product- und Artikelkennungen | Aktuell verkaufbares Element wieder mit Inhalt verbinden | Alte Order-Positionen oder externe Referenzen nachverfolgen |
| Archivierte Erweiterungskonfiguration | In der Regel durch aktuelle Konfiguration ersetzen | Erklären, wie historische Transaktionen erzeugt wurden |
| Abonnement-, Buchungs- oder Zahlungsinstanzen | Nur fortführen, wenn ein unterstützter Zielverantwortlicher vorhanden ist | Vertragliche oder Transaktionshistorie aufbewahren, sofern erforderlich |
| Veraltete benutzerdefinierte Felder | Nur behalten, wenn ein aktueller Ablauf sie verwendet | In dokumentiertem Export speichern, wenn historische Interpretation wichtig ist |
| Alte Routen und Aliasse | Wertvolle Ziele weiterleiten | Routenverzeichnis für Audit und Fehleranalyse aufbewahren |
Diese Trennung verhindert, dass das aktive Ziel zu einer Kopie einer aufgegebenen Implementierung wird, während Nachweise für Mitarbeitende, Customers oder externe Systeme erhalten bleiben. Das Archiv sollte durchsuchbar und mit stabilen Geschäftskennungen verknüpft sein, statt als undokumentierter Datenbankdump zurückzubleiben.
Wie die J2Store-Unterschiede den Migrationsumfang verändern
Der J2Store-Umfang sollte Datensatzübertragung, Wiederherstellung von Beziehungen und Behandlung von Legacy-Abhängigkeiten voneinander trennen.
| Behandlung | Beispiele | Auswirkung auf den Umfang |
|---|---|---|
| Direkte Datensatzübertragung | Standard-Products, Customers, Orders, Kategorien, Inhalte und Medien | Felder dem unterstützten Zielverantwortlichen zuordnen |
| Wiederherstellung von Beziehungen | Artikel zu Product, Benutzer zu Customer, Product zu Option, Order zu App-Datensatz | Verbindung mit stabilen Kennungen neu herstellen |
| Zielkonfiguration | Menüs, Module, Templates, Steuern, Zahlung, Versand, Zugriff und Spracheinstellungen | Der Zielimplementierung zuweisen |
| Übertragung von Legacy-Erweiterungsdaten | Abonnements, Buchungen, Teilzahlungen, individuelle Checkout-Felder, Berichtswesen | Aktuelles Ziel definieren oder als historisches Archiv bewahren |
| Kontinuität externer Systeme | ERP-, CRM-, Buchhaltungs-, Auftragsabwicklungs- und Marketplace-IDs | Dauerhafte Kennungen und Verantwortung für die Zuordnung erhalten |
| Bewusste Stilllegung | Aufgegebene Erweiterungen, doppelte Routen, veraltete Felder, ungenutzte Inhalte | Mit dokumentierter Geschäftsentscheidung ausschließen |
Ein kohärentes Migrationsmodell gibt jedem bewahrten Wert ein eindeutiges autoritatives Ziel. Es verwendet nicht die alte J2Store-Struktur als Zielentwurf, nur weil diese Tabellen in der Quelldatenbank vorhanden sind.
Fazit
Die Besonderheiten des J2Store-Datenmodells entstehen daraus, dass Commerce auf Joomla-Artikel, Benutzer, Kategorien, Menüs, Aliasse, Module und Templates aufgesetzt wird. Produktbedeutung verteilt sich auf Inhalts- und Commerce-Datensätze. Customer-Bedeutung kann sich über Joomla-Identität und J2Store-Adressen oder Orders erstrecken. Spezialisierte Verkaufsmodelle hängen häufig von app-eigenen Tabellen ab, und historische Orders müssen verständlich bleiben, selbst wenn die zugehörigen Apps nicht mehr aktiv sind.
Da J2Store heute eine Legacy-Plattform ist, sollte die Migration geschäftliche Bedeutung bewahren, ohne veraltete technische Strukturen zu reproduzieren. Das stärkste Zielmodell verbindet Artikel- und Product-Identität wieder, weist Customer- und Order-Werte dem richtigen Lebenszyklusverantwortlichen zu, überträgt Erweiterungsdaten ausdrücklich und legt Datensätze still, für die kein gültiger Verbraucher mehr existiert.
Häufige Fragen
Warum sind Joomla-Artikel zentral für das J2Store-Datenmodell?
J2Store verwendet Joomla-Artikel als Inhaltsgrundlage für Products. Artikelinhalt, Kategorie, Alias, Sprache, Zugriff und Veröffentlichungsstatus können daher untrennbar mit J2Store-Preis, SKU, Bestand, Optionen und Kaufdatensätzen verbunden sein.
Ist J2Store weiterhin die aktive Fortsetzung der Plattform?
Nein. Die J2Store-Entwicklung wurde eingestellt und das Repository archiviert. J2Commerce ist der aktive Nachfolger. Bestehende J2Store-Daten bleiben gültige Quellnachweise, sollten aber in die gewählte aktuelle Zielstruktur übertragen und nicht unverändert als weiterhin operativ vorausgesetzt werden.
Sind J2Store-Optionen auf jeder Plattform mit Varianten gleichzusetzen?
Nein. Eine Quellauswahl kann eine bestandsführende SKU, einen Preisaufschlag, ein Personalisierungsfeld, eine Spezifikation oder einen Erweiterungsdatensatz darstellen. Die Zielstruktur sollte sich daran orientieren, was die Auswahl im Product- und Order-Verhalten tatsächlich verändert.
Wie sollten Gast-Customers dargestellt werden?
Kontakt- und Adressdaten von Gästen sollten bei der historischen Order verbleiben, sofern nie ein echtes dauerhaftes Konto existierte. Künstlich erzeugte Joomla-Benutzer können Identität verzerren und doppelte Customer-Historien erzeugen.
Stellen historische Orders aktives Zahlungs-, Versand- oder Steuerverhalten wieder her?
Nein. Historische Orders bewahren aufgezeichnete Bezeichnungen, Beträge, Statuswerte und Referenzen. Aktives Checkout-Verhalten gehört zur Zahlungs-, Versand-, Steuer- und Währungskonfiguration der Zielumgebung.
Was sollte mit Daten einer aufgegebenen J2Store-Erweiterung geschehen?
Zunächst ist zu klären, ob die Datensätze weiterhin geschäftliche, rechtliche oder operative Bedeutung haben. Gibt es einen aktuellen Verantwortlichen, sollten sie dorthin übertragen werden. Andernfalls sollten sie bewusst archiviert oder stillgelegt werden, statt undurchsichtige Felder in unpassende Zielobjekte einzufügen.