Bei der Bewertung von VirtueMart als möglicher Zielplattform ist im Datenmodell zu klären, wie Quellstrukturen und Beziehungen im Ziel repräsentiert werden. VirtueMart speichert Commerce-Datensätze innerhalb einer Joomla-Umgebung, verwendet aber nicht dasselbe Artikel-als-Produkt-Modell wie J2Store oder J2Commerce. Produkte, Produktkategorien, Hersteller, Preise, Bestand, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Bestellungen, Versandmethoden und Zahlungsmethoden gehören zu VirtueMart. Joomla stellt die Benutzeridentität, Menüs, Module, Templates, das Sprach-Framework, Routing, Zugriffsregeln und die Erweiterungsumgebung rund um diese Datensätze bereit.
Diese Eigentumsgrenze macht Migration zu einer Aufgabe der Beziehungsübersetzung. Eine Quellvariante kann zu einem Child Product, einem Custom Field oder einer anderen strukturierten Beziehung werden. Ein Kundensegment kann zu einer Shopper-Gruppe werden, die Preise und Methodenverfügbarkeit beeinflusst. Ein Steuer- oder Rabattwert kann Nachweis in einer alten Bestellung oder aktive Berechnungsregel für zukünftige Warenkörbe sein. Das richtige Ziel hängt von der geschäftlichen Rolle der Quelldaten ab.
Eigentumsgrenzen zwischen Joomla und VirtueMart
Ein VirtueMart-Shop besteht aus zwei verbundenen Modellen. Die Commerce-Komponente besitzt Katalog- und Transaktionsdatensätze; Joomla besitzt einen großen Teil des Website- und Identitätskontexts, über den diese Datensätze dargestellt werden.
| Geschäftsbereich | Primärer Eigentümer in der Zielplattform | Zu erhaltende Beziehung |
|---|---|---|
| Produktidentität und Katalogfelder | VirtueMart | Produkt zu Kategorie, Hersteller, Medien, Preis, Bestand, Custom Fields und verwandten Produkten |
| Benutzeranmeldung | Joomla-Benutzer | Benutzer zu VirtueMart-Shopper- und Adressdatensätzen |
| Shopper-Segmentierung | VirtueMart-Shopper-Gruppe, teilweise kombiniert mit Joomla-Zugriff | Shopper zu Preis-, Sichtbarkeits-, Steuer-, Zahlungs- oder Versandlogik |
| Shop-Route | Joomla-Menü, Router, Alias, Sprache und VirtueMart-View | Produkt oder Kategorie zum bevorzugten Käuferziel |
| Produktdarstellung | VirtueMart-Layouts plus Joomla-Template und -Module | Datensatzkennungen zur richtigen Seitenausgabe |
| Zahlung und Versand | VirtueMart-Methoden und -Plugins | Aktive Methodenregeln zu Bestellnachweisen und Checkout-Verhalten |
Ein Produkt kann in VirtueMart vorhanden sein, obwohl seine Käuferroute, Modulplatzierung oder sein Sprachkontext fehlt. Ein Joomla-Benutzer kann existieren, während die zugehörige Shopper-Gruppe, Adresse oder Bestellhistorie getrennt ist. Beide Seiten jeder Beziehung benötigen einen eindeutigen Eigentümer.
Produkte, Kategorien, Hersteller und Medien
VirtueMart-Produkte können mit mehreren kommerziellen Strukturen verbunden sein. Ein Quellprodukt kann eine oder mehrere Kategorien, einen Hersteller, Bilder und Dateien, Bestandsfelder, Abmessungen, Verfügbarkeit, Preise, Steuern, Shopper-Gruppen, Custom Fields, Child Products, verwandte Produkte, Bewertungen und übersetzte Inhalte benötigen.
| Bedeutung in der Quelle | Zielfrage in VirtueMart | Erforderliche Beziehung |
|---|---|---|
| Produktklassifikation | Welche VirtueMart-Kategorien sollen das Produkt enthalten? | Produkt-zu-Kategorie-Zuordnungen und gewünschte Hierarchie |
| Markenidentität | Ist sie Herstellerdatensatz, Kategorie, Custom Field oder externer Schlüssel? | Produkt-zu-Hersteller-Beziehung und ggf. Beziehung zu einer Markenseite |
| Galerie und Dateien | Welche Medien sind Bilder, herunterladbare Dateien oder Inhaltsressourcen? | Medienrolle am Produkt, Reihenfolge und Sichtbarkeit |
| Verwandtes Produkt oder Zubehör | Handelt es sich um Merchandising, Kompatibilität, Ersatz oder Bundle-Logik? | Produkt-zu-Produkt-Beziehung mit definiertem Zweck |
| Bestand und Abmessungen | Gelten Werte auf Produktebene oder pro Child Product? | Verantwortung für Bestand und versandrelevante Werte |
| Bewertungen | Sind sie native VirtueMart-Datensätze, Joomla-Inhalte oder Erweiterungsdaten? | Beziehung zwischen Rezensent, Produkt, Bewertung, Text und Veröffentlichung |
Die Übersetzung von Kategorien darf nicht mit Joomla-Navigation verwechselt werden. VirtueMart-Kategorien organisieren den Commerce-Katalog; Joomla-Menüeinträge stellen ausgewählte Kategorie- oder Produktansichten bereit. Eine Quell-Kategoriehierarchie kann daher korrekt migriert werden, während die Zielnavigation dennoch eine andere Routenstruktur verwendet.
Auch Herstellerdatensätze benötigen semantische Prüfung. Eine Quellmarke kann nur als sichtbarer Text dienen oder Filter, eigene Seiten, Datenexporte, Preisregeln und externe Integrationsschlüssel steuern. Das Ziel sollte die weiterhin relevanten Funktionen erhalten, statt jedes Markenlabel automatisch in dasselbe Zielobjekt umzuwandeln.
Child Products, Custom Fields und Variantenbedeutung
VirtueMart-Custom-Fields können Produkte beschreiben, Shopper-Eingaben erfassen, verwandte Datensätze verknüpfen, Plugin-Verhalten auslösen oder an auswählbaren Produktstrukturen beteiligt sein. Child Products können eigene SKU, Preis, Bestand, Abmessungen, Bilder oder Verfügbarkeit besitzen. Weil beide Mechanismen im Shop als Auswahl erscheinen können, lassen sich Quell-„Varianten“ nicht einheitlich abbilden.
| Verhalten in der Quelle | Mögliche VirtueMart-Darstellung | Zu erhaltende Bedeutung |
|---|---|---|
| Größe oder Farbe hat eigene SKU und eigenen Bestand | Parent-Child-Produktbeziehung, häufig über ein auswählbares Feld dargestellt | Jede Auswahl verweist auf die richtige Bestands- und Bestellpositionsidentität |
| Auswahl ändert den Preis, teilt aber Bestand | Produkt-Custom-Field oder konfigurierte Preisbeziehung | Preisanpassung bleibt mit der gewählten Option verknüpft |
| Shopper gibt Text ein oder lädt Informationen hoch | Shopper-Input-Custom-Field oder Erweiterungsdatensatz | Eingabewert bleibt der richtigen Bestellposition zugeordnet |
| Technische Spezifikation | Beschreibendes Custom Field | Wert bleibt lesbar und, wo relevant, filterbar |
| Verwandtes Produkt oder Kategorie | Systemweite Custom-Field-Beziehung | Link verweist weiterhin auf den vorgesehenen Datensatz |
| Plugin-basierter Konfigurator | Plugin-eigenes Custom Field und Datentabellen | Konfigurationszustand erhält einen unterstützten Ziel-Eigentümer |
Die Abbildungsentscheidung sollte von fünf Fragen ausgehen: Ändert die Auswahl SKU, Bestand, Preis, Bild oder Auftragsabwicklung? Wenn keines davon verändert wird, ist der Wert möglicherweise beschreibend statt eine Variante. Wenn mehrere davon verändert werden, ist ein Child Product oder eine Plugin-eigene Struktur wahrscheinlicher als ein einfaches Textfeld.
Custom Fields sind wiederverwendbare Definitionen, die Produkten zugewiesen werden können. Definition, Typ, Reihenfolge, Sichtbarkeit, Plugin-Eigentum und produktspezifischer Wert sind getrennte Beziehungen. Nur den angezeigten Wert zu kopieren kann die Definition verlieren, durch die der Wert auswählbar oder funktional wird.
Shopper-Gruppen, Preise und Berechnungsregeln
VirtueMart-Shopper-Gruppen können Katalogsichtbarkeit, Produktpreise, Steuern, Zahlungsmethoden, Versandmethoden und weitere kommerzielle Regeln beeinflussen. Eine Kundengruppe im Quellshop entspricht daher nicht zwingend einem einzigen VirtueMart-Shopper-Gruppen-Label.
Auch Preise können kontextabhängig sein. Ein Produkt kann Preise besitzen, die Mengenbereichen, Shopper-Gruppen, Währungen oder weiteren Bedingungen zugeordnet sind. Berechnungsregeln können Steuern, Rabatte, Margen oder Preisänderungen anwenden und nach Produktkategorie, Hersteller, Shopper-Gruppe, Land, Bundesland/Region, Währung oder Datum eingeschränkt sein.
| Quellregel | VirtueMart-Beziehung | Konsequenz für die Übersetzung |
|---|---|---|
| Großhandelspreisliste | Shopper-Gruppe plus Produktpreis-Datensätze | Kundenmitgliedschaft und Preisberechtigung müssen verbunden bleiben |
| Steuerbefreite Käufer | Shopper-Gruppe, Adressstandort und Berechnungsregeln | Identität, Geografie und Regelbedingungen müssen zusammenpassen |
| Kategorierabatt | Produktkategorie plus Berechnungsregel | Regel hängt von Kategoriezugehörigkeit ab, nicht von einem kopierten Rabattfeld |
| Regionale Steuer | Länder-/Regionenkontext plus Berechnungsregel | Kunden- oder Bestelladresse liefert einen Teil der Regeleingabe |
| Zeitlich begrenzte Aktion | Berechnungsregel oder Gutschein mit Datumswerten | Gültigkeitszeitraum und Rechenoperation müssen explizit bleiben |
| Währungsspezifischer Preis | Preis-Währungs-Beziehung | Betrag, Währung und Darstellungskontext dürfen nicht vermischt werden |
Historische Bestellbeträge und aktive Berechnungslogik gehören zu unterschiedlichen Ebenen. Eine alte Bestellung sollte tatsächlich erfasste Steuer-, Rabatt-, Währungs- und Gesamtwerte erhalten. Sie muss nicht durch die aktuelle Berechnungsengine neu berechnet werden. Neues Checkout-Verhalten hängt dagegen von aktiven Zielregeln ab.
Shopper, Adressen, Felder und Bestellungen
VirtueMart verknüpft häufig einen Joomla-Benutzer mit Shopper-Datensatz, Shopper-Gruppen und Adressinformationen. Gastbestellungen können ohne wiederverwendbares Joomla-Konto existieren. Shopper-Felder können Registrierungs-, Rechnungs-, Versand-, Steuer-, Unternehmens- oder transaktionsbezogene Angaben erfassen.
Das Zielmodell sollte jedes Feld seinem Lebenszyklus entsprechend zuordnen:
- dauerhafte Anmeldeidentität gehört zum Joomla-Benutzer;
- wiederverwendbare Käufersegmentierung gehört zu Shopper-Gruppen-Beziehungen;
- wiederverwendbare Rechnungs- oder Versandinformationen gehören zu Shopper-/Adressdatensätzen;
- Gastdaten gehören zum Bestell-Snapshot;
- einmalige Lieferhinweise oder Kaufanweisungen gehören zur Bestellung;
- erweiterungseigene Mitgliedschafts- oder Einwilligungswerte gehören zum System, das sie verwendet.
Bestellungen sind historische Nachweise. Sie können Produkt-Snapshots, ausgewählte Custom Fields, Child-Product-Identität, Mengen, Preise, Steuern, Rabatte, Gutscheine, Shopper-Gruppen-Kontext, Adressen, Zahlungs- und Versandlabels, Status, Währung, Notizen und Rechnungen enthalten.
| Bestellnachweis | Warum die Beziehung wichtig ist |
|---|---|
| Produkt und Child Product | Identifiziert den exakten verkaufbaren Artikel statt nur das Parent Product |
| Custom-Field-Auswahl | Erklärt Konfiguration, Personalisierung oder Bedeutung einer Produktoption |
| Shopper- und Adress-Snapshot | Bewahrt, wer gekauft hat und wohin Rechnung bzw. Versand gingen |
| Preis, Steuer, Rabatt und Währung | Erklärt das historische finanzielle Ergebnis |
| Zahlungs- und Versandmethode | Liefert Kontext für Kundenbetreuung und Auftragsabwicklung |
| Status und Zeitstempel | Zeigt die operative Historie der Bestellung |
| Externe Referenz | Verbindet Buchhaltung, ERP, Carrier- oder Marktplatzdatensätze |
Zahlungs- und Versand-Plugins können zusätzliche Metadaten erzeugen. Historisches Label und Provider-Referenz können in die migrierte Bestellung gehören, während die aktuelle Plugin-Konfiguration zur Zielumgebung gehört.
Shop-Darstellung, Sprache, URLs und Joomla-Präsentation
VirtueMart-Produkt- und Kategoriedatensätze bestimmen nicht allein die Käuferoberfläche. Joomla-Menüs, Module, Template-Overrides, Aliasse, Sprachzuordnungen, Zugriffsebenen und Routing prägen den finalen Shop.
Eine Quell-URL kann auf Produktslugs, verschachtelten Kategorien, Sprachpräfixen, Menüaliasen oder einer SEO-Erweiterung beruhen. VirtueMart-Routen können sowohl von Commerce-Aliasen als auch vom Joomla-Menükontext abhängen. Die Migration sollte daher für jedes wichtige Produkt und jede wichtige Kategorie das kanonische Ziel bestimmen und Weiterleitungen mit diesem Ziel verknüpfen.
Mehrsprachige Daten können übersetzte Produkt- und Kategoriedatensätze, Herstellertexte, Custom-Field-Labels, Joomla-Menüs, Module und Metadaten umfassen. Eine Sprachbeziehung ist erst vollständig, wenn die übersetzten Commerce-Datensätze über den entsprechenden Joomla-Sprach- und Routenkontext erreichbar sind.
| Präsentationsschicht | Verantwortung im Datenmodell |
|---|---|
| VirtueMart-Produkt- und Kategorie-Aliasse | Commerce-seitige Identität, die von Routen verwendet wird |
| Joomla-Menüeintrag | Einstiegspunkt und Routenkontext für eine Ansicht |
| Modul | Abfrage und Platzierung zur Darstellung von Produkten oder Kategorien |
| Template-Override | Darstellungslogik, die bestimmte Felder oder Kennungen erwartet |
| Sprachzuordnung | Verbindung zwischen übersetzten Inhalten, Menüs und Commerce-Datensätzen |
| Metadaten und kanonisches Ziel | Suchmaschinenbezogene Verantwortung für die Seite |
Darstellungslogik sollte nicht in Produktfelder eingefügt werden, nur um eine Seite nachzubilden. Sie sollte in der Ziel-Präsentationsschicht von Joomla und VirtueMart verbleiben und die übersetzten Datensätze über stabile Beziehungen konsumieren.
Plugin-eigene, individuelle und externe Daten
VirtueMart-Shops verwenden häufig Zahlungs-, Versand-, Custom-Field-, Subscription-, Product-Builder-, Such-, Datenexport-, Rechnungs-, Marktplatz-, Buchhaltungs- und Fulfillment-Erweiterungen. Diese können Tabellen und Referenzen erzeugen, die nicht zum normalen Produkt-, Shopper- oder Bestellmodell gehören.
| Abhängigkeit | Daten außerhalb der Kerndatensätze | Zielfrage |
|---|---|---|
| Custom-Field-Plugin | Konfiguratorwerte, vom Käufer bereitgestellte Dateien, Child-Beziehungen, Preislogik | Gibt es ein entsprechendes Plugin oder einen strukturierten Zieldatensatz? |
| Subscription- oder Recurring-Erweiterung | Pläne, Zyklen, Verlängerungen, Gateway-Referenzen, Berechtigungen | Welches System besitzt den wiederkehrenden Zustand nach der Migration? |
| Product Builder oder Bundle-Erweiterung | Komponentenprodukte, Formeln, gespeicherte Konfigurationen | Kann das Ziel die Konfiguration abbilden, ohne sie zu verflachen? |
| Zahlungs- oder Versand-Plugin | Transaktions-IDs, Labels, Tracking, Methodenmetadaten | Welche Werte sind historischer Nachweis und welche aktive Konfiguration? |
| ERP- oder Buchhaltungsintegration | Produkt-, Kunden-, Steuer-, Rechnungs- und Bestellschlüssel | Welche Kennungen sind dauerhaft und extern maßgeblich? |
| Template- oder Modul-Override | Felderwartungen und Darstellungsregeln | Welche übersetzten Kennungen müssen für die Darstellung stabil bleiben? |
Individuelle Datenbankspalten sind nicht selbsterklärend. Ihre Namen können Speicherstruktur zeigen, aber nicht den geschäftlichen Zweck. Jeder erhaltene Wert benötigt einen benannten Verbraucher, Lebenszyklus und eine Zielbeziehung.
Wie VirtueMart-Unterschiede den Migrationsumfang verändern
Der VirtueMart-Umfang sollte als Behandlung von Beziehungen beschrieben werden:
| Behandlung | Typische VirtueMart-Beispiele | Konsequenz für den Umfang |
|---|---|---|
| Direkte Datensatzübersetzung | Produkte, Kategorien, Hersteller, Shopper, Bestellungen, Medien | Standardfelder und Kennungen abbilden |
| Rekonstruktion von Beziehungen | Parent-Child-Produkte, Custom-Field-Zuordnungen, Shopper-Gruppen, Preise, Bedingungen von Berechnungsregeln | Verknüpfungen und Regeleingaben neu aufbauen |
| Joomla-Präsentationsstruktur | Menüs, Module, Routen, Sprachkontext, Template-Overrides | Der Ziel-Website-Implementierung zuweisen |
| Plugin-eigene Daten | Konfiguratoren, Subscriptions, spezielle Checkout-Felder, Methodenmetadaten | Unterstütztes Ziel oder separates Archiv definieren |
| Kontinuität externer Systeme | ERP-, Buchhaltungs-, Fulfillment-, Datenexport- oder Marktplatzkennungen | Dauerhafte Schlüssel und Verantwortung erhalten |
| Bewusstes Ausmustern | Veraltete Plugins, ungenutzte Custom Fields, doppelte Routen, aufgegebene Regeln | Mit dokumentierter Begründung ausschließen |
Das Datenmodell ist schlüssig, wenn ein Produkt über Kategorien, Child Products, Custom Fields, Preise, Bestand, Shopper-Gruppen-Regeln, Bestellpositionen, Joomla-Routen und externe Kennungen nachvollzogen werden kann, ohne von undokumentierten technischen Annahmen abhängig zu sein.
Fazit
Die Unterschiede im VirtueMart-Datenmodell entstehen aus dem Zusammenspiel zwischen VirtueMart-Commerce-Datensätzen und Joomla-Website-Strukturen. Produkte können von Kategorien, Herstellern, Medien, Child Products, Custom Fields, Shopper-Gruppen, Preisen, Berechnungsregeln und Plugins abhängen. Kunden können sich über Joomla-Benutzer, Shopper-Datensätze, Adressen und Gruppen erstrecken. Bestellungen bewahren Snapshots, die auch dann verständlich bleiben müssen, wenn aktuelle Regeln und Plugins anders sind.
Eine belastbare Migration übersetzt diese Beziehungen explizit. Sie trennt historische Bestellnachweise von aktiver Berechnungs- und Checkout-Logik, hält Joomla-Routing von Produktdatensätzen getrennt und weist Plugin-eigenen oder externen Daten ein klares Ziel zu. So bleibt die kommerzielle Bedeutung erhalten, statt lediglich Datenbankzeilen zu reproduzieren.
Häufige Fragen
Warum können VirtueMart-Varianten nicht alle auf einen einzigen Optionstyp abgebildet werden?
Manche Auswahlen sind Child Products mit eigener SKU, eigenem Bestand, Preis, Bild oder eigenen Abmessungen. Andere sind Preisänderungen, beschreibende Custom Fields, Shopper-Eingaben oder Plugin-eigene Konfigurationen. Die geschäftliche Funktion bestimmt die Zielstruktur.
Was ist der Unterschied zwischen einer Custom-Field-Definition und einem Produktwert?
Die Definition legt Feldtyp, Verhalten, Sichtbarkeit und mögliche Plugin-Logik fest. Die Produktzuordnung liefert Wert oder Auswahl für ein einzelnes Produkt. Für das Verhalten im Shop können beide Beziehungen erforderlich sein.
Wie beeinflussen Shopper-Gruppen das Datenmodell?
Shopper-Gruppen können Preise, Sichtbarkeit, Steuern, Zahlungs- und Versandmethoden sowie weitere Regeln beeinflussen. Nur den Gruppennamen ohne Mitglieder und verwendende Regeln zu erhalten, bewahrt die geschäftliche Bedeutung nicht.
Sollten historische Bestellungen mit den Steuer- und Rabattregeln der Zielplattform neu berechnet werden?
Nein. Historische Bestellungen sollten die zum Kaufzeitpunkt erfassten Beträge und Labels bewahren. Aktive Zielregeln steuern neue Warenkörbe und müssen vom historischen Snapshot getrennt bleiben.
Warum sind Joomla-Menüs relevant, wenn Produkte in VirtueMart gespeichert werden?
Menüs können den Routenkontext und Einstiegspunkte der Shop-Darstellung festlegen. Produkt- und Kategorie-Aliasse können korrekt sein, während die bevorzugte Käufer-URL dennoch von Joomla-Menü- und Sprachbeziehungen abhängt.
Wie sollten Plugin-eigene Daten übersetzt werden?
Identifizieren Sie die Datensätze, die das Plugin erzeugt, die Produkt-, Shopper- oder Bestellbeziehungen, die es verwendet, und das Zielsystem, das dieselbe geschäftliche Funktion künftig besitzt. Erhalten Sie nur Werte mit klar definiertem weiterem Nutzen.