Stand: 2026-07-24
dbxShop ist die Shop-Fachanwendung von dbxapp. Sie umfasst inzwischen den oeffentlichen Katalog, Produktsuche und Filter, Warenkorb, Checkout, Zahlungsarten, Bestellungen, Rechnungen, Widerruf, Medien, Artikelgruppen, Attribute, Versandgruppen und Verkaufskanaele. Die Administration liegt in einem getrennten Modul dbxShop_admin.
Der Shop nutzt die normalen dbxapp-Bausteine: Routing ueber dbx_run1, Templates ueber dbxTPL, Datenzugriff ueber dbxDB, Struktur ueber DD, Formulare ueber dbxForm, Listen ueber dbxReport, CMS-Seiten fuer Rechtstexte und openWin fuer Admin-Dialoge.
Fachliches Gesamtbild
dbxShop deckt den Weg von einem gepflegten Produkt bis zur nachvollziehbaren Bestellung ab:
Der Shop ist dabei kein isoliertes Fremdsystem. CMS, Benutzer, Medien, Workflow, Mail, PDF, Konfiguration und Designs werden über die vorhandenen dbxapp-Bausteine verbunden.
Rollen und typische Aufgaben
| Rolle | Typische Aufgaben |
|---|---|
| Besucher/Kunde | suchen, filtern, Produkt ansehen, Warenkorb, Checkout, Bestellung/Rechnung ansehen, Widerruf senden |
| Produktpflege | Produkt, Gruppe, Attribute, Bilder, Preis, Steuer, Bestand und Versand pflegen |
| Shop-Admin | Bestellungen, Zahlungen, Rechnung, Versand, Tracking, Rechtstexte und Einstellungen verwalten |
| Channel-Manager | Kanäle konfigurieren, Mapping prüfen, Produkte exportieren, Webhooks überwachen |
| Entwickler | Repository/Service/Adapter erweitern, ohne Preis- oder Rechteprüfungen ins Template zu verlagern |
Produktlebenszyklus
- Produkt mit eindeutiger SKU und verständlichem Slug anlegen.
- Titel, Beschreibung, Produkttyp und Aktivstatus pflegen.
- Brutto-/Nettopreis, Steuerklasse und gegebenenfalls Bestand festlegen.
- Eine Primärgruppe und optionale weitere Gruppen zuordnen.
- Attribute der Gruppen ausfüllen; filterbare Attribute bewusst markieren.
- Produkt- oder Gruppenbilder aus der zentralen Medienverwaltung zuordnen.
- Versandgruppen und Lieferinformationen prüfen.
- interne bzw. externe Channels aktivieren und Overrides pflegen.
- Produktvorschau in Katalog und Detailansicht prüfen.
- Produkt freigeben bzw. über den passenden Workflow veröffentlichen.
Gruppen sind mehr als Navigation. Sie können Darstellung, Attribute, Steuer- und Versanddefaults sowie Channel-Gruppen bündeln. Ein konkreter Produktwert gewinnt, ein leerer/erbender Wert verwendet den fachlich vorgesehenen Gruppendefault.
Kundenerlebnis
Katalog
Der öffentliche Katalog kombiniert Suche, Gruppenbaum und Attributfilter. Angezeigt werden nur aktive, für den internen shop-Channel freigegebene Produkte. Produktkarten kommen aus einem TPL-Report; dadurch bleiben Filter, Trefferzahl und Pagination Teil der Reportpipeline, obwohl keine klassische Tabelle sichtbar ist.
Produktdetail
Die Detailansicht zeigt:
- Mediengalerie und Primärbild,
- Titel, Kurz- und Langbeschreibung,
- Preis-/Steuerinformation,
- Lieferzeit, Versand und Bestand,
- sichtbare Produktattribute,
- Warenkorbaktion,
- gruppenabhängiges Detail- und Gallerytemplate.
Eine SKU oder ID aus der URL wird immer gegen aktiven Channel, Aktivstatus und Zugriffsregeln geprüft.
Warenkorb
Der Session-Warenkorb ist nur eine Benutzerabsicht. Vor Anzeige und Checkout werden Produkte, Mengen, Preis, Steuer, Bestand und Lieferbarkeit erneut aus dem Repository bestimmt. Vom Browser übergebene Summen oder Preise sind nie die Berechnungsgrundlage.
Checkout
Der Checkout verwendet dbxForm und führt den Kunden durch Kontakt-/Adressdaten, Zahlungsart, Hinweise und Zustimmungen. Nur konfigurierte Zahlungsarten werden angeboten. Rechtstexte können als Snapshot in der Bestellung gespeichert werden, damit der zum Kaufzeitpunkt akzeptierte Stand erhalten bleibt.
Sprachabhängige Oberfläche
Katalogfilter, Kauf- und Warenkorbformular, Checkout sowie die öffentliche Bestellliste besitzen eigene deutsche, englische und spanische FDs:
Die jeweilige FD liefert neben Feldlabels auch Seiten-/Bar-Titel, Reportspalten, Statusbeschriftungen, leere Zustände, Zahlungs- und Validierungshinweise sowie Confirmtexte. dbxForm und dbxReport laden diese Meldungen über ihren gemeinsamen FD-Mechanismus. Allgemeine Browserknöpfe wie Ja/Nein kommen aus der zentralen JavaScript-Übersetzung.
Produktnamen, Gruppennamen, Attribute, Liefertexte oder Zahlungsanweisungen aus der Datenbank sind gespeicherte Fachdaten. In einer einsprachigen Shoptabelle werden sie nicht durch eine FD scheinübersetzt. Dafür wären echte Sprachtabellen und passende Sprach-DDs erforderlich.
Bestelllebenszyklus
Eine Bestellung besitzt zwei fachlich getrennte Zustände:
- Bestell-/Abwicklungsstatus, z. B. Zahlung ausstehend, in Bearbeitung, versendet oder abgeschlossen.
- Zahlungsstatus und Providerreferenz, z. B. offen, bestätigt, fehlgeschlagen oder erstattet.
shop_order_item speichert den kaufzeitbezogenen Snapshot. Änderungen an SKU, Titel, Preis oder Steuer eines Produkts dürfen bestehende Bestellpositionen nicht nachträglich verändern. Statusänderungen werden in shop_order_history nachvollziehbar festgehalten.
Preis, Steuer, Versand und Bestand
- Währung und Brutto-/Nettoanzeige kommen aus der Shopkonfiguration.
- Steuerklassen werden zentral konfiguriert und einem Produkt bzw. Default zugeordnet.
- Channelpreise können den internen Preis überschreiben; der definierte Vererbungswert verwendet wieder den Produkt-/Gruppenpreis.
- Versandgruppen bestimmen Lieferzeit, Kosten und Freigrenzen.
- Bei aktivem Bestand werden Verfügbarkeit und Mengen serverseitig geprüft.
- Digitale Produkte können einen eigenen Liefer-/Versandweg verwenden.
Rundung und Summenbildung gehören in die Fachlogik. Templates formatieren nur bereits berechnete Werte.
Modulaufteilung
dbxShop ist bewusst Frontend und verwendet das aktive Frontend-Design. dbxShop_admin besitzt das Suffix _admin und wird fuer Administratoren vom Design-Router auf default_design_admin aufgeloest. Aktuell ist das Admin-Design dbxapp.
Frontend-Routen
Aufrufmuster:
| dbx_run1 | Aufgabe |
|---|---|
| start, catalog | Katalog mit Suche, Gruppen- und Attributfiltern |
| product, detail | Produktdetail anhand SKU/Parameter |
| cart | Warenkorb anzeigen und Mengen bearbeiten |
| checkout | Kundendaten, Zahlungsart und Zustimmung erfassen |
| paypal_start | PayPal-Ablauf aus dem Checkout starten |
| paypal_return | PayPal-Rueckkehr erfassen und Zahlung verbuchen |
| paypal_cancel | abgebrochene PayPal-Zahlung behandeln |
| amazon_pay_return | Amazon-Pay-Rueckkehr verarbeiten |
| amazon_pay_cancel | abgebrochene Amazon-Pay-Zahlung behandeln |
| order, orders | eigene bzw. zuletzt erzeugte Bestellungen anzeigen |
| invoice_pdf | zugreifbare Rechnung als PDF ausgeben |
| channel_webhook | externe Bestell-/Channel-Rueckmeldung annehmen |
| legal, terms | CMS-Rechtstexte des Shops ausgeben |
| return, returns, withdrawal | Widerrufsseite und Formular ausgeben |
Beispiel fuer eine CMS- oder Template-Inclusion:
Admin-Routen
Aufrufmuster:
| dbx_run1 | Aufgabe |
|---|---|
| dashboard, start | Kennzahlen und Schnellzugriffe |
| install | DD-Schema, Defaults und Testgrundlage sicherstellen |
| products | Artikelliste, Auswahl- und Massenaktionen |
| product_edit | Artikel bearbeiten oder neu anlegen |
| product_tree_move | Artikelgruppe im Baum verschieben |
| product_channel_mapping | Channel-spezifische Artikeldaten pflegen |
| products_help | kontextbezogene Produkthilfe |
| groups | hierarchische Artikelgruppen verwalten |
| attributes | Attributdefinitionen verwalten |
| product_attributes | Attributwerte eines Artikels pflegen |
| shipping_groups | Versandarten und Kosten verwalten |
| channel_groups | Vertriebsszenarien aus Channels bilden |
| channels | interne und externe Verkaufskanaele konfigurieren |
| media | Shop-Medien anzeigen und hochladen |
| assign_media | Medien Artikeln oder Gruppen zuordnen |
| orders | Bestellreport mit Filtern und Aktionen |
| order_detail | Status, Zahlung, Versand, Tracking und Notiz pflegen |
| order_invoice | Rechnung als HTML anzeigen |
| order_invoice_pdf | Rechnungs-PDF erzeugen/oeffnen |
| legal | Rechtstexte im CMS pflegen |
| returns | Widerrufe administrieren |
| settings | Shop-, Steuer-, Zahlungs-, Mail- und Versandeinstellungen |
| payment_test | konfigurierte Zahlungsanbieter pruefen |
Der Modulzugriff ist ueber dbxShop_admin/cfg/config.php auf die Gruppe admin beschraenkt. Fachaktionen duerfen diese Modulberechtigung nicht durch direkte, ungeschuetzte Hilfsrouten umgehen.
Datenmodell
Alle Shop-DDs verwenden derzeit den Server dbxShop|dbxShop.db3. Jede Tabelle besitzt die Primaer-ID id. Die physischen Tabellen werden aus den DD-Dateien synchronisiert und sollen nicht parallel als handgeschriebenes SQL-Schema gepflegt werden.
Artikel und Darstellung
| DD | Tabelle | Zweck |
|---|---|---|
| shopProduct | shop_product | SKU, Slug, Titel, Typ, Preis, Steuer, Versand, Bestand, Aktivstatus |
| shopProductGroup | shop_product_group | hierarchische Gruppen, Steuer-/Versanddefaults, Karten-, Detail- und Gallery-Templates |
| shopProductGroupMap | shop_product_group_map | Artikel-zu-Gruppe, einschliesslich Primaergruppe |
| shopProductImage | shop_product_image | CMS-Medium oder Bildpfad fuer Artikel/Gruppe |
| shopAttributeDefinition | shop_attribute_definition | gruppenbezogene Text-, Auswahl- oder Zahlenattribute |
| shopProductAttributeValue | shop_product_attribute_value | konkrete Attributwerte eines Artikels |
Die Artikelgruppe kann Darstellungsvorgaben erben lassen, zum Beispiel card_template, detail_template, gallery_template, Bildanzahl, Bildmodus, Overflow und Klickverhalten. Fachliche Artikelwerte bleiben im Artikel; die Gruppe stellt Defaults und Kategorisierung bereit.
Versand und Channels
| DD | Tabelle | Zweck |
|---|---|---|
| shopShippingGroup | shop_shipping_group | Versandweg, Lieferzeit, Kosten und Freigrenze |
| shopProductShippingGroupMap | shop_product_shipping_group_map | Artikel-zu-Versandgruppe |
| shopChannel | shop_channel | Plattform, Verbindung, Zugang, Export/Import und Teststatus |
| shopProductChannel | shop_product_channel | Aktivierung, Channel-SKU, Preis-/Versandoverride und Exportstatus |
| shopChannelGroup | shop_channel_group | wiederverwendbare Gruppe von Verkaufskanaelen |
| shopChannelGroupChannel | shop_channel_group_channel | Channels innerhalb einer Channel-Gruppe |
| shopProductChannelGroupMap | shop_product_channel_group_map | Artikel-zu-Channel-Gruppe |
Direkte Channel-Zuordnungen und geerbte Zuordnungen ueber Channel-Gruppen werden gemeinsam aufgeloest. Ein Channel-spezifischer Preis von -1 bedeutet sinngemaess, dass der Artikel- bzw. Gruppenwert verwendet wird.
Bestellung und Widerruf
| DD | Tabelle | Zweck |
|---|---|---|
| shopOrder | shop_order | Kunde, Summe, Channel, Zahlung, Rechnung, Bestand, Versand und Rechtstext-Snapshots |
| shopOrderItem | shop_order_item | unveraenderlicher Bestellpositions-Snapshot |
| shopOrderHistory | shop_order_history | Status- und Fachereignisse einer Bestellung |
| shopWithdrawal | shop_withdrawal | Widerruf mit Bezug zu Bestellung/Kunde und Adminstatus |
Bestellpositionen speichern SKU, Titel, Menge, Preis, Steuer und Versand zum Bestellzeitpunkt. Nachtraegliche Artikelaenderungen duerfen eine vorhandene Bestellung deshalb nicht rueckwirkend umschreiben.
Installation, DD-Sync und Testdaten
dbxShopRepository::install() synchronisiert die 17 Shop-DDs, legt Standard-Channels an und bereinigt bestimmte Zuordnungen. Die Synchronisation wird mit schema_sync_version begrenzt. Eine Aenderung an einem DD erfordert deshalb auch eine neue Schema-Versionskennung, wenn die automatische Synchronisation erneut laufen soll.
Wenn Artikel, Versandgruppen, Channel-Gruppen oder Bilder fehlen, ruft der aktuelle Shop seedDemoProducts() auf. Das Entwicklungsprojekt darf Testdaten enthalten. Die mitgelieferten Testdaten umfassen unter anderem Software- und Servicegruppen, Versandgruppen, Channel-Gruppen und Demoartikel.
Werkzeuge fuer gezielte Testdaten und Mockups liegen unter:
Katalog und Produktdarstellung
Der Katalog zeigt nur aktive Artikel, die dem internen Channel shop zugeordnet sind. Er unterstuetzt:
- Volltextsuche mit gewichteten Artikel-, Gruppen- und Attributwerten,
- hierarchische Artikelgruppen und Breadcrumbs,
- filterbare Attribute,
- gruppenspezifische Karten- und Detailtemplates,
- Artikel- und Gruppenbilder aus dem CMS-Medienbestand,
- Steuer-, Liefer- und Bestandsinformationen.
Vorhandene Templates sind unter anderem:
Neue Varianten werden als Shop-Templates ergaenzt und ueber die Gruppe ausgewaehlt. Der Service validiert den Template-Namen; ungepruefte Dateipfade aus Datenbankwerten sind nicht erlaubt.
Einheitliches Laden von Produktlisten
Produktlisten verwenden im Repository immer denselben einfachen Ablauf:
- Produktzeilen bzw. leichte Filterkandidaten laden.
- Beziehungen fuer die benoetigte Produktmenge gebuendelt ueber dbxDB und die vorhandenen DDs laden.
- Gruppen, Versand, Channels, Bilder und Attribute im Speicher per ID zuordnen.
- Nur die sichtbare Katalogseite vollstaendig darstellen.
products() fuer die Administration und productsByIds() fuer den oeffentlichen Report verwenden beide decorateProducts(). Die Methode bildet eine kurzlebige Datensicht nur fuer den aktuellen Aufruf. Sie ist kein prozess- oder requestuebergreifender Cache und benoetigt deshalb keine Invalidierung. Einzelabrufe wie productById() und productBySku() bleiben unveraendert kompatibel.
Ein allgemeiner Ergebnis-Cache wurde nicht in dbxDB eingebaut. Identische SQL-Texte koennten dort zwar wiederverwendet werden, produktbezogene Abfragen mit verschiedenen IDs blieben aber verschieden. Gleichzeitig muessten rohe Queries, direkte PDO-Schreibpfade, DDL, Transaktionen und externe Schreiber beruecksichtigt werden. Die Repository-Mengenabfrage beseitigt das N+1-Problem ohne diese Aktualitaets- und Invalidierungskomplexitaet.
Auch die Darstellung folgt dem Mengenprinzip. Der Service liest einmal pro Request die in einem Karten- oder Detailtemplate vorhandenen {replacement_namen} und erzeugt nur deren Werte. Eine Katalogkarte baut dadurch keine unsichtbare Detailgalerie, Attributtabelle, Versand-/Lageransicht oder dbxForm-Instanz mehr. Eigene Shop-Templates bleiben kompatibel: Sobald sie einen bekannten Platzhalter verwenden, wird dessen Wert weiterhin vollständig erzeugt. Der Cache enthält nur die Platzhalternamen der lokalen Template-Datei, keine Produkt-, Benutzer- oder Formulardaten.
Die Admin-Bildliste folgt demselben Vertrag. allImages() lädt alle benötigten Produkt- und Gruppentitel in höchstens zwei Mengenabfragen und ordnet sie per ID zu. Neue Adminlisten dürfen nicht innerhalb einer Ergebnis-Schleife select1() für reine Bezeichnungen aufrufen.
Warenkorb und Checkout
Der Warenkorb wird in der PHP-Session unter dbxShop_cart gefuehrt. Der Checkout erfasst Name, E-Mail, Telefon, Lieferadresse, Notiz und Zahlungsart. Rechtstexte und Widerrufsbelehrung muessen bestaetigt werden.
Ändernde Warenkorbaktionen bleiben POST-Aktionen im vorhandenen dbxReport-/dbxForm-Vertrag. remove und clear sind benannte Submit-Buttons; ajax.js übernimmt deren name/value zusätzlich zu den Formulardaten. Nach einem Bestätigungsdialog hält ein kurzlebiges Hidden-Feld den bestätigten name/value-Wert fest und der reguläre Formular-Submit entscheidet weiter zwischen AJAX und Browsernavigation. Dadurch funktionieren Entfernen und Leeren sowohl mit AJAX als auch beim nativen Formular-Fallback. Die vorhandene dbxForm-CSRF-Prüfung bleibt unverändert; ein separater dbx_token wurde dafür nicht eingeführt.
Der aktuelle Gesamtzähler steht am zurückgegebenen Warenkorb-Root in data-dbx-shop-cart-count. Das modulbezogene design/js/shop.js synchronisiert damit nach ajax:after alle Menü-Badges. Die dbxapp-Asset-Version 69 stellt sicher, dass Browser die korrigierten Kernel-Bibliotheken neu laden.
Der Ablauf ist:
- Warenkorbpositionen gegen aktuelle Produkte pruefen.
- Bestand pruefen, wenn stock_enabled aktiv ist.
- Kundendaten und Zahlungsart validieren.
- Rechtstexte und Widerruf als Snapshot speichern, wenn aktiviert.
- Bestellung und Positionen erzeugen.
- Bestand gegebenenfalls reservieren.
- Bei Offline-Zahlung Bestaetigungsseite und Mail ausgeben.
- Bei PayPal/Amazon Pay zum Provider wechseln und Rueckkehr verarbeiten.
- Bestell- und Zahlungsereignisse in der History protokollieren.
Gastbestellungen werden mit checkout_guest_allowed gesteuert. Die oeffentliche Anzeige einer Bestellung oder Rechnung muss weiterhin die im Service implementierte Zugriffspruefung benutzen; eine frei uebergebene ID allein ist keine Berechtigung.
Zahlungsarten
Aktuell unterstuetzt die Konfiguration:
| Zahlungsart | Aktivierung |
|---|---|
| Vorkasse/Ueberweisung | Schalter plus optionale Bankdaten und Anweisung |
| Rechnung | Schalter plus Rechnungshinweis |
| PayPal | Schalter, Modus, Client-ID und Client-Secret |
| Amazon Pay | Schalter, Modus, Region, Merchant-/Store-/Key-Daten und Private Key |
PayPal und Amazon Pay werden im Checkout erst angeboten, wenn die benoetigten Zugangsdaten vorhanden sind. Neue Provider gehoeren in eine eigene Adapterklasse; Secrets duerfen nicht in Templates, Logs oder Testausgaben geschrieben werden.
Rechtstexte, CMS und Widerruf
Der Shop stellt die benoetigten CMS-Seiten unter einem Shop-Ordner sicher. Rechtstexte und Widerrufsinhalt werden im CMS gepflegt, nicht dauerhaft als HTML im Shop-Template dupliziert. Beim Checkout koennen Snapshots in der Bestellung gespeichert werden, damit die zum Kaufzeitpunkt akzeptierte Fassung nachvollziehbar bleibt.
Widerrufe werden ueber das Frontendformular in shop_withdrawal gespeichert und im Admin-Modul bearbeitet. Kunden- und Admin-Mail koennen separat aktiviert werden.
Medien
Produktbilder referenzieren vorzugsweise zentrale CMS-Medien ueber media_id. Ein image_path bleibt als Fallback fuer vorhandene oder erzeugte Dateien moeglich. Ein Bild kann einem Artikel oder einer Artikelgruppe zugeordnet sein. Gruppenbilder dienen als Fallback und als visuelle Navigation im Katalog.
Der konfigurierbare CMS-Slot lautet standardmaessig shop. Medien duerfen nicht allein durch Dateinamen als vertrauenswuerdig behandelt werden; Uploadziel, Dateiname und Dateityp werden serverseitig begrenzt.
Channels und externe Plattformen
Standard-Channels sind:
dbxShopChannelConnector kapselt Verbindungstest, Payload-Normalisierung und Artikelexport. Plattformbezogene Implementierungen existieren fuer eBay, Amazon, mobile.de und Kleinanzeigen; zusaetzlich gibt es einen generischen Middleware-Weg. Der interne Channel shop benoetigt keinen externen Export.
Eine sichtbare Channel-Konfiguration bedeutet nicht automatisch, dass ein Produktivvertrag oder alle API-Berechtigungen vorhanden sind. Vor Livebetrieb muessen Zugangsdaten, API-Scopes, Marketplace-/Seller-Kontext, Policies, Webhook-Authentifizierung und Fehlerwiederholung geprueft werden.
Der Webhook-Endpunkt ist:
Webhook-Secrets und Provider-Signaturen sind Sicherheitsgrenzen. Ein neuer Importweg darf Bestellungen nicht ungeprueft aus beliebigem JSON erzeugen.
Einstellungen
Die Admin-Seite settings verwaltet unter anderem:
- Aktivstatus, Standard-Channel und Waehrung,
- Brutto-/Nettoanzeige und drei Steuerklassen,
- B2B-, Lager- und Channel-Schalter,
- Gastbestellung und Rechtstext-Snapshots,
- Kunden-/Admin-Mail und Absender,
- Vorkasse, Rechnung, PayPal und Amazon Pay,
- digitale Lieferung und pauschalen Versand,
- den CMS-Medienslot.
Die Konfiguration wird mit dbx()->get_config('dbxShop') gelesen und ueber die zentrale Konfigurationsschnittstelle gespeichert. Keine zweite JSON- oder ENV-Konfiguration fuer dieselben Werte einfuehren.
Reale Codewege
Repository statt DB-Zugriff aus dem Template
Der zweite Parameter von productBySku() verlangt hier ein aktives Produkt. Die Serviceklasse prüft zusätzlich Channel und Darstellungskontext. Ein Template erhält nur die fertigen Werte und generiert keine Shopabfrage.
Produkt an einen Channel exportieren
exportProductToChannel() lädt Channel, Produkt, Mapping und Connectorstatus über das Repository. Ein Admincontroller soll nicht selbst ein Providerpayload aus Request-Feldern zusammensetzen.
Bestellreport
Die Adminansicht übergibt diese Daten an dbxReport. Repository und Report haben unterschiedliche Aufgaben: das Repository kennt die Shopabfrage, dbxReport kennt Filterzustand, Pagination, Formatierung und Aktionen.
Zahlungsadapter
Provideradapter kapseln Authentifizierung, Request/Response und Testmodus. Der Service bleibt für lokalen Bestellzustand, Idempotenz, Rückkehr und Historie zuständig.
Erweiterungsszenarien
Neues Produktattribut
Wenn Redakteure ein zusätzliches Merkmal wie Material oder Vertragslaufzeit benötigen, wird meist keine neue Spalte in shop_product gebraucht. Eine Attributdefinition kann einer Gruppe zugeordnet, als filterbar markiert und pro Produkt befüllt werden.
Neue Zahlungsart
- Konfigurationsfelder und sichere Secret-Behandlung ergänzen.
- eigenen Adapter mit isConfigured, Start/Erstellung, Rückkehr/Bestätigung und Verbindungstest implementieren.
- Zahlungsart nur bei vollständiger Konfiguration im Checkout anbieten.
- lokale Order vor bzw. eindeutig zum Providerrequest referenzieren.
- wiederholte Rückkehr/Webhooks idempotent verarbeiten.
- History und Fehlermeldung ohne Secrets schreiben.
Neuer Verkaufskanal
- Channeltyp und Konfiguration definieren.
- dbxShopChannelConnector bzw. einen plattformspezifischen Adapter ergänzen.
- Produktmapping und erforderliche Policies/IDs pflegbar machen.
- Testverbindung ohne produktive Mutation bereitstellen.
- Exportstatus, externe IDs und Providerantwort speichern.
- Webhook authentifizieren und normalisieren.
- Fehlerwiederholung und Teilfehler fachlich festlegen.
Neue Darstellungsvariante
Eine neue Karten- oder Detailansicht entsteht als Shoptemplate und optionales CSS innerhalb des Shopdesigns. Die Gruppe wählt den erlaubten Template-Namen. Produktdaten, Preise und Rechte bleiben unverändert im Service/Repository.
Betrieb und Fehlersuche
- Dashboardzahlen zuerst gegen Repositoryabfragen und aktive Filter prüfen.
- Fehlende Produkte: Aktivstatus, internen Channel, Gruppe und Rechte prüfen.
- Falscher Preis: Produktwert, Gruppen-/Channeloverride, Steueranzeige und Währung getrennt prüfen.
- Checkoutfehler: Formularvalidierung, Bestand, Zustimmung und Provider- Konfiguration prüfen.
- Doppelbestellung: Providerreferenz, Rückkehr-Idempotenz und Webhook-Historie prüfen.
- Fehlendes Bild: shopProductImage, media_id, aktive dbxMedia-Datei und Gruppenfallback prüfen.
- Exportfehler: Channeltest, Mapping, externe Policies/Scopes und gespeicherte Connectorantwort prüfen; niemals Secrets in die UI kopieren.
Erweiterungsregeln
- Neue Tabellen zuerst als DD in dbxShop/dd modellieren.
- Jede Shop-Tabelle benoetigt id als Primaerschluessel mit Autoincrement- Semantik der jeweiligen Datenbank.
- Datenzugriff gehoert in dbxShopRepository, nicht in Templates.
- Frontendablauf gehoert in dbxShopService.
- Adminablauf gehoert in dbxShopAdmin und bleibt admin-geschuetzt.
- Neue Eingaben verwenden dbxForm und FD, neue Listen dbxReport.
- Preis-, Steuer-, Versand- und Bestellwerte werden serverseitig berechnet.
- IDs aus Request oder Session werden immer gegen Rechte und Datensatzbezug geprueft.
- Secrets werden nicht ausgegeben oder in Systemmeldungen protokolliert.
- Externe Calls erhalten Timeout, Fehlerbehandlung und nachvollziehbaren Status; sie duerfen lokale Bestellungen nicht inkonsistent hinterlassen.
Pruefliste
- DD-Sync laeuft auf einer leeren Entwicklungsdatenbank durch.
- Jede Tabelle besitzt id und eine funktionierende Autoincrement-ID.
- Demoartikel erscheinen im Katalog und lassen sich filtern.
- Warenkorb addiert, aendert und entfernt Positionen korrekt.
- Bestätigtes Einzel-Löschen und Leeren funktionieren per AJAX; der Menü-Badge zeigt danach unmittelbar die aktuelle Gesamtmenge.
- Checkout weist unvollstaendige Daten und fehlende Zustimmung ab.
- Offline-Zahlung erzeugt Bestellung und Positionen genau einmal.
- Provider-Rueckkehr ist wiederholbar bzw. erzeugt keine Doppelbestellung.
- Eigene Bestellungen und Rechnungen sind zugreifbar, fremde nicht.
- Adminreports, Formulare und Massenaktionen funktionieren.
- Rechtstexte, Widerruf, Medien und Mail-Schalter sind geprueft.
- Channel-Tests und Exporte zeigen Fehler, ohne Secrets auszugeben.
- dbxapp und flowers stellen den Shop lesbar und responsive dar.