Bagisto verbindet Commerce-Datensätze mit einer Laravel-Anwendungsarchitektur. Fehler entstehen häufig dann, wenn Quelldaten in zentrale Tabellen geschrieben werden, ohne Produkttyp, Attributfamilie, Channel, Locale, Bestandsquelle, Customer-Gruppe, Package- oder API-Beziehung zu erhalten, die dem Datensatz seine betriebliche Bedeutung gibt. Der Shop kann dann Products und Orders enthalten, während Customer-facing oder administrative Funktionen trotzdem unvollständig bleiben.
Die folgenden Fallstricke beschreiben wiederkehrende Fehlermuster. Jeder Abschnitt nennt Warnsignale, Prävention, ein praktisches Beispiel und eine Pass-Bedingung. Tabellen werden dort eingesetzt, wo sie den Vergleich klarer machen.
Übersicht zur Vermeidung typischer Bagisto-Migrationsfehler
| Bereich | Verdeckter Fehler | Schwerpunkt der Prävention |
|---|---|---|
| Product-Architektur | Unterschiedliche Verkaufsmodelle werden zu einfachen Products abgeflacht. | Produkttyp und Child-Beziehungen erhalten. |
| Attribute | Werte werden ohne richtige Attributfamilie oder Eingabelogik übertragen. | Attribute und Familien vor dem Bulk-Import planen. |
| Channels | Datensätze existieren, gehören aber zur falschen Domain, Locale, Währung oder Root Category. | Channel-spezifische Eigentums- und Übersetzungsbeziehungen erhalten. |
| Bestand | Mengen verlieren Beziehungen zu Bestandsquelle und Channel. | SKU-Bestand expliziten Bestandsquellen zuordnen. |
| Customers | Gruppen, Zugriff, Steuer- und Preisbedeutung werden zu bloßen Bezeichnungen. | Bedeutung der Customer-Gruppe und Kontobeziehungen erhalten. |
| Orders | Summen bleiben erhalten, während Rechnungs-, Versand-, Erstattungs- oder Positionskontext verloren geht. | Historische Transaktionsbeziehungen verständlich erhalten. |
| Inhalte | CMS- und SEO-Werte werden ohne Theme-, Menü- oder Routenverantwortung übertragen. | Content-Datensätze von Storefront-Implementierung trennen. |
| Erweiterungen und APIs | Laravel-Packages und externe Clients werden an ein inkompatibles Schema angebunden. | Individuelle Eigentümerschaft inventarisieren und Verträge sowie Kennungen erhalten. |
Fallstrick 1: Unterschiedliche Produkttypen zu Simple Products abflachen
Was schiefgeht
Quell-Products mit Varianten, Bundles, Gruppen, Downloads oder Buchungsfunktion werden als einfache Bagisto-Products importiert. Titel und Preise können sichtbar sein, während Child Products, auswählbare Attribute, Bundle-Zusammenstellung, Download-Links, Buchungsslots, Stornierungslogik oder Fulfillment-Unterschiede fehlen. Der Shop zeigt dann einen Product-Datensatz, der das ursprüngliche kommerzielle Angebot nicht reproduzieren kann.
Frühe Warnsignale
| Verhalten im Quellsystem | Falsches Ergebnis im Ziel |
|---|---|
| Varianten haben eigene SKUs und Bestände. | Sie werden zu Textoptionen eines einzigen Simple Product. |
| Customers wählen Komponenten eines Bundles. | Nur Bundle-Titel und ein Preis bleiben erhalten. |
| Grouped Products bleiben einzeln kaufbar. | Sie werden in einem Bestandsdatensatz zusammengeführt. |
| Ein digitales oder buchungsbezogenes Product hat besonderes Liefer- oder Terminverhalten. | Es wird wie ein gewöhnliches versandpflichtiges Product behandelt. |
Prävention
Klassifizieren Sie jede Product-Familie vor dem Feld-Mapping nach ihrem Verkaufsverhalten. Unterscheiden Sie Simple-, Configurable-, Grouped-, Bundle-, Downloadable-, Virtual- und Booking-Anforderungen, soweit sie im Ziel existieren. Erhalten Sie Parent-Child-Beziehungen, Komponentenmengen, auswählbare Attribute, Dateien, Terminwerte und produktspezifische Betriebsregeln, statt diese in Beschreibungen zu komprimieren.
Praxisbeispiel
Für ein Trainingsunternehmen sollte ein gedrucktes Workbook als einfaches Product, eine Online-Datei als Downloadable Product, eine geplante Beratung als Booking-Verhalten und ein konfigurierbarer Merchandise-Artikel als Parent mit Child-SKUs behandelt werden. Ein einziges Product-Template für alle vier Fälle wäre ungeeignet.
Pass-Bedingung
Jede repräsentative Product-Familie verwendet einen Ziel-Produkttyp, der verkaufbare Einheiten, Auswahl, Zusammensetzung, Lieferung, Bestand und Customer-Interaktion erhält.
Fallstrick 2: Attribute ohne stabiles Attributfamilien-Modell anlegen
Was schiefgeht
Quellfelder werden einzeln als Bagisto-Attribute angelegt, ohne Eingabetyp, Code, Validierung, Storefront-Nutzung, Suchbarkeit, Eindeutigkeit, Übersetzung oder Familienzuordnung zu definieren. Gleichartige Products erhalten unterschiedliche Felder und Configurable Products fehlen die Select-Attribute für Child-Varianten. Administratoren sehen Werte, können den Katalog aber nicht konsistent pflegen.
Frühe Warnsignale
| Attributsignal | Wahrscheinliche Folge |
|---|---|
| Lesbare Labels dienen als einzige Kennung. | Integrationen können sich nicht auf stabile Attributcodes verlassen. |
| Textfelder werden für kontrollierte Auswahl verwendet. | Filterung und Variantenerzeugung werden inkonsistent. |
| Attribute werden erst nach dem Product-Import Familien zugeordnet. | Product-Formulare enthalten irrelevante Felder oder es fehlen Pflichtfelder. |
| Gleichartige Werte verwenden unterschiedliche Schreibweisen, Einheiten oder Sprachen. | Suche und Storefront-Darstellung fragmentieren. |
Prävention
Definieren Sie Attributcodes, Labels, Eingabetypen, Validierung, Optionswerte, Übersetzungsanforderungen und Attributfamilien vor der massenhaften Product-Erstellung. Gruppieren Sie Attribute nach Pflege- und Verkaufslogik. Verwenden Sie Configurable-Auswahl nur für kontrollierte Attribute, die Child Products tatsächlich unterscheiden.
Praxisbeispiel
Für Bekleidung sollten stabile Codes für Material, Größe, Farbe, Pflegehinweise und Saison existieren. Größe und Farbe werden als kontrollierte Auswahl definiert, der Bekleidungsfamilie zugeordnet und Child-SKU-Beziehungen getrennt von beschreibenden Attributen erhalten.
Pass-Bedingung
Repräsentative Products zeigen unter der vorgesehenen Familie die richtigen Attribute und Eingabeverhalten, mit normalisierten Werten und ohne fehlende Felder, die für Configurable- oder Suchlogik erforderlich sind.
Fallstrick 3: Eigentum von Channel, Locale, Währung und Root Category ignorieren
Was schiefgeht
Products, Categories, Inhalte und Preise werden geladen, als hätte Bagisto einen einzigen universellen Store-Kontext. Channels können jedoch Hostname, Root Category, Bestandsquellen, Locales, Währungen und Designkontext definieren. Ein Product kann vorhanden sein und trotzdem auf der vorgesehenen Domain fehlen, die falsche Übersetzung oder Währung verwenden oder unter einem Category-Baum erscheinen, der einem anderen Channel gehört.
Frühe Warnsignale
| Channel-Signal | Fehlermuster |
|---|---|
| Alle Datensätze werden unter dem Standard-Channel geladen. | Regionale oder markenbezogene Storefronts verlieren ihre Trennung. |
| Locale-Werte werden in einem Feld zusammengeführt. | Customers sehen vermischte oder falsche Fallback-Inhalte. |
| Währung wird nur als Formatierung betrachtet. | Preiskontext wird zwischen Channels unklar. |
| Root Categories werden erst nach Product-Zuordnung erstellt. | Navigation und Product-Sichtbarkeit müssen nachgearbeitet werden. |
Prävention
Definieren Sie jeden Ziel-Channel, bevor Channel-bezogene Datensätze geladen werden. Legen Sie Hostname, Root Category, aktivierte und Standard-Locale, Währungen, Bestandsquellen sowie Product- oder Content-Zuordnungen fest. Übersetzungen sollten nach Locale erhalten werden, statt Products nur wegen unterschiedlicher Sprache zu duplizieren.
Praxisbeispiel
Für einen englischen und arabischen Storefront mit gemeinsamem Katalog sollten Channel- und Locale-Zuordnungen bewusst geplant, Anforderungen der Rechts-nach-links-Locale berücksichtigt, die richtige Root Category verbunden und Product-Identität von übersetzten Inhalten getrennt werden.
Pass-Bedingung
Products, Categories, Inhalte, Locales, Währungen und Bestandsquellen erscheinen genau im vorgesehenen Channel-Kontext mit korrekter Übersetzung und Navigationsverantwortung.
Fallstrick 4: Mengen ohne Beziehungen zu Bestandsquellen übertragen
Was schiefgeht
Pro Product oder SKU wird nur eine Bestandszahl migriert, während Bagisto-Bestandsquellen, Prioritäten, Channel-Zuordnungen und Versand-/Fulfillment-Verantwortung unklar bleiben. Eine korrekte Gesamtmenge kann betrieblich falsch sein, wenn sie auf mehrere Warehouses verteilt ist oder der Ziel-Channel die vorgesehene Quelle nicht nutzen kann. Externe Warehouse-Updates können die Startwerte außerdem überschreiben.
Frühe Warnsignale
| Bestandssignal | Entstehendes Risiko |
|---|---|
| Product-Gesamtsummen ersetzen Child-SKU-Mengen. | Configurable-Kombinationen zeigen falsche Verfügbarkeit. |
| Warehouse-Codes fehlen. | Bestand lässt sich nicht mit physischen Standorten abstimmen. |
| Bestandsquellen sind Channels nicht zugeordnet. | Vorhandene Menge wird im vorgesehenen Shop nicht verkaufbar. |
| Eigentum von ERP oder WMS ist unklar. | Konkurrierende Updates erzeugen Overselling oder veraltete Bestände. |
Prävention
Erhalten Sie SKU, Bestandsquellen-Code, Menge, Priorität, Channel-Zuordnung und externe Kennung als eine Beziehung. Definieren Sie das führende System für fortlaufende Bestandsupdates und stimmen Sie den Eröffnungsbestand mit der ersten externen Synchronisierung ab. Verwenden Sie keine Summen, wenn Fulfillment weiterhin vom Standort abhängt.
Praxisbeispiel
Für einen konfigurierbaren Schuh in zwei Warehouses sollte jede Größen-SKU je Bestandsquelle ihre eigene Menge behalten. Die Quellen werden dem vorgesehenen Channel zugeordnet und das System definiert, das spätere Anpassungen veröffentlicht.
Pass-Bedingung
Repräsentative SKUs zeigen in den richtigen Channels korrekte quellbezogene Verfügbarkeit, und jedes Bestandsupdate hat einen dokumentierten Eigentümer und Abgleichsschlüssel.
Fallstrick 5: Customer-Gruppen nur als Bezeichnungen erhalten
Was schiefgeht
Namen von Customer-Gruppen werden kopiert, aber Rabatt-, Steuerklassen-, Product-Zugriffs-, Category-Zugriffs- oder andere betriebliche Bedeutung geht verloren. Wholesale-Customers werden zu normalen Retail-Konten, Guest- und registriertes Verhalten werden vermischt und gruppenbezogene Regeln passen nicht mehr zur vorgesehenen Zielgruppe.
Frühe Warnsignale
| Signal der Customer-Gruppe | Verdecktes Problem |
|---|---|
| Gruppen werden nur nach Namen gemappt. | Kommerzielle und Zugriffsfolgen sind unbekannt. |
| Customer-Datensätze haben keine klare Standardgruppe. | Preis- und Steuerbehandlung werden inkonsistent. |
| Wholesale-Products sind für Retail-Customers sichtbar. | Category- oder Product-Beschränkungen fehlen. |
| Externe Customer-IDs werden verworfen. | CRM- oder ERP-Synchronisierung erzeugt Dubletten. |
Prävention
Dokumentieren Sie den fortbestehenden Zweck jeder Customer-Gruppe und erhalten Sie Mitgliedschaft, Steuerklassenbeziehungen, Zugriffsfolgen, Rabatte und externe Kennungen nur dort, wo diese Funktionen in Bagisto weitergeführt werden. Trennen Sie Gruppenmitgliedschaft von Kontoaktivierung, Einwilligungen, Adressen und Order-Historie.
Praxisbeispiel
Für einen Wholesale-Customer sollten Konto, Gruppenmitgliedschaft, freigegebener Product-Zugriff, relevante Steuerbehandlung, Adressen, Order-Historie und ERP-Kennung erhalten werden. Ein Retail-Customer darf dabei keine Wholesale-Sichtbarkeit oder -Preise erben.
Pass-Bedingung
Repräsentative Customers behalten die vorgesehene Gruppe, Zugriffs-, Preis-/Rabatt-, Steuer-, Identitäts- und historische Order-Beziehung, ohne dass die Gruppenbezeichnung allein als Nachweis dient.
Fallstrick 6: Orders auf Products und Endsumme reduzieren
Was schiefgeht
Historische Orders werden auf Customer, Artikel und Summen reduziert, während Rechnungen, Sendungen, Erstattungen, Zahlungs- und Versandbezeichnungen, Rabatte, Steuern, Statushistorie, Child-SKU-Identität und externe Referenzen unvollständig werden. Mitarbeitende finden die Order, können aber nicht mehr erklären, was gekauft, fakturiert, versandt, erstattet oder abgestimmt wurde.
Historische Datensätze können außerdem fälschlich als aktuelle Payment- und Shipping-Konfiguration interpretiert werden.
Frühe Warnsignale
| Order-Nachweis | Fehlende Bedeutung |
|---|---|
| Product-Name ist erhalten. | Gekaufte Child-SKU oder ausgewählte Optionen fehlen. |
| Endsumme stimmt. | Rabatt, Steuer, Versand oder Erstattung lassen sich nicht erklären. |
| Ein Status ist sichtbar. | Beziehungen zu Rechnung, Sendung, Stornierung und Erstattung fehlen. |
| Zahlungs- und Versandnamen erscheinen. | Live-Methoden werden fälschlich als konfiguriert angenommen. |
Prävention
Definieren Sie den historischen Zweck von Orders und erhalten Sie Positions- und SKU-Kennungen, Customer, Adressen, Summen und Anpassungen, Zahlungs- und Versandbezeichnungen, Rechnung, Sendung, Erstattung, Tracking, Status und externe Schlüssel, die Support und Abgleich benötigen. Live-Checkout-Konfiguration bleibt getrennt von historischen Nachweisen.
Praxisbeispiel
Prüfen Sie eine bezahlte und versandte Order, eine teilweise erstattete Order, eine Order mit Configurable Product und eine Order mit externer ERP-Referenz. Mitarbeitende sollten den Lifecycle erklären können, ohne den Quellshop zu öffnen.
Pass-Bedingung
Repräsentative Orders bleiben über Positionen, Customer-Identität, finanzielle Komponenten, Rechnung, Sendung, Erstattung, Tracking, Status, Channel-Kontext und externen Abgleich verständlich, ohne zum Quellshop zurückkehren zu müssen.
Fallstrick 7: CMS- und SEO-Daten ohne Storefront-Eigentum übertragen
Was schiefgeht
CMS Pages, Category-Beschreibungen, Product-Inhalte, Metadaten, URL-Keys und Medien werden kopiert, aber Menüs, Theme-Bereiche, Homepage-Platzierung, Redirects, Locale-spezifische Routen und wiederverwendbare Inhaltskomponenten fehlen. Die Administration enthält den Text, während Customers fehlerhafte Einstiegspfade oder schlecht strukturierte Seiten sehen.
Frühe Warnsignale
| Inhaltssignal | Fehlermuster |
|---|---|
| Seiten werden nur anhand von Rohtext freigegeben. | Layout- und Navigationszweck gehen verloren. |
| URL-Keys werden ohne Konfliktprüfung kopiert. | Routen kollidieren oder verändern sich unerwartet. |
| Eine Sprachversion wird als alleinige kanonische Version behandelt. | Locale-spezifische Inhalte fallen falsch zurück. |
| Theme-Komponenten werden als automatische Folge der CMS-Datensätze angenommen. | Banner, Menüs und Product-Seitenbereiche fehlen. |
Prävention
Trennen Sie Inhaltsdatensätze, Routenidentität, Übersetzung, Navigation und Theme-Darstellung. Erhalten Sie bereinigte Product-, Category- und CMS-Inhalte je Locale, definieren Sie Ziel-URLs und Redirects und weisen Sie Menüs, Layouts, Theme-Komponenten und Medien-Rendering der Storefront-Implementierung zu.
Praxisbeispiel
Für eine mehrsprachige Policy-Seite und eine Category-Landingpage mit hohem Traffic werden genehmigte lokalisierte Inhalte und Metadaten erhalten, alte Routen gemappt, Menü und Layout neu aufgebaut und für jeden Channel das korrekte Locale-spezifische Ziel geprüft.
Pass-Bedingung
Priorisierte Inhalte behalten Bedeutung, Locale, URL-Ziel, Navigationspfad, Metadaten und Customer-facing Darstellung, ohne ungeklärte Quell-Theme-Abhängigkeiten oder Routenverantwortung.
Fallstrick 8: Laravel-Packages und Erweiterungen nur als Konfiguration betrachten
Was schiefgeht
Custom Laravel Packages, Marketplace-Module, B2B-Funktionen, Zahlungs- oder Versand-Packages, Suchdienste und Theme-Erweiterungen werden neu installiert und danach als vollständig wiederhergestellt betrachtet. Sie können jedoch eigene Datenbanktabellen, Modelle, Events, Queues, Konfiguration, Storefront-Komponenten oder Admin-Workflows außerhalb von Bagisto-Core-Datensätzen besitzen. Ihre Daten können fehlen, obwohl das Package selbst vorhanden ist.
Frühe Warnsignale
| Erweiterungssignal | Entstehendes Risiko |
|---|---|
| Die Package-Liste enthält kein Inventar der eigenen Daten. | benutzerdefinierte Tabellen und Beziehungen werden ausgeschlossen. |
| Neuinstallation gilt als Beweis der Wiederherstellung. | Historische Datensätze und Einstellungen fehlen weiterhin. |
| Package-Versionen unterscheiden sich, Schemakompatibilität wird aber vorausgesetzt. | Modelle oder Migrations passen nicht mehr zu vorhandenen Daten. |
| Custom Events oder Observer werden ignoriert. | Das Laden von Daten löst unbeabsichtigte Nebeneffekte aus. |
Prävention
Inventarisieren Sie jedes weiterverwendete Package anhand eigener Tabellen, Modelle, Konfiguration, Events, Queues, APIs, Storefront-Komponenten und externer Abhängigkeiten. Entscheiden Sie, ob historische Daten migriert, transformiert, archiviert, neu aufgebaut oder bewusst stillgelegt werden. Steuern Sie Reihenfolge von Package-Installation und Datenladung, damit Migrations und Event Listener importierte Datensätze nicht beschädigen.
Praxisbeispiel
Bei einem Marketplace-Package sollten Verkäuferidentitäten und -beziehungen erst nach Bestätigung des Ziel-Package-Schemas erhalten werden. Bei einem Search-Package ist zu klären, ob es Indexdaten besitzt oder seinen Index aus Bagisto-Katalogdaten neu aufbaut.
Pass-Bedingung
Jedes geschäftskritische Package hat eine kompatible Zielversion, eine explizite Entscheidung zur Datenbehandlung, eine sichere Installationsreihenfolge und funktionierende Beziehungen zu den migrierten Core-Datensätzen.
Fallstrick 9: APIs und Headless-Clients an einen inkompatiblen Vertrag anbinden
Was schiefgeht
Ein REST-, GraphQL-, Mobile- oder Headless-Client wird mit alten IDs, Feldern, Authentifizierungsannahmen oder Response-Strukturen auf die neue Bagisto-Umgebung umgestellt. Der Client kann Products abrufen und trotzdem Configurable Children, lokalisierte Werte, Preise, Bestand, Customer-Sessions oder Order-Historie verlieren. Schreibzugriffe können Dubletten erzeugen, wenn migrierte Datensätze nicht erkannt werden.
Frühe Warnsignale
| API-Signal | Wahrscheinlicher Fehler |
|---|---|
| Quell-IDs werden ohne Cross-Reference verworfen. | Externe Clients erzeugen doppelte Products oder Customers. |
| Nur einfache Product-Abfragen werden getestet. | Configurable-, Bundle-, Grouped- oder Downloadable-Beziehungen fehlen. |
| Locale- und Channel-Kontext fehlt. | Die API liefert falsche Inhalte oder kommerziellen Kontext. |
| Authentifizierung und Berechtigungen werden nur konzeptionell kopiert. | Clients können erforderliche Operationen nicht sicher ausführen. |
Prävention
Definieren Sie den Ziel-API-Vertrag nach Ressource, Kennung, Channel, Locale, Authentifizierung, Lese-/Schreibverantwortung und Fehlerverhalten. Erhalten Sie Cross-References dort, wo Clients Kontinuität benötigen. Trennen Sie historische Importe von Live-API-Events und stellen Sie sicher, dass Clients bestehende Objekte aktualisieren statt neu anzulegen.
Praxisbeispiel
Für einen Mobile-Storefront können ein Simple Product und eine Configurable-Familie in zwei Locales abgefragt, die vorgesehene Child-SKU in den Warenkorb gelegt, ein Customer authentifiziert und Order-Historie mit Zielkennungen und Channel-Kontext abgerufen werden.
Pass-Bedingung
Jeder weiterverwendete API- oder Headless-Client liest und schreibt die richtigen Bagisto-Ressourcen im vorgesehenen Channel und in der richtigen Locale und verwendet stabile Identitäten, ohne Dubletten zu erzeugen.
Fallstrick 10: Annehmen, dass Datenbankdatensätze Checkout und Betrieb automatisch wiederherstellen
Was schiefgeht
Die Migration lädt Products, Customers und Orders direkt und nimmt an, Payment, Shipping, Tax, Benachrichtigungen, Queues, Indizes, Caches, Themes und externe Services würden automatisch folgen. In einer Laravel-Anwendung können Konfiguration, Code, Environment-Variablen, geplante Jobs, Queues und Deployment-Zustand genauso wichtig sein wie die Datenbank. Korrekte Datensätze können daher einen unbrauchbaren Shop ergeben.
Frühe Warnsignale
| Anwendungssignal | Verdeckte Lücke |
|---|---|
| Historische Payment- und Shipping-Bezeichnungen werden als Einrichtung behandelt. | Aktuelle Zugangsdaten, Tarife und Einschränkungen fehlen. |
| Queue Worker und Scheduled Tasks haben keinen Verantwortlichen. | E-Mails, Indizes oder Integrationen werden inkonsistent verarbeitet. |
| Cache- und Search-Index-Daten werden kopiert statt neu aufgebaut. | Veraltete oder inkompatible abgeleitete Daten bleiben erhalten. |
| Umgebungsspezifische Secrets werden ungeprüft übertragen. | Security und Service-Verbindungen sind unsicher oder ungültig. |
Prävention
Trennen Sie dauerhafte Commerce-Datensätze von Anwendungskonfiguration und abgeleitetem Zustand. Bauen Sie Payment, Shipping, Tax, Benachrichtigungen, Queues, Schedules, Indizes, Caches, Environment-Variablen und Service-Zugangsdaten im Ziel-Deployment neu auf. Cache- oder Indexdaten sollten nicht als führende Datensätze importiert werden.
Praxisbeispiel
Nach dem Laden des Katalogs werden relevante Indizes und Caches neu aufgebaut, ein aktueller Payment- und Shipping-Pfad konfiguriert, Queue- und Scheduler-Verantwortung festgelegt und geprüft, ob eine repräsentative Order die vorgesehene Benachrichtigung und operative Übergabe auslöst.
Pass-Bedingung
Migrierte Datensätze funktionieren innerhalb einer bewusst konfigurierten Bagisto-Anwendung, in der aktuelle Services, Queues, Schedules, Indizes, Caches und Zugangsdaten unabhängig von historischen Daten verantwortet werden.
Fazit
Eine Bagisto-Migration erfordert mehr als Datenbankkompatibilität. Produkttypen, Attribute, Channels, Bestandsquellen, Customer-Gruppen, Order-Beziehungen, Inhalte, Laravel-Packages, APIs und Anwendungskonfiguration müssen ihre jeweils eigene Verantwortungslogik behalten. Der sicherste Präventionsansatz erhält die Bedeutung der zentralen Commerce-Daten und baut Package- und Deployment-Verhalten bewusst um die Zielanwendung herum neu auf.
Häufige Fragen
Warum sollten Bagisto-Produkttypen vor dem Feld-Mapping klassifiziert werden?
Jeder Produkttyp trägt andere Beziehungen und anderes Customer-Verhalten. Ein Configurable-, Grouped-, Bundle-, Downloadable- oder Booking Product kann nicht korrekt dargestellt werden, wenn lediglich die Felder eines Simple Product kopiert werden.
Was ist der Unterschied zwischen einem Bagisto-Attribut und einer Attributfamilie?
Ein Attribut definiert eine Product-Eigenschaft und ihr Eingabeverhalten. Eine Attributfamilie gruppiert die Attribute, die zu einem bestimmten Product-Pflegemodell gehören. Products benötigen die richtige Familie, damit die vorgesehenen Felder konsistent verfügbar sind.
Warum kann ein Product vorhanden sein und trotzdem im Bagisto-Storefront fehlen?
Channel-Zuordnung, Root Category, Locale, Währung, Status, Bestandsquelle, Menge und Theme-Darstellung können Sichtbarkeit und Verkaufbarkeit beeinflussen. Product-Präsenz in der Administration reicht nicht aus.
Wie sollte Multi-Warehouse-Bestand nach Bagisto migriert werden?
Erhalten Sie SKU-bezogene Mengen je Bestandsquelle, ordnen Sie die Quellen den vorgesehenen Channels zu, bewahren Sie Warehouse-Kennungen und definieren Sie ERP oder WMS als fortlaufenden Update-Eigentümer. Ersetzen Sie standortbezogenen Bestand nicht durch eine einzige Summe.
Stellt die Installation derselben Bagisto-Erweiterung deren Daten automatisch wieder her?
Nicht zwingend. Ein Package kann benutzerdefinierte Tabellen, Modelle, Einstellungen, Events und Storefront-Komponenten besitzen. Historische Daten brauchen deshalb eine explizite Kompatibilitäts- und Behandlungsentscheidung.
Warum sollten Cache- und Search-Index-Daten nicht als Migrationsdatensätze behandelt werden?
Caches und Indizes werden aus führenden Anwendungsdaten und Code abgeleitet. Werden sie zwischen Umgebungen kopiert, können veraltete oder inkompatible Zustände erhalten bleiben. Sie sollten normalerweise in der Zielanwendung neu aufgebaut werden.