Wenn EasyStore by JoomShaper als mögliche Zielplattform bewertet wird, muss zuerst verstanden werden, wie sein Datenmodell Bedeutung verteilt: EasyStore verbindet eine eigene Commerce-Komponente mit Joomla-Identität, Zugriff, Routing, Modulen und Page-Building-Ebenen. Products, Varianten, Categories, Tags, Marken, Collections, Customers, Orders, Coupons, Bewertungen und andere kommerzielle Datensätze gehören zu EasyStore, während Joomla und SP Page Builder bestimmen können, wie diese Datensätze erreicht und dargestellt werden.
Wird EasyStore als mögliche Zielplattform betrachtet, lautet die zentrale Frage des Datenmodells nicht, ob ein Quelldatensatz in ein ähnlich benanntes Feld kopiert werden kann. Entscheidend ist, welches EasyStore-Objekt die Bedeutung besitzen soll und welche Joomla- oder Darstellungsbeziehung getrennt erhalten werden muss. Ein Quellkatalog kann Products, Optionen, Spezifikationen, Collections, Navigation, Landingpages, Käuferidentitäten und Transaktionshistorie in einem Modell bündeln; EasyStore verteilt diese Zuständigkeiten auf Commerce- und Website-Aufbauobjekte.
EasyStore verwendet getrennte Commerce- und Joomla-Zuständigkeitsebenen
EasyStore speichert das Kernmodell des Verkaufs, während Joomla das umgebende Website-Framework bereitstellt. SP Page Builder kann anschließend EasyStore-Daten konsumieren und Shop-Ausgabe anordnen, ohne zum führenden System für Product-Bestand, Customer-Identität oder Order-Historie zu werden.
| Ebene | Typische Datensätze | Auswirkung auf die Übertragung |
|---|---|---|
| EasyStore Commerce | Products, Varianten, Preise, Bestand, Categories, Tags, Marken, Collections, Customers, Orders, Coupons, Bewertungen | Diese Datensätze bilden den kommerziellen Datengraphen und sollten ihre internen Beziehungen behalten. |
| Joomla Core | Benutzer, Zugriffsebenen, Menüs, Module, Sprachen, Medien, Aliase | Diese Datensätze können Identität, Erreichbarkeit, Sichtbarkeit und Website-Kontext steuern, ohne EasyStore-Entitäten zu ersetzen. |
| SP Page Builder | Seitenlayouts und EasyStore-Content-Blöcke | Die Darstellung referenziert EasyStore-Datensätze, wird aber nicht zum führenden Product- oder Order-System. |
| Zahlungs- und Versandintegrationen | Gateway-, Carrier- und Transaktionsreferenzen | Historische Referenzen gehören zu Orders; zukünftiges Betriebsverhalten gehört zur Zielintegration. |
| Individuelle Erweiterungen und Integrationen | Zusatzfelder, Webhooks, externe IDs, spezialisierte Abläufe | Zuständigkeit muss geklärt werden, bevor Werte Zielobjekten zugeordnet werden. |
Diese Trennung verhindert zwei typische Fehler: Joomla-Content wird nicht fälschlich als Commerce-Daten behandelt, und visuelle Page-Builder-Ausgabe wird nicht mit dem autoritativen Product-Modell verwechselt.
Products, Variationen und Varianten benötigen eine Übersetzung auf Beziehungsebene
Ein EasyStore-Product kann Titel, Alias, Beschreibung, Medien, Preise, Steuerbehandlung, Versandmaße, Kennungen, Bestandsverhalten, Category, Tags, Zugriff und SEO-Werte enthalten. Sobald Variationen hinzugefügt werden, entsteht kommerzielle Bedeutung auf Variantenebene. Preise und Bestand können vom Parent-Product-Kontext in den Bereich Product Variants wechseln, in dem jede Kombination eigenen Preis, Rabatt, Gewicht, SKU, standardisierte Kennung, Menge, Verfügbarkeit und Sichtbarkeit tragen kann.
Eine Quellplattform kann dieselbe Ware als separate Products, als ein Product mit Optionen, als Matrix von Variantenkombinationen, als konfigurierbare Child Records oder als individuelle Felder darstellen. Das Zielmodell muss entscheiden, welche Quelldatensätze zum EasyStore-Parent werden und welche zu Varianten.
| Muster im Quellkatalog | Frage zur EasyStore-Darstellung | Gefährdete Bedeutung |
|---|---|---|
| Ein Product je Größe oder Farbe | Sollen die Datensätze unter einem Parent mit Varianten zusammengeführt werden? | URLs, Bewertungen, Medien, Bestand und externe IDs können falsch dupliziert oder zusammengeführt werden. |
| Parent Product mit Child-SKUs | Welche Child-Attribute definieren EasyStore-Variationswerte? | Verkaufbare Kombinationen können SKU-, Preis-, Bestands- oder Sichtbarkeitsidentität verlieren. |
| Freitextoption auf einer Order | Ist der Wert eine verkaufbare Variation oder historische Positionsmetadaten? | Käuferauswahlen können in eine Variantenstruktur gezwungen werden, die nicht zur Quelle passt. |
| Product-Spezifikationsfelder | Sollten Werte als EasyStore Additional Data statt als Variationen abgebildet werden? | Informationsattribute können fälschlich zu kaufbaren Auswahlmöglichkeiten werden. |
| Product-Bestand plus Optionsbestand | Welche Bestandsebene ist führend? | Das Ziel kann doppelt zählen oder nicht verfügbare Kombinationen anbieten. |
EasyStore-Variationen sind nicht nur Darstellungsbezeichnungen. Sobald ein Product Variationen besitzt, können daraus entstehende Varianten eigene kommerzielle Attribute tragen. Quellkennungen sollten deshalb an genau der verkaufbaren Ebene erhalten bleiben, die externe Systeme, Lagerprozesse und historische Orders erkennen.
Additional Data, Tags, Marken, Collections und Related Products erfüllen unterschiedliche Aufgaben
EasyStore bietet mehrere Strukturen zur Beschreibung und Gruppierung von Products. Additional Data kann strukturierte Spezifikationen tragen. Tags unterstützen Auffindbarkeit und flexible Klassifikation. Marken kennzeichnen Hersteller- oder Brand-Identität. Categories bilden die Hauptkataloghierarchie. Collections können Products für Merchandising kuratieren. Upsell- und Cross-Sell-Beziehungen verbinden Products miteinander.
Diese Strukturen dürfen nicht zu einer generischen Taxonomie abgeflacht werden.
| EasyStore-Struktur | Primäre Rolle | Mögliche Quelldaten |
|---|---|---|
| Category | Hauptkatalogorganisation und Product-Zuordnung | Quell-Categories oder Departments mit dauerhafter Navigationsbedeutung |
| Tag | Flexible Auffindbarkeitskennzeichnung | Keywords, Themen, Use Cases oder nicht hierarchische Klassifikationen |
| Marke | Product-Brand oder Herstelleridentität | Brand-, Vendor- oder Herstellerdatensätze, sofern die Bedeutung übereinstimmt |
| Collection | Kuratierte Product-Gruppe | Kampagnengruppen, saisonale Sortimente, Featured Ranges oder redaktionelle Collections |
| Additional Data | Informative Product-Spezifikationen | Technische Attribute, Materialien, Maße, Kompatibilität oder beschreibende Fakten |
| Upsell-/Cross-Sell-Beziehung | Merchandising-Verknüpfung zwischen Products | Verwandte, ergänzende, ersetzende oder höherwertige Product-Referenzen |
Eine Quell-„Collection“ kann eine Category, regelbasierte Gruppe, Landingpage oder Kampagne sein. Die Zieldarstellung muss ihrem geschäftlichen Zweck folgen, nicht ihrer Bezeichnung. Dasselbe gilt für Attribute: Eine vom Käufer wählbare Größe gehört in die Variationsstruktur, eine nicht wählbare technische Spezifikation in Additional Data oder eine andere beschreibende Struktur.
EasyStore-Categories sind weder Joomla-Menüs noch Page-Builder-Layouts
EasyStore-Categories organisieren Products innerhalb des Commerce-Modells. Joomla Menu Items machen Seiten erreichbar und können Alias, Routenpfad, Zugriff, Sprache und Template-Kontext definieren. SP-Page-Builder-Layouts ordnen Komponenten und EasyStore-Blöcke auf Seiten an. Eine einzige Shop-Landingpage kann von allen drei Ebenen abhängen.
| Shop-Konzept | EasyStore-Zuständigkeit | Joomla- oder Darstellungsbeziehung |
|---|---|---|
| Product-Listenhierarchie | EasyStore-Category-Baum | Ein Menu Item kann eine Category-Route oder kuratierte Seite freigeben. |
| Product-URL | EasyStore-Product-Alias und Component Routing | Joomla-Menükontext kann die öffentliche Route beeinflussen. |
| Kampagnen-Landingpage | EasyStore-Products oder Collection-Referenzen | SP-Page-Builder-Layout kann Kampagnen-Content anordnen. |
| Navigationsbezeichnung | Joomla Menu Item | Kann auf Category, Collection, Product oder individuelle Seite zeigen. |
| Product-Block | EasyStore-Datenquelle | SP-Page-Builder-Block steuert Position und Darstellung. |
Diese Trennung ist besonders wichtig, wenn die Quellplattform Navigation und Kataloggruppierung in demselben Objekt speichert. Nur den Category-Baum nachzubauen erzeugt nicht automatisch die öffentliche Navigation; nur Layouts zu kopieren kann Products von ihren autoritativen Category- und Collection-Beziehungen trennen.
Customers und Joomla-Benutzer können verbunden sein, ohne derselbe Datensatz zu sein
EasyStore kann Customer-Datensätze pflegen und vorhandene Joomla-Benutzer in Customers umwandeln. Dadurch sind beide Konzepte verbunden, aber nicht identisch. Joomla besitzt Login-Identität, Kontostatus, Benutzergruppen und Zugriff. EasyStore besitzt das Käuferprofil und die Commerce-Beziehungen, die für den Shop benötigt werden.
Eine Quellplattform kann registrierte Customers, Gastkäufer, Administratoren ohne Kaufhistorie und Customers enthalten, deren Transaktionshistorie eine andere E-Mail-Adresse als das aktuelle Konto verwendet. Diese Muster dürfen nicht ohne Erhalt der historischen Bedeutung zu einer einzigen Account-Form normalisiert werden.
| Quell-Identitätsmuster | Entscheidung zur EasyStore-Beziehung |
|---|---|
| Registrierter Käufer mit Joomla-äquivalentem Login | EasyStore-Customer mit dem richtigen Joomla-Benutzer verknüpfen, soweit das Zielmodell diese Identität unterstützt. |
| Gastkäufer | Käufer- und Adressdetails mit historischen Orders erhalten, ohne ein dauerhaftes Konto zu erfinden. |
| Mehrere Quellkonten mit derselben E-Mail | Entscheiden, ob Identitäten getrennt bleiben, zusammengeführt werden oder einen externen Schlüssel benötigen. |
| Mitarbeiter- oder Administratorkonto | Berechtigungsidentität von Customer-Status trennen, sofern die Person nicht zugleich Käufer ist. |
| B2B-Kontakt mit Organisationsbezug | Organisation, Kontakt, Preis- und Berechtigungsbedeutung nicht auf einen einfachen Customer-Datensatz reduzieren. |
Auch Joomla-Benutzergruppen müssen von kommerziellen Segmenten getrennt bleiben. Eine Gruppe für Administratorrechte oder eingeschränkten Content ist nicht automatisch gleichbedeutend mit Customer-Gruppe, Rabattzielgruppe oder Großhandelsstufe.
Orders bewahren kommerzielle Snapshots statt Live-Konfiguration
Eine EasyStore-Order repräsentiert eine historische Transaktion. Ihre nützliche Bedeutung kann Customer- oder Gastidentität, Adressen, Product- und Variantenauswahl, Mengen, Preise, Rabatte, Steuern, Versand, Zahlungsreferenzen, Status, Erstattungen oder Stornierungen, Notizen und Zeitstempel umfassen. Diese Werte sind Snapshots dessen, was zum Kaufzeitpunkt geschah.
Historische Order-Daten dürfen nicht als Ersatz für aktuelle Product-, Steuer-, Versand-, Zahlungs- oder Checkout-Konfiguration verwendet werden. Eine Versandbezeichnung auf einer alten Order hält die damals verwendete Methode fest, definiert aber nicht die Carrier-Konfiguration im Ziel. Eine Zahlungsreferenz erhält Transaktionskontext, konfiguriert jedoch kein Gateway.
| Order-Beziehung | Zu erhaltende historische Bedeutung |
|---|---|
| Product- oder Variantenreferenz | Welcher verkaufbare Artikel gekauft wurde, einschließlich Quellkennung, wo erforderlich |
| Positionsbeschreibung und gewählte Werte | Käuferseitige Product- und Auswahlbedeutung zum Kaufzeitpunkt |
| Customer- oder Gastbeziehung | Wer die Order aufgegeben hat und welche Adressen verwendet wurden |
| Preis, Rabatt, Steuer und Summe | Kommerzieller Snapshot, keine Neuberechnung nach aktuellen Regeln |
| Versand- und Zahlungsreferenz | Methode und Transaktionskontext der jeweiligen Order |
| Status und Zeitleiste | Lebenszyklusnachweis für Support und Auswertung |
| Erstattungs- oder Stornierungsinformationen | Historische Veränderung der ursprünglichen Transaktion |
Speichert die Quellplattform Order-Positionen unabhängig von aktuellen Products, sollten diese Snapshots lesbar bleiben, selbst wenn sich der aktuelle Katalog geändert hat, eine SKU eingestellt oder eine Variante neu organisiert wurde.
Coupons, Bewertungen und andere Beziehungen benötigen eigene Zuständigkeiten
Coupons und Bewertungen hängen mit Katalog und Customers zusammen, sind aber keine Product-Felder. Ein Coupon kann Berechtigung, Rabatttyp, Zeitraum, Nutzung sowie Product-, Category- oder Customer-Beziehungen enthalten. Eine Bewertung kann Customer- oder Gastidentität mit Product, Rating, Text, Status und Zeitstempel verbinden.
Werden diese Datensätze wie dekorativer Content behandelt, geht ihre Beziehungsbedeutung verloren. Eine Bewertung ohne korrekte Product-Verknüpfung wird verwaist. Ein Coupon, der nur als Code kopiert wird, kann eine andere Geschäftsregel repräsentieren. Wishlist-, Analytics- oder Abandoned-Cart-Datensätze können zu anderen EasyStore-Bereichen oder externen Services gehören und dürfen nicht aus Customer- oder Order-Core-Daten abgeleitet werden.
SP-Page-Builder-Integration repräsentiert Darstellungsreferenzen
EasyStore kann Products und Commerce-Elemente für SP-Page-Builder-Layouts bereitstellen. Page-Builder-Blöcke können Product-Listen, Suche, Categories, Filter, Preise, Bewertungen, Titel, Warenkorb-Steuerungen, Wunschlisten, Review-Content und weitere Shop-Elemente darstellen. Diese Blöcke referenzieren Commerce-Daten; sie besitzen weder Product-Bestand noch Order-Historie.
Ein visueller Builder im Quellsystem kann Katalogreferenzen direkt in Page-JSON oder Layoutdatensätzen einbetten. Das Zielmodell muss wiederverwendbaren redaktionellen Content, statische Layoutkonfiguration und dynamische EasyStore-Referenzen trennen.
| Page-Builder-Element | Dateninterpretation |
|---|---|
| Product-Listenblock | Darstellungsabfrage oder Referenz auf EasyStore-Products |
| Category-Block | Darstellungsbeziehung zu einer EasyStore-Category |
| Preis-, Rating-, Titel- oder Thumbnail-Block | Gerenderte Felder aus dem Product-Kontext |
| Warenkorb- oder Wishlist-Steuerung | Interaktives Shop-Element, keine historischen Warenkorbdaten |
| Statischer Text- oder Bildblock | Seiten-Content, der eine eigenständige Content-Migration benötigen kann |
| Individueller Layout-Override | Darstellungsimplementierung statt Standard-Commerce-Entität |
Diese Trennung lässt Products und Categories autoritativ bleiben, während Seitenlayouts entsprechend dem Darstellungsmodell der Zielplattform neu aufgebaut oder übertragen werden.
Einstellungen, Integrationen und Custom Data nach Zuständigkeit klassifizieren
EasyStore-Einstellungen können Steuern, Checkout-Verhalten, Zahlungen, Versand, E-Mail-Benachrichtigungen, Bestandsverhalten und Darstellungsregeln definieren. Sie beeinflussen den Live-Betrieb, sind aber nicht mit Products, Customers oder Orders gleichzusetzen. Historische Datensätze können ihre Ergebnisse referenzieren, ohne die zukünftige Konfiguration selbst zu tragen.
Individuelle Versanddienstleister, Payment-Integrationen, Entwicklererweiterungen, individuelle Datenbankfelder, Webhooks und externe Systemkennungen können weitere Zuständigkeitsebenen hinzufügen. Das Zielmodell muss bestimmen, ob jeder Wert ein EasyStore-Core-Datensatz, eine Joomla-Identität oder Route, eine SP-Page-Builder-Referenz, ein Integrationsdatensatz oder ein externer Systemschlüssel ist.
| Custom-Data-Signal | Anforderung an die Übertragung |
|---|---|
| ERP- oder Lager-ID auf Variantenebene | Auf der richtigen verkaufbaren Variante erhalten, nicht nur am Parent Product. |
| Individuelles Customer-Feld | Bestimmen, ob der Wert zu EasyStore, Joomla-Benutzerdaten oder einem externen Profil gehört. |
| Gateway-Transaktionsreferenz | Mit historischer Order und Zahlungskontext erhalten. |
| Carrier-spezifische Versandkennung | Mit der Order- oder Fulfillment-Beziehung erhalten, die sie verwendet. |
| Individuelle Page-Builder-Datenquelle | Referenzierte EasyStore-Entität und separate Darstellungskonfiguration identifizieren. |
| Tabelle einer Erweiterung | Parent-Entität, Geschäftszweck und Zielverantwortung vor der Übertragung definieren. |
Ein sauberes EasyStore-Migrationsmodell ist damit eine Zuständigkeitskarte: Commerce-Entitäten bleiben in EasyStore, Login und Zugriff in Joomla, visuelle Komposition im SP Page Builder oder der Zieldarstellungsebene und externe Kennungen an den Datensätzen, die verbundene Systeme erkennen.
Fazit
Eine EasyStore-Datenmigration erfordert mehr als das Erstellen von Products und Customers. Products können kommerzielle Datensätze auf Variantenebene enthalten; Categories, Tags, Marken, Collections und Spezifikationen erfüllen unterschiedliche Auffindbarkeit-Zwecke; Joomla-Benutzer und EasyStore-Customers können verknüpft sein, ohne dieselbe Entität zu bilden; Orders bewahren historische Snapshots; und SP-Page-Builder-Layouts referenzieren Commerce-Daten, besitzen sie aber nicht.
Wenn diese Grenzen explizit bleiben, entsteht ein Zielmodell, das Katalogverwaltung, Customer-Identität, historischen Service, Shop-Darstellung und Kontinuität verbundener Systeme unterstützt, ohne Joomla- und EasyStore-Ebenen zu einem mehrdeutigen Datensatzmodell abzuflachen.
Häufige Fragen
Sind EasyStore-Variationen nur Darstellungsoptionen?
Nein. Sobald Variationen erzeugt werden, können EasyStore-Varianten eigenen Preis, Rabatt, Steuerbehandlung, Versanddaten, SKU, standardisierte Kennungen, Bestand, Verfügbarkeit und Sichtbarkeit tragen. Sie sollten als verkaufbare Datensätze übertragen werden, wenn die Quelle äquivalente Kombinationen verwendet.
Sollten Product-Spezifikationen zu Variationen werden?
Nur wenn der Wert eine vom Käufer wählbare verkaufbare Kombination definiert. Informative Spezifikationen sind in Additional Data oder einer anderen beschreibenden Struktur besser aufgehoben, damit keine künstlichen Varianten entstehen.
Sind EasyStore-Categories dasselbe wie Joomla Menu Items?
Nein. EasyStore-Categories organisieren Products. Joomla Menu Items schaffen Navigations- und Routenkontext und können auf Category, Product, Collection oder Page-Builder-Seite zeigen.
Kann ein Joomla-Benutzer mit einem EasyStore-Customer verknüpft werden?
Ja. EasyStore unterstützt die Umwandlung eines Joomla-Benutzers in einen Customer, aber der Joomla-Benutzer bleibt die Login-Identität, während EasyStore das Commerce-Profil und dessen Customer-Beziehungen besitzt.
Konfigurieren migrierte Orders Zahlung, Versand oder Steuern?
Nein. Orders erhalten historischen Transaktionskontext. Zukünftiges Zahlungs-, Versand-, Steuer- und Checkout-Verhalten gehört zu EasyStore-Einstellungen und aktivierten Zielintegrationen.
Wie sollten SP-Page-Builder-Shop-Layouts behandelt werden?
Sie sollten in statischen Seiten-Content, Darstellungskonfiguration und Referenzen auf EasyStore-Entitäten getrennt werden. Product- und Order-Daten bleiben in EasyStore autoritativ, auch wenn Page Builder ihre Darstellung steuert.