Wenn VirtueMart als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn VirtueMart als Zielplattform ausgewählt wird, muss die Vorbereitung sowohl die Commerce-Datensätze als auch die Joomla-Strukturen dokumentieren, durch die diese Datensätze nutzbar werden. Produkte können von Kategorien, Child Products, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Medien, Download-Dateien, Zahlungs- und Versand-Plugins, Joomla-Menüs, Sprachzuordnungen, Template-Overrides und externen Integrationen abhängen. Eine reine Produktanzahl erklärt keine dieser Abhängigkeiten.
Für jede erforderliche Maßnahme vor der Ausführung sollte die VirtueMart-Vorbereitung einen verantwortlichen Eigentümer, unterstützende Nachweise und eine eindeutige Freigabebedingung festlegen. Außerdem muss sie Quellnachweise von Zielimplementierung trennen: Historische Bestellungen, Produktbeziehungen, Shopper-Gruppen-Zuordnungen und URLs gehören zur Migrationsvorbereitung, während aktives Zahlungs-, Versand-, Steuer-, Checkout-, E-Mail- und Template-Verhalten Zielkonfiguration bleibt.
Joomla-, VirtueMart-, Hosting- und Datenbankzugriff absichern
Bestätigen Sie Zugriff auf Joomla-Administration, VirtueMart-Administration, Hosting, Datenbank, Dateisystem, Produktmedien, Download-Dateien, geplante Aufgaben und verbundene Dienste. Dokumentieren Sie Joomla-Version, VirtueMart-Version, PHP- und Datenbankumgebung, aktives Template, Sprachen, aktivierte Plugins, Zahlungs- und Versandmethoden sowie eigenen Code oder Overrides.
| Vorbereitungsmaßnahme | Verantwortlich | Nachweis | Freigabebedingung |
|---|---|---|---|
| Administrativen Zugriff bestätigen | Joomla-/VirtueMart-Administrator | Funktionierende Konten und Rollenübersicht | Produkte, Custom Fields, Kunden, Bestellungen, Plugins, Menüs und Konfiguration können geprüft werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Datenbankexport, Dateisystemarchiv, Medien-/Download-Archiv und benannter Restore-Verantwortlicher | Der Quellshop kann ohne Abhängigkeit von der Live-Umgebung wiederhergestellt werden. |
| Plattform- und Erweiterungsversionen dokumentieren | Technischer Verantwortlicher | Inventar von Joomla, VirtueMart, PHP, Datenbank, Template, Plugins, Modulen und Paketen | Versionsabhängige Datensätze und Kompatibilitätsannahmen sind dokumentiert. |
| Custom Code und Overrides erfassen | Entwicklungsverantwortlicher | Template-Overrides, geänderte Layouts, eigene Plugins, Skripte und direkte Datenbankänderungen | Jede Anpassung, die Commerce-Daten liest oder schreibt, hat einen Verantwortlichen. |
| Verbundene Systeme abbilden | Integrationsverantwortliche | ERP-/PIM-/WMS-/CRM-/Zahlungs-/Versand-/Datenexport-Endpunkte und externe IDs | Weiterhin genutzte Systeme und maßgebliche Datenquellen sind identifiziert. |
Bewahren Sie interne IDs für Produkte, Kategorien, Hersteller, Custom Fields, Shopper-Gruppen, Joomla-Benutzer, VirtueMart-Shopper, Bestellungen, Bestellpositionen, Status, Medien und externe Systeme. Diese Kennungen sind entscheidend, wenn Datensätze über Joomla- und VirtueMart-Tabellen hinweg abgeglichen werden müssen.
Produkte, Kategorien, Hersteller und Medien vorbereiten
VirtueMart-Produkte können SKU, GTIN oder Herstellerkennungen, Beschreibungen, Preise, Bestand, Abmessungen, Bilder, Hersteller, Kategorien, Child-Product-Verknüpfungen, Custom Fields, verwandte Produkte, Download-Dateien und Shopper-Gruppen-Einschränkungen enthalten. Bereiten Sie den Katalog anhand des Verkaufsverhaltens und nicht anhand der Zeilenanzahl vor.
| Produktmuster | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Einfaches physisches Produkt | Produkt-ID, SKU, Preis, Steuerregel, Bestand, Gewicht, Kategorie, Hersteller, Bilder und Musterbestellung | Ein Datensatz identifiziert eindeutig den verkauften und abgewickelten Artikel. |
| Parent und Child Products | Parent-ID, Child-IDs, Vererbungsverhalten, Child-SKUs, Preise, Bestand, Bilder, Kategorien und Aliasse | Jedes verkaufbare Child kann zum Parent und seinen überschriebenen Werten zurückverfolgt werden. |
| Download-Produkt | Dateipfad, Zugriffsbeziehung, Limit oder Ablauf, Produktverknüpfung und Beispiel einer abgeschlossenen Bestellung | Dateien und Nachweise für bestellungsbasierten Zugriff sind wiederherstellbar. |
| Produkt in mehreren Kategorien | Produkt-zu-Kategorie-Zuordnungen und priorisierte Route | Es werden keine Produktduplikate nur zur Reproduktion von Entdeckungspfaden erzeugt. |
| Produkt mit Herstellerbezug | Hersteller-ID, Name, Produktverknüpfung, externer Schlüssel und Route | Marken-/Herstelleridentität bleibt von der Kategorienstruktur getrennt. |
| Medienintensives Produkt | Haupt-/Zusatzbilder, Dokumente, Remote-Dateien, Reihenfolge und Child-spezifische Medien | Jede Mediendatei hat einen bekannten Product- oder Child-Product-Eigentümer. |
Dokumentieren Sie unveröffentlichte, archivierte, reine Katalog-, ausverkaufte und rückständige Produkte sowie Mindest-/Höchstmengen und Verfügbarkeitsdaten. Diese Zustände benötigen eine bewusste Zielbehandlung und dürfen nicht in einen einzigen aktiven Produktstatus normalisiert werden.
Custom Fields, Child Products und Käuferauswahlen vorbereiten
VirtueMart-Custom-Fields können Produkte beschreiben, vom Shopper auswählbare Eingaben erzeugen, den Preis beeinflussen, in Warenkorb- und Bestellansichten erscheinen, verwandte Produkte oder Kategorien verbinden, Downloads anhängen oder von Plugins abhängen. Child Products können Parent-Werte erben und zugleich Preis, Bestand, Bild, Kategorie oder Shopper-Gruppen-Zuordnung überschreiben.
| Struktur | Erforderlicher Nachweis | Freigabebedingung |
|---|---|---|
| Beschreibendes Custom Field | Felddefinition, Typ, Titel, Werte, Produktzuordnungen, Anzeigeposition und Suchnutzung | Beschreibende Daten sind von kaufbaren Auswahlen getrennt. |
| Warenkorbattribut oder Warenkorbeingabe | Felddefinition, Pflichtstatus, Preisauswirkung, ausgewählte Werte und Beispiel einer Bestellposition | Käuferauswahlen bleiben mit der gekauften Position verbunden. |
| Plugin-Custom-Field | Plugin-Eigentümer, Parameter, Tabellen, Produktverknüpfungen und Ausgabebeispiel | Erweiterungseigenes Verhalten wird nicht mit normalen Felddaten verwechselt. |
| Parent-/Child-Produkt | Vererbungsregeln, überschriebene Werte, Child-SKU, Bestand, Preis, Bild, Alias und Kategorie | Jedes verkaufbare Child ist vollständig nachvollziehbar. |
| Verwandtes Produkt oder Kategorie | Beziehungstyp, Quell-IDs, Anzeigezweck und Priorität | Merchandising-Beziehungen sind getrennt von Taxonomie dokumentiert. |
Erstellen Sie ein Feldregister mit einer Zeile pro wichtigem Custom Field. Dokumentieren Sie, ob das Feld Identität, Produktauswahl, Preis, Bestand, Download-Zugriff, Darstellung, Suche oder einen anderen Plugin-Prozess steuert. Ähnliche Labels sollten nur zusammengeführt werden, wenn auch ihr kommerzielles Verhalten gleichwertig ist.
Shopper-Gruppen, Kunden, Joomla-Benutzer und Adressen vorbereiten
VirtueMart-Shopper-Gruppen können Produktsichtbarkeit, Produktpreise, Berechnungsregeln, Zahlungs- und Versandmethoden sowie Preisdarstellung steuern. Kunden können außerdem Joomla-Benutzer, VirtueMart-Shopper-Datensätze, Adressen, individuelle Shopper-Felder, Unternehmens- oder Steuerkennungen und externe CRM-/ERP-Schlüssel umfassen.
| Kontobereich | Nachweis | Verantwortlich | Freigabebedingung |
|---|---|---|---|
| Joomla-Benutzer und VirtueMart-Shopper-Verknüpfung | Joomla-Benutzer-ID, VirtueMart-Benutzer-ID, E-Mail, Status, Gruppen und externe ID | Kundendatenverantwortlicher | Die Kontobeziehung ist über Joomla und VirtueMart hinweg nachvollziehbar. |
| Shopper-Gruppen-Mitgliedschaft | Gruppendefinitionen, zugewiesene Shopper, Produktpreise, Berechnungsregeln und Zahlungs-/Versandeinschränkungen | Commerce-Verantwortlicher | Die Bedeutung der Gruppe ist über ihr Label hinaus dokumentiert. |
| Adress- und Checkout-Felder | Felddefinitionen, Pflicht-/Anzeigeregeln, Rechnungs-/Versandwerte und Länder-/Regionsreferenzen | Kundenservice-Verantwortlicher | Gespeicherte Adressen und Bestellzeit-Adress-Snapshots lassen sich unterscheiden. |
| Gastkäufer | Bestellbezogene Identität, Adressen, E-Mail und Zugriffsnachweis | Bestelldatenverantwortlicher | Gast-Historie erfordert kein künstlich erzeugtes Joomla-Konto. |
| Unternehmens- oder Steueridentität | Unternehmensfelder, Steuernummer, Validierungsstatus und externer Kontoschlüssel | Finance-/B2B-Verantwortlicher | Geschäftskontodaten haben ein benanntes Ziel oder einen erhaltenen Eigentümer. |
| Authentifizierung | Lokales Passwort, SSO, Social Login, MFA, Reset-Kommunikation und Kontoverantwortlicher | Sicherheitsverantwortlicher | Kontozugriff ist geplant, ohne Passwortportabilität vorauszusetzen. |
Nehmen Sie repräsentative Shopper auf, die mehreren Gruppen angehören, Sonderpreise erhalten, eingeschränkte Zahlungs- oder Versandmethoden nutzen oder mehrere Adressen besitzen. Diese Fälle machen Beziehungen sichtbar, die normale Retail-Konten nicht zeigen.
Preise, Berechnungsregeln, Steuern, Gutscheine und Bestand vorbereiten
VirtueMart-Preisbildung kann mehrere Produktpreise, Währungen, Mengenbereiche, Shopper-Gruppen, Kosten- und Basispreise, Steuerregeln, Rabatte, Overrides und Berechnungsreihenfolgen umfassen. Bestand kann einem Parent Product, Child Product oder externen System gehören.
| Kommerzieller Bereich | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Produktpreise | Product-/Child-ID, Währung, Shopper-Gruppe, Mengenbereich, Datumswerte, Kosten-/Basis-/Endwerte und Override-Status | Jeder Preis ist dem richtigen Produkt und Geschäftskontext zugeordnet. |
| Berechnungsregeln | Regeltyp, Steuer-/Rabattwirkung, Kategorien, Shopper-Gruppen, Länder, Regionen, Datumswerte und Berechnungsreihenfolge | Regeln sind als Konfigurationsbeziehungen und nicht als Produktfelder dokumentiert. |
| Gutscheine | Code, Typ, Wert, Datumswerte, Nutzungsstatus und relevante historische Bestellungen | Historische Gutschein-Nachweise sind von aktiver Gutschein-Konfiguration getrennt. |
| Bestand | Product-/Child-ID, Menge, ggf. reservierter Bestand, Schwellenwert für niedrigen Bestand und externer Bestandsverantwortlicher | Maßgebliche Menge und Schlüssel der verkaufbaren Einheit sind bekannt. |
| Mengenbeschränkungen | Mindest-, Höchst-, Verpackungs- und Kaufschrittregeln | Mengenbeschränkungen gehen nicht in generischen Produktnotizen verloren. |
Historische Bestellsummen müssen Snapshots bleiben. Planen Sie nicht, alte Preise, Steuern, Rabatte oder Versandkosten aus aktuellen Berechnungsregeln neu zu erzeugen.
Bestellungen, Status, Zahlung, Versand und Rechnungen vorbereiten
Bereiten Sie Bestellungen als historische Geschäftsnachweise vor. Dazu gehören Bestellköpfe, Shopper, Gastidentitäten, Rechnungs- und Versand-Snapshots, Produkt- und Child-Product-Positionen, ausgewählte Custom Fields, Mengen, Preise, Steuern, Rabatte, Gutscheine, Zahlungslabels, Versandlabels, Status, Kommentare, Rechnungen, Erstattungen oder Korrekturen und externe Referenzen.
| Bestellnachweis | Verantwortlich | Freigabebedingung |
|---|---|---|
| Bestellkopf und Statushistorie | Commerce Operations | Statusfolge, Zeitstempel, Shopper-/Gastkontext und aktuelle Bedeutung sind dokumentiert. |
| Produktpositionen und Auswahlen | Katalog- und Bestellverantwortliche | Product-/Child-IDs, SKU, ausgewählte Custom Fields, Menge und Snapshot-Text sind vollständig. |
| Summen und Anpassungen | Finance-Verantwortlicher | Zwischensumme, Steuer, Rabatt, Gutschein, Versand, Zahlungskosten und Endsumme stimmen überein. |
| Zahlungs- und Versandreferenzen | Finance- und Fulfillment-Verantwortliche | Historische Methodenlabels, Transaktions-/Tracking-IDs und Provider-Verantwortung sind bekannt. |
| Rechnungen und Dokumente | Finance-Verantwortlicher | Rechnungsnummern, Dateien, Sprache und Bestellbeziehungen sind wiederherstellbar. |
| Externe Bestell-IDs | Integrationsverantwortlicher | ERP-, Buchhaltungs-, Marktplatz- oder Fulfillment-Referenzen bleiben nachvollziehbar. |
Wählen Sie normale, Gast-, Shopper-Gruppen-, rabattierte, Multi-Steuer-, erstattete, Download- und Child-Product-Bestellungen. Das Musterset sollte die Bestellzustände abdecken, die Mitarbeiter tatsächlich für Kundenbetreuung und Abgleich benötigen.
Joomla-Menüs, Routen, Sprachen, Medien und Shop-Abhängigkeiten vorbereiten
VirtueMart-Datensätze hängen von Joomla-Menüs, Aliasen, Zugriffsebenen, Sprachzuordnungen, Modulen, Template-Layouts, Overrides, Such-/Filtererweiterungen und Content-Links ab. Das Migrieren von Produkten und Kategorien erstellt diese Darstellungsbeziehungen nicht automatisch neu.
| Shop-Bereich | Nachweis | Freigabebedingung |
|---|---|---|
| Produkt- und Kategorierouten | Quell-URL, Product-/Category-ID, Alias, Sprache, Menükontext, Metadaten und Zielabsicht | Priorisierte Routen haben eine eindeutige Entscheidung: erhalten, ändern, zusammenführen, stilllegen oder weiterleiten. |
| Joomla-Menüs und -Module | Menüeintragstyp, Parent, Alias, Sprache, Zugriff, Modulposition und Seitenzuordnung | Commerce-Einstiegspunkte und Entdeckungsabhängigkeiten sind dokumentiert. |
| Mehrsprachige Datensätze | Sprach-Tags, Zuordnungen, übersetzte Produkte/Kategorien, Menüs, Medien und Fallback-Regeln | Zusammengehörige Übersetzungen werden nicht als unabhängige Duplikate behandelt. |
| Template und Overrides | Template-Name, VirtueMart-Layouts, Override-Dateien, Custom-Field-Positionen und betroffene Routen | Darstellungsabhängigkeiten sind von Commerce-Daten getrennt. |
| Medien und Downloads | Pfade, Remote-Speicher, Thumbnails, Download-Dateien und Zugriffsregeln | Priorisierte Dateien sind verfügbar und mit den richtigen Datensätzen verknüpft. |
| SEO und Weiterleitungen | Metadatenverantwortlicher, Routing-Erweiterung, Weiterleitungsregeln, Sitemaps und wichtige URLs | URL-Kontinuität hat einen expliziten Verantwortlichen. |
Das Joomla-CMS-Inventar gehört zum breiteren Joomla-Vorbereitungsumfang. Diese Checkliste erfasst nur Joomla-Strukturen, die VirtueMart-Commerce-Datensätze und -Routen wesentlich beeinflussen.
Plugins, Custom Tables und externe Systeme inventarisieren
Erstellen Sie ein Erweiterungsregister für Zahlung, Versand, Custom Fields, Suche/Filter, Subscriptions, Downloads, Marktplätze, Datenexporte, Buchhaltung, ERP, CRM, Bestand, Analysen und individuellen Code. Dokumentieren Sie, was jede Komponente besitzt und auf welche Kerndatensätze sie verweist.
| Abhängigkeit | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| VirtueMart-Plugin | Name, Version, Zweck, Konfiguration, Tabellen/Felder und betroffene Produkte/Kunden/Bestellungen | Plugin-eigene Datensätze haben ein Ziel oder einen erhaltenen Systemverantwortlichen. |
| Joomla-Erweiterung | Komponenten-/Modul-/Plugin-Name, Menü-/Modulabhängigkeit und Datenverantwortlicher | Gemeinsames Joomla-Verhalten wird nicht fälschlich als VirtueMart-Kerndaten klassifiziert. |
| Individuelle Tabelle oder Spalte | Schema, Schlüsselbeziehungen, Geschäftszweck und konsumierender Code | Individuelle Datensätze können interpretiert statt blind kopiert werden. |
| Externes System | Endpunkt, maßgebliche Datentypen, Synchronisationsrichtung, IDs und Cutover-Verantwortlicher | Systemübergreifende Identität und Datenhoheit sind dokumentiert. |
| Generierte Daten | Caches, Logs, Sessions, Indizes, temporäre Dateien und aufgegebene Datensätze | Nicht maßgebliche Daten werden bewusst ausgeschlossen. |
Inaktive Erweiterungen sollten im Register bleiben, wenn ihre Daten weiterhin kommerziell oder historisch wichtig sind.
Repräsentative Testmuster für die Migration auswählen
Wählen Sie Muster, die die tatsächliche Struktur des Shops sichtbar machen. Dokumentieren Sie Quell-IDs, SKUs, URLs, Gruppenzuordnungen, externe Schlüssel, verwandte Datensätze und den Grund für die Auswahl jedes Musters.
| Muster | Vorzubereitende Nachweise | Zweck der Vorbereitung |
|---|---|---|
| Einfaches Produkt | Preis, Bestand, Steuer, Kategorie, Hersteller, Medien und Bestellung | Definiert die Basis für normale VirtueMart-Produktdarstellung vor komplexeren Mustern. |
| Parent-/Child-Familie | Parent und Children, Custom Fields, SKUs, Preise, Bestand, Bilder und Aliasse | Repräsentiert geerbte und überschriebene Produktwerte. |
| Produkt mit Custom Fields | Felddefinitionen, Plugin-Abhängigkeiten, Preis-/Warenkorbwirkungen und Bestellposition | Macht Käuferauswahl- und Erweiterungsbeziehungen sichtbar. |
| Shopper-Gruppen-Fall | Kunde, Gruppen, eingeschränkte Produkt-/Preis-/Zahlungs-/Versandnachweise | Repräsentiert B2B- oder segmentierten Commerce. |
| Komplexe Bestellung | Gast-/registrierte Identität, Child Product, individuelle Auswahlen, Gutschein, Steuer, Zahlung, Versand und Rechnung | Repräsentiert historischen Geschäftskontext. |
| Mehrsprachige Route | Produkt-/Kategorieübersetzungen, Aliasse, Menüpfade, Metadaten und Weiterleitungsabsicht | Repräsentiert Joomla-Sprach- und Routing-Abhängigkeiten. |
| Erweiterungseigener Datensatz | Kerndatentyp, individuelle Tabelle/Feld, Plugin-Eigentümer und externer Schlüssel | Macht Nicht-Core-Umfang vor der Ausführung sichtbar. |
Das VirtueMart-Musterpaket ist bereit, wenn jeder ausgewählte Datensatz über Quellnachweise, Joomla- und Shopper-Gruppen-Kontext, zugehörige Dateien und einen benannten Prüfer verfügt.
Abschließendes VirtueMart-Bereitschaftstor
| Bereitschaftsbereich | Freigabebedingung |
|---|---|
| Zugriff und Wiederherstellung | Joomla, VirtueMart, Hosting, Datenbank, Dateien, Backups und Wiederherstellungsverantwortung sind bestätigt. |
| Katalog | Produkte, Children, Kategorien, Hersteller, Medien, Custom Fields, Bestand, Preise und Kennungen sind dokumentiert. |
| Kunden | Joomla-Benutzer, Shopper, Gruppen, Adressen, Felder, Gastidentitäten und Authentifizierungsabhängigkeiten sind klassifiziert. |
| Bestellungen | Positionen, Auswahlen, Summen, Status, Zahlung, Versand, Rechnungen und externe Referenzen verfügen über Quellnachweise. |
| Shop | Menüs, Routen, Sprachen, Module, Overrides, Medien, SEO und Weiterleitungen sind dokumentiert. |
| Abhängigkeiten | Plugins, Custom Code, Tabellen, externe Systeme und Datenverantwortlichkeiten haben benannte Eigentümer. |
| Muster | Repräsentative Datensätze decken jedes wesentliche Produkt-, Kunden-, Bestell-, Routen- und Erweiterungsmuster ab. |
Die VirtueMart-Vorbereitung ist abgeschlossen, wenn jeder wesentliche Commerce-Datensatz über seinen Joomla-Eigentümer, zugehörige Plugin- oder Custom-Field-Datensätze, Nachweisartefakte und sein vorgesehenes Ziel oder erhaltenes System nachvollzogen werden kann.
Fazit
Die Vorbereitung einer Migration zu VirtueMart erfordert koordinierte Nachweise über Joomla, Produkte, Child Products, Custom Fields, Shopper-Gruppen, Preise, Berechnungsregeln, Kunden, Bestellungen, Medien, Routen, Plugins und externe Systeme hinweg. Die Checkliste sollte diese Beziehungen vor der Ausführung explizit machen, statt sich auf Produktanzahlen oder Screenshots zu verlassen.
Ein vollständiges VirtueMart-Bereitschaftspaket bewahrt wiederherstellbare Nachweise, benennt maßgebliche Datensätze, trennt historische Transaktionen von Live-Konfiguration und klärt die Verantwortung für jede wesentliche Abhängigkeit.
Häufige Fragen
Was sollte bei einer VirtueMart-Migration zuerst vorbereitet werden?
Bestätigen Sie zunächst den Zugriff auf Joomla, VirtueMart, Hosting, Datenbank, Dateisystem, Medien und Erweiterungen. Erstellen Sie danach wiederherstellbare Backups und dokumentieren Sie die Plattformversionen. Detaillierte Katalogarbeit sollte erst beginnen, wenn das Team die Quelle zuverlässig prüfen und wiederherstellen kann.
Warum benötigen VirtueMart-Custom-Fields ein eigenes Register?
Custom Fields können Produkte beschreiben, Käufereingaben erfassen, Preise beeinflussen, auf Bestellpositionen erscheinen, verwandte Datensätze verbinden, Downloads anhängen oder von Plugins abhängen. Ihr Label allein verrät weder die geschäftliche Funktion noch den Ziel-Eigentümer.
Wie sollten Parent und Child Products vorbereitet werden?
Dokumentieren Sie Parent- und Child-IDs, geerbte Werte, überschriebene SKUs, Preise, Bestand, Bilder, Kategorien, Shopper-Gruppen, Aliasse und Custom Fields. Jedes tatsächlich verkaufbare Child sollte eigenständig nachvollziehbar bleiben und zugleich seine Parent-Beziehung bewahren.
Warum gehören Shopper-Gruppen zur Vorbereitung?
Shopper-Gruppen können Sichtbarkeit, Preise, Berechnungsregeln, Zahlungs- und Versandmethoden sowie angezeigte Preiselemente beeinflussen. Nur den Gruppennamen zu erhalten würde die kommerziellen Beziehungen entfernen, die ihn nützlich machen.
Welche VirtueMart-Bestellungen eignen sich als repräsentative Muster?
Nehmen Sie normale und Gastbestellungen, Shopper-Gruppen-Fälle, Child Products, Custom-Field-Auswahlen, Gutscheine, mehrere Steuern, Erstattungen oder Anpassungen, Downloads, Rechnungen und externe Referenzen auf, die Teams für Kundenbetreuung oder Finanzen tatsächlich verwenden.
Wie sollten Joomla- und VirtueMart-Vorbereitung aufgeteilt werden?
Der Joomla-Umfang besitzt allgemeine CMS-Inhalte, Benutzer, Menüs, Module, Templates und Erweiterungen. Der VirtueMart-Umfang besitzt Commerce-Produkte, Shopper-Gruppen, Kunden, Bestellungen, Berechnungsdatensätze und Commerce-Plugins und dokumentiert nur die Joomla-Abhängigkeiten, die diese Datensätze benötigen.