Zum Hauptinhalt springen
Diese Seite enthält ausführliche Template-Beispiele für das Abo-Modul. Sie ergänzen die Anleitung um eine vollständige Umsetzung, die Sie als Ausgangspunkt übernehmen können. Die gezeigte Lösung vermeidet Weiterleitungen auf ws_bank_manage.htm und ws_address_manage.htm. Der Käufer bleibt auf ws_product.htm beziehungsweise ws_subscription_manage.htm, Adresse und Bankverbindung bearbeitet er in Modal-Fenstern. Abhängige Varianten sind berücksichtigt.
Die Modal-Fenster sind mit Bootstrap 4 umgesetzt. Die Funktionen arbeiten auch mit anderen Bootstrap-Versionen zusammen.Die Beispiele setzen jQuery und die WEBSALE-Funktion ws_AJAXloadTemplate voraus. Letztere steckt im Modul zum Nachladen von Templates oder in der System- beziehungsweise Core-Bibliothek.
Wegweiser: Abo-Modul · Referenz: SUBS-Tags, WEBSALE JavaScript-Bibliothek
Die folgenden Listings sind Auszüge. Die drei Punkte am Anfang und am Ende stehen für den übrigen Inhalt des jeweiligen Templates, der unverändert bleibt.Alle Beschriftungen und Meldungstexte sind Beispieltexte. Ersetzen Sie sie durch Ihre eigenen oder durch Textplatzhalter aus der shop.config.

Die fünf Templates im Überblick

Die Reihenfolge ist keine Empfehlung, sondern eine Abhängigkeit: Schritt 1 ruft die Templates aus den Schritten 2 bis 4 per AJAX nach. Bauen Sie deshalb zuerst Schritt 1 und ergänzen Sie die übrigen danach.

Schritt 1: Produktdetailansicht

Dieses Template trägt die Hauptlast. Es zeigt das Abo-Produkt, prüft über DC-FPAboOrderOk, ob alle Voraussetzungen erfüllt sind, und hält die drei Modal-Fenster für Anmeldung, Adresse und Bankverbindung bereit.
Der Schalter DC-FPAboOrderOk ist der Kern der Logik. Drei Prüfungen setzen ihn auf false: fehlende Rechnungsadresse, fehlende Bankverbindung und fehlende Intervallauswahl. Erst wenn alle drei bestanden sind, ist die Schaltfläche zum Abschluss nicht mehr deaktiviert.Wenn Sie weitere Voraussetzungen haben, ergänzen Sie einfach eine weitere Zeile nach demselben Muster.

Schritt 2: Anmeldung im Modal-Fenster

ws_login.htm liefert die Anmelde- und Registrierungsfelder, die Schritt 1 per AJAX in das Modal-Fenster holt. Der gesamte Abo-Teil steckt im One-Time-Parameter WS-OTP3(loginSubscription). Die negative Klammerung darüber sorgt dafür, dass der reguläre Seiteninhalt nicht mitgeliefert wird, wenn das Template als AJAX-Fragment angefordert wird. Innerhalb davon unterscheidet WS-OTP1(NewUserSubscription) zwischen Anmeldung eines bestehenden Kunden und Neuregistrierung. Beide Formulare verweisen über ws_AJAXloadTemplate aufeinander, sodass der Käufer im Modal-Fenster zwischen den beiden Ansichten wechseln kann, ohne die Produktseite zu verlassen.
Die drei DC-SPRegisterParams…_set-Zeilen merken sich die One-Time-Parameter in Session-Parametern. Nur dadurch findet der Käufer nach der Registrierung oder nach einer Bestätigungsmail wieder in den Abo-Kontext zurück.Die Links tragen zusätzlich otpsubscriptionprodindex und, bei abhängigen Varianten, otpsubscriptionvarindex. Damit weiß das Modal-Fenster nach dem Wechsel zwischen Anmeldung und Registrierung noch, um welches Produkt es ging.

Schritt 3: Rechnungsadresse im Modal-Fenster

ws_address_manage.htm wird für das Abo-Modul an zwei Stellen gebraucht. Der obere Block in ST-Ajax liefert die reine Adressanzeige, die Schritt 1 und Schritt 5 in ihren Container subscriptionAddress holen. Der untere Block liefert das Adressformular für das Modal-Fenster. Wieder trennt ein One-Time-Parameter die beiden Welten, diesmal WS-OTP3(updateAddressSubscription). Das normale Adressformular der Seite bleibt negativ geklammert erhalten, damit das Kundenkonto weiter wie gewohnt funktioniert.
Beide Formulare tragen dieselbe ID addressform. Das geht nur gut, weil die beiden Blöcke durch den One-Time-Parameter nie gleichzeitig ausgegeben werden. Wenn Sie die negative Klammerung entfernen, steht die ID zweimal im Dokument und das Speichern im Modal-Fenster greift auf das falsche Formular zu.

Schritt 4: Bankverbindung im Modal-Fenster

ws_bank_manage.htm ist das umfangreichste der vier nachgeladenen Templates, weil es drei Zustände abdecken muss: eine bereits gewählte Bankverbindung anzeigen, aus den vorhandenen Bankverbindungen auswählen, und eine Bankverbindung anlegen oder bearbeiten. Die gesamte Auswahl hängt an SUBS-FixedPaymentCodeUsed(4). Der Wert 4 ist der Zahlungsarten-Code für Lastschrift. Das Modul fragt damit ab, ob in der shop.config eine feste Zahlungsart für Abos eingestellt ist und ob es die Lastschrift ist. Nur dann braucht es überhaupt eine Bankverbindung.
Das Beispiel bindet ws-module-ajaxgeneric-1.8.5.js ein.BANK-SEPADirectMandateType(2) steht für ein wiederkehrendes SEPA-Mandat. Liegt eines vor, sind die Daten der Bankverbindung gesperrt und der Käufer legt stattdessen eine neue an.

Schritt 5: Abo-Übersicht im Kundenkonto

ws_subscription_manage.htm ist ein neues Template, das es in älteren Shops noch nicht gibt. Es zeigt alle Abonnements des Kunden und bietet je Abo Lieferintervall, Menge und die drei Schaltflächen zum Löschen, Pausieren und Aktivieren an. Lieferadresse und Bankverbindung stehen auch hier in Modal-Fenstern. Die beiden ws_AJAXloadTemplate-Aufrufe ganz am Ende füllen die Container beim Laden der Seite einmalig.
Die Preisprüfung im Listing ist ein nützliches Detail: PR-LoadData holt den heutigen Produktpreis, DC-FPCurrentPrice_set merkt ihn, und der Vergleich mit SUBS-Data_PR_Price zeigt dem Kunden eine Preisänderung gegenüber dem Preis bei Abo-Abschluss an.

Die Meldungscodes im Überblick

Das Listing aus Schritt 5 zeigt die Erfolgs- und Fehlermeldungen als nummerierte Abschnitte. ~MSG-Subscription_success~ und ~MSG-Subscription_error~ geben als einzelnes Tag den aktuellen Code aus. Als Abschnitt ohne Parameter sind sie wahr, sobald überhaupt ein Code gesetzt ist. Mit Parameter prüfen sie auf eine bestimmte Nummer. Die Codes 9, 10 und 11 fehlen im Beispiel-Listing. Wenn Sie es übernehmen, ergänzen Sie für diese drei eine Meldung, sonst bleibt die Seite im Fehlerfall stumm.
Oberhalb von 900 liegen technische Fehler, die der Kunde nicht beheben kann: 901 steht für ein nicht freigeschaltetes Feature, 902 bis 912 für Datenbankfehler. Codes ab 950 und ab 1000 entstehen, wenn der Shop einen Fehler nicht zuordnen kann, und werden zusätzlich als kritischer Fehler protokolliert.Fangen Sie diese Fälle mit {MSG-Subscription_error} ohne Parameter ab und zeigen Sie eine allgemeine Meldung an, damit der Kunde nicht vor einer leeren Seite steht.

Die Zustände eines Abonnements

~SUBS-Data_state_code~ gibt den Zustand als Zahl aus, die vier Abschnitts-Tags fragen ihn einzeln ab. Das Beispiel-Listing beschriftet SUBS-Data_state_isactive, SUBS-Data_state_isnew und SUBS-Data_state_istriggered alle drei mit “aktiv”. Für die reine Anzeige ist das in Ordnung, es verdeckt aber einen Unterschied: nur bei neuen Abonnements bietet SUBS-Buttonvalue_triggernewsubscriptions die Schaltfläche an, mit der der Kunde die erste Bestellung selbst auslöst.