> ## Documentation Index > Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt > Use this file to discover all available pages before exploring further. # FORM- (Formulare) > Die FORM-Tags setzen das Ziel eines Shop-Formulars und schleusen dabei Sitzungskontext und CSRF-Token als versteckte Felder ein. Übersicht aller Formulare nach Bereichen. Jedes Formular, mit dem ein Besucher etwas an den Shop schickt, braucht ein Ziel. Dieses Ziel liefern die `FORM-`Tags. Für jede Funktion des Shopsystems gibt es genau ein Tag, und es steht immer im `action`-Attribut des `form`-Elements. Ein `FORM-`Tag ist dabei mehr als eine Adresse. Es tut zwei Dinge gleichzeitig, und das zweite ist der Grund, warum es genau an dieser Stelle stehen muss. Wegweiser: [Template-Sprache im Überblick](https://dokumentation.websale.de/v8s/grundlagen-zu-tags.md) · Referenz: Tag-Arten ## Wie ein FORM-Tag arbeitet Erstens gibt das Tag an der Stelle, an der es steht, die Ziel-Adresse aus. Diese Adresse enthält bereits den Zustand, in den das Shopsystem nach dem Absenden wechseln soll. Zweitens merkt sich das Shopsystem, dass es beim nächsten `>` im Template zusätzliche Felder einfügen muss. Beim `>`, das das `form`-Element abschließt, hängt es deshalb versteckte Eingabefelder an: * `Ctx` mit dem Sitzungskontext, also dem, was das Shopsystem über den aktuellen Besucher und seinen Stand im Shop weiß * bei allen sicherheitsrelevanten Formularen zusätzlich ein CSRF-Token * je nach Formular weitere Felder, beispielsweise die Nummer der bearbeiteten Lieferadresse bei `FORM-DelivAddrManage` Im fertigen HTML sieht das so aus: ```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
...
``` > [!WARNING] > > Aus diesem Einfügemechanismus folgt die wichtigste Regel für alle `FORM-`Tags: Das Tag gehört in das `action`-Attribut seines eigenen `form`-Elements und nirgendwo sonst. Steht es in einem `a`-Element, in einem JavaScript-Block oder in einer Variablen, landen die versteckten Felder hinter dem nächstbesten `>` und damit an einer Stelle, an der sie nichts bewirken. Das Formular wird dann ohne Sitzungskontext abgeschickt, und der Besucher landet auf der Startseite oder bekommt eine Fehlermeldung. > > Die versteckten Felder lassen sich nicht von Hand nachbauen. Sowohl der Kontext als auch das CSRF-Token werden pro Seitenaufruf erzeugt. Ein Formular ohne gültiges Token weist das Shopsystem ab. Die Schreibweise des Tagnamens ist ohne Bedeutung. `~FORM-Basket~` und `~Form-Basket~` liefern dasselbe. Einheitlich zu schreiben hilft trotzdem beim Durchsuchen der Templates. ## Das Grundmuster Alle `FORM-`Tags folgen demselben Muster. ```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
... Ihre Eingabefelder ...
``` Geben Sie `method="post"` an. Die Formulare des Shopsystems übertragen teils umfangreiche Daten, und der Sitzungskontext im Feld `Ctx` ist für eine Adresszeile zu lang. > [!WARNING] > > Ein `FORM-`Tag ist immer ein Einzel-Tag. Als Klammerung oder als Schleife lässt sich keines der Tags verwenden. ## Bestellablauf | Tag | Formular für | Gehört auf | | - | - | - | | `FORM-Product` | die Produktausgabe mit Menge und Varianten | innerhalb von `PR-Data`, `@PR-Data` oder `PR-AdvData()` | | `FORM-Basket` | den Warenkorb | Warenkorbseite `ws_basket.htm` | | `FORM-Addr` | die Abfrage der Rechnungs- und Lieferadresse | Template für die Adressabfrage im Bestellablauf | | `FORM-DelivAddr` | die Abfrage einer abweichenden Lieferadresse | Template für die Lieferadressabfrage | | `FORM-PayDeliv` | die Auswahl von Zahlungs- und Versandart | Zahlungs- und Versandartenseite `ws_pay_deliv.htm` | | `FORM-PlaceOrder` | die Bestellübersicht mit dem Absenden der Bestellung | Bestellübersichtsseite `ws_place_order.htm` | | `FORM-DirectOrder` | die Direktbestellung | Direktbestellungsformular `ws_direct_order.htm` | | `FORM-FastOrderConfiguration` | die Einrichtung der Schnellbestellung | Template zur Konfiguration der Schnellbestellung | | `FORM-BonusPoints` | die Eingabe einzulösender Bonuspunkte | alle Templates | | `FORM-AltCurrency` | die Auswahlliste der alternativen Währung | Produktdetailansicht `ws_product.htm`, Warenkorbseite `ws_basket.htm` | | `FORM-MDM` | die Auswahl und Pflege mehrerer Lieferadressen | Template für mehrere Lieferadressen, beispielsweise `ws_multidelivery_manage.htm` | `FORM-AltCurrency` brauchen Sie nur, wenn die Währungsauswahl außerhalb der Formulare `FORM-Product` und `FORM-Basket` steht. Liegt sie innerhalb, wird sie mit deren Formular abgeschickt. `FORM-DelivAddr` entfällt, wenn Sie Rechnungs- und Lieferadresse in einem Schritt auf einer Seite abfragen. Dann trägt `FORM-Addr` beide Adressblöcke. > [!WARNING] > > `FORM-AddrManage` fällt außerhalb der Kundenkonto-Seite auf dasselbe Ziel zurück wie `FORM-Addr`. Die beiden Tags sind deshalb nur im Kundenkonto wirklich verschieden. Verwenden Sie trotzdem das jeweils passende Tag, damit die Absicht im Template erkennbar bleibt. ## Kundenkonto und Kundendaten | Tag | Formular für | Gehört auf | | - | - | - | | `FORM-UserAccount` | das kundenspezifische Shop-Timeout | Templates der Kundenkonto-Seite | | `FORM-AddrManage` | die Verwaltung der Rechnungsadresse | Template für die Rechnungsadressverwaltung | | `FORM-DelivAddrManage` | die Verwaltung der Lieferadressen | Template für die Lieferadressverwaltung | | `FORM-DelivAddrSearch` | die Volltextsuche in den Lieferadressen | innerhalb der Klammerung `D-Overview` | | `FORM-BankManage` | die Eingabe einer Bankverbindung | `ws_bank_manage.htm` | | `FORM-BankSearch` | die Volltextsuche in den Bankdaten | innerhalb der Klammerung `BANK-Overview` | | `FORM-CCardSearch` | die Volltextsuche in den Kreditkartendaten | innerhalb der Klammerung `CC-Overview` | | `FORM-OrderHistory` | die Bestellhistorie | Template für die Bestellhistorie | | `FORM-Subscription` | die Verwaltung abonnierter Produkte | Abo-Verwaltung `ws_subscription_manage.htm` | | `FORM-UserSearch` | die Kundensuche der SuperUser-Funktion | Template für die Kundensuche | | `FORM-SendUploadLink` | das Versenden eines gesicherten Upload-Links | alle Templates, solange der Kunde angemeldet ist | Die drei Suchformulare `FORM-DelivAddrSearch`, `FORM-BankSearch` und `FORM-CCardSearch` müssen innerhalb der jeweiligen Übersichts-Klammerung stehen. Außerhalb fehlt dem Shopsystem der Bezug darauf, in welchem Datenbestand gesucht werden soll. ## Anmeldung und Passwort | Tag | Formular für | Gehört auf | | - | - | - | | `FORM-CombinedLogin` | die kombinierte Anmeldung aus Bestandskunde, Neukunde und Gastbestellung | Loginseite `ws_login.htm`, Bereich `LoginUser` | | `FORM-LoginNewUser` | die Neukunden-Anmeldung | Anmelde-Template, Bereich Neukunden-Anmeldung | | `FORM-LoginStart` | die Anmeldung vor Eintritt in einen geschlossenen Shop | Start-Anmelde-Template | | `FORM-QuickLogin` | die Schnellanmeldung für Bestandskunden | alle Templates | | `FORM-ReauthUser` | die erneute Passworteingabe bei dauerhaftem Login | alle Templates | | `FORM-ChangeEmail` | das Ändern der E-Mail-Adresse | Anmelde-Template, Bereich E-Mail-Adresse ändern | | `FORM-ChangePW` | das Ändern des Passworts | Anmelde-Template, Bereich Passwort ändern | | `FORM-RequestPW` | das Anfordern von Passwort oder Authentifizierungs-Link | Anmelde-Template, Bereich Passwort anfordern | | `FORM-RequestPWStart` | dasselbe im geschlossenen Shop | Start-Anmelde-Template | | `FORM-SetPassword` | das Neusetzen des Passworts | Anmelde-Template, Bereich Passwort setzen | | `FORM-SetPasswordStart` | dasselbe im geschlossenen Shop | Start-Anmelde-Template | | `FORM-ForceSetEmail` | das Nachtragen einer fehlenden E-Mail-Adresse nach der Anmeldung | Login-Template | | `FORM-CreateAccountAfterGuestOrder` | das Anlegen eines Kundenkontos nach einer Gastbestellung | Loginseite `ws_login.htm`, Bestelleingangsbestätigung `ws_confirm.htm` | | `FORM-ExternLogin_facebook_connect` | das Verbinden des Kundenkontos mit Facebook | Loginseite `ws_login.htm` | Bei `FORM-ReauthUser` findet anders als bei den übrigen Anmeldeformularen keine Prüfung der E-Mail-Adresse statt. Der Besucher gibt nur sein Passwort erneut ein, weil er bereits erkannt ist. > [!WARNING] > > Alle Anmeldeformulare führen auf denselben Zustand des Shopsystems und unterscheiden sich nur durch einen internen Befehlscode. Ein vertauschtes Tag erzeugt deshalb keine Fehlermeldung, sondern führt eine andere Funktion aus. Prüfen Sie beim Aufbau der Loginseite jedes Formular einzeln durch. ## Katalog, Suche und Produkt | Tag | Formular für | Gehört auf | | - | - | - | | `FORM-Search` | die Suche samt erweiterter Suche | alle Templates | | `FORM-QuickSearch` | die Schnellsuche | alle Templates | | `FORM-CatFilter` | die Auswahl der Filter auf Kategorieebene | Kategorieansicht | | `FORM-CatSort` | die Auswahl der Sortierung auf Kategorieebene | Kategorieansicht | | `FORM-ProductSort` | die Sortierung aller Produkte einer Kategorie | alle Templates mit Kategorien oder Suchergebnissen | | `FORM-ProductRecmd` | die Weiterempfehlung eines Produkts | Template "Produkt weiterempfehlen" | | `FORM-InventoryRegister` | die Benachrichtigung bei Wiederverfügbarkeit | Template mit dem Benachrichtigungsformular | `FORM-ProductSort` wählt sein Ziel selbst, je nachdem ob es auf einer Kategorieseite, auf der Merkliste oder auf einem anderen Template steht. Sie müssen dafür nichts angeben. ## Formulare für beliebige Templates Zwei Tags nehmen das Ziel als Parameter entgegen, statt es fest vorzugeben. Sie brauchen sie, wenn ein externes Formularprogramm über `WS-ExternInclude` eingebunden ist und nach dem Absenden wieder ein bestimmtes Shop-Template erscheinen soll. | Tag | Übertragung | | - | - | | `FORM-Template(