Customer, login and account - WEBSALE Dokumentation

Almost all tags on this page build form fields. That sounds monotonous, but it is the reason why they are so easy to learn: they follow the same three-part pattern almost without exception. Once you have understood it, you can write any field on this page without reading the individual description. That is why this pattern comes first. It is followed by the forms built from it, from the simple login through the combined login in the order process to the confirmation of the email address. At the end are the links that lead from the shop into the customer account. Reference: The introduction to the prefix WS- and the overview of the eight pages are on Shop, page and technology

The three-part pattern

Almost every input field comes with three tags.

Suffix	Returns	Belongs in
none	the value entered so far	the `value` attribute
`_input`	the HTML name of the field	the `name` attribute
`_error`	the error style suffix	the `class` attribute

<input type="text"
       name="~WS-Email_input~"
       value="~WS-Email~"
       class="eingabe~WS-Email_error~">

As a single tag, the suffix _error returns the string _error and nothing else. Append it to a class name, and the class is called eingabe_error in case of an error and eingabe otherwise. This lets you design the error display entirely via CSS, without a second area tag in the template.

Every _error tag also works as an area tag, which applies when the input is incorrect. This is the way to show an error message in words next to the field.

{WS-Email_error}
   <p class="fehler">Bitte geben Sie eine gültige E-Mail-Adresse ein.</p>
{/WS-Email_error}

The value tags return the most recently entered value so that the buyer does not have to retype everything after an error. This also applies to password fields. For a password field, consider whether you really want to write the value back, or whether an empty field is the better choice.

The same fields serve different purposes depending on the process. This is the most common stumbling block on the login template.

Tag	When logging in	When changing
`WS-Email`	the email address of the existing customer	the previous email address
`WS-NewEmail`	the email address of the new customer	the new email address
`WS-EmailAgain`	–	the repetition of the new email address
`WS-PW`	the password of the existing customer	the previous password
`WS-NewPW`	the password of the new customer	the new password
`WS-PWAgain`	the repetition for the new customer	the repetition of the new password
`WS-UserID`	the user ID, if the shop works with one	–

<form action="~FORM-LoginKnownUser~" method="post">
   <input type="text"
          name="~WS-Email_input~"
          value="~WS-Email~"
          class="eingabe~WS-Email_error~">

   <input type="password"
          name="~WS-PW_input~"
          maxlength="64"
          class="eingabe~WS-PW_error~">

   <input type="submit" value="Anmelden">
</form>

The example on the previous page for WS-PW shows an input element with type="text". A password field must have type="password", otherwise the password is visible on the screen. The examples for WS-NewPW and WS-PWAgain do it correctly. The corrected version is shown above.

The difference between WS-Email and WS-NewEmail is not old versus new, but existing customer versus new customer. On a template that covers both cases, you need both fields, and they must not carry the same name attribute.

WS-UserID belongs to shops in which the buyer does not log in with their email address but with an assigned ID. This is common above all in the B2B area. In a shop without this login type, the three tags simply remain unused.

The password strength indicator

<body>
   ~WS-SecureLoginConfigurationJS~
   ...
</body>

WS-SecureLoginConfigurationJS outputs the content of the secure login section of the shop configuration as a script in the page. This tells the password strength indicator in the browser which rules apply to a valid password. Without this tag, the indicator cannot check anything.

The tag belongs exclusively on the templates on which the buyer sets a new password, that is, on registration and on password change. It has no place on the ordinary login page.

Forgotten password

<form action="~FORM-RequestPW~" method="post">
   <input type="text" name="~WS-Email_input~" value="~WS-Email~">
   ~WS-PWRequestZip~
   <input type="submit" value="Passwort zusenden">
</form>

WS-PWRequestZip generates a ready-made input field for the postal code. You only write the tag, not the surrounding input element. The additional query prevents someone from requesting a password using only a guessed email address.

WS-RequestPWLink generates the link to the login page for this purpose. It behaves like WS-LoginLink, but does not tie the process to the order process. The tag exists in the shop system but is not described in the previous documentation.

Staying logged in

A buyer who has to type their password on every visit comes back less often. Two checkboxes offer them the option to stay logged in, and they differ in one important point.

Tag	Automatic login	Before critical actions
`WS-StaySignedIn_input`	yes	password must be re-entered
`WS-StayFullySignedIn_input`	yes	no re-entry needed

<form action="~FORM-QuickLogin~" method="post">
   ...
   <label>
      <input type="checkbox" name="~WS-StaySignedIn_input~">
      Angemeldet bleiben
   </label>
</form>

Both tags must be placed inside the login form, that is, inside FORM-LoginNewUser, FORM-LoginStart, FORM-QuickLogin, FORM-CombinedLogin or another login form. Outside it, they do generate a field name, but it is never submitted.

Only offer WS-StayFullySignedIn_input if you know that buyers shop on private devices. In a shop that is also used on shared computers, WS-StaySignedIn_input is the right choice, because there the password prompt before critical actions protects the account.

Re-authentication before critical actions

{WS-UserRequiresReAuthForCritAction}
   <p>Bitte bestätigen Sie zur Sicherheit noch einmal Ihr Passwort.</p>
   <form action="~FORM-ReauthUser~" method="post">
      <input type="password" name="~WS-PW_input~" class="eingabe~WS-PW_error~">
      <input type="submit" value="Bestätigen">
   </form>
{/WS-UserRequiresReAuthForCritAction}

{!WS-UserRequiresReAuthForCritAction}
   ... die eigentliche Seite ...
{/!WS-UserRequiresReAuthForCritAction}

WS-UserRequiresReAuthForCritAction applies when three things are true at the same time: the buyer was logged in automatically, they have not yet entered a password in this session, and the page meets one of the configured criteria for a critical action.

Put sensitive content such as address data, bank details or the order history in the negative area tag. Otherwise an automatically logged-in buyer sees it without having confirmed their password. The tag is permitted on all templates precisely so that you can use it wherever it is needed.

In the order process, the buyer is presented with three options: log in as an existing customer, register as a new customer, or order as a guest. Because this takes place in one form, there is a dedicated tag family with a regular structure. The selection consists of a name and, for each option, a value and a marker:

Tag	Returns
`WS-CombinedLogin_radioname`	the common HTML name of the radio buttons
`WS-CombinedLogin_radiovalue_knownUser`	the value for logging in as an existing customer
`WS-CombinedLogin_radiovalue_newUser`	the value for new registration
`WS-CombinedLogin_radiovalue_noLogin`	the value for ordering without an account
`WS-CombinedLogin_radioselected_knownUser`	`_checked` if this option is selected
`WS-CombinedLogin_radioselected_newUser`	the same for new registration
`WS-CombinedLogin_radioselected_noLogin`	the same for ordering without an account

The fields again follow the three-part pattern:

Field	Value	Name	Error
Email address	`WS-CombinedLogin_eMail`	`WS-CombinedLogin_eMail_input`	`WS-CombinedLogin_eMail_error`
Existing customer password	`WS-CombinedLogin_PWknownUser`	`WS-CombinedLogin_PWknownUser_input`	`WS-CombinedLogin_PWknownUser_error`
New customer password	`WS-CombinedLogin_PWnewUser`	`WS-CombinedLogin_PWnewUser_input`	`WS-CombinedLogin_PWnewUser_error`
New customer repetition	`WS-CombinedLogin_PWAgainnewUser`	`WS-CombinedLogin_PWAgainnewUser_input`	`WS-CombinedLogin_PWAgainnewUser_error`

<form action="~FORM-CombinedLogin~" method="post">
   <input type="text"
          name="~WS-CombinedLogin_eMail_input~"
          value="~WS-CombinedLogin_eMail~"
          class="eingabe~WS-CombinedLogin_eMail_error~">

   <label>
      <input type="radio"
             name="~WS-CombinedLogin_radioname~"
             value="~WS-CombinedLogin_radiovalue_knownUser~"
             ~WS-CombinedLogin_radioselected_knownUser~>
      Ich habe bereits ein Konto
   </label>
   {WS-CombinedLogin_radioselected_knownUser}
      <input type="password"
             name="~WS-CombinedLogin_PWknownUser_input~"
             class="eingabe~WS-CombinedLogin_PWknownUser_error~">
   {/WS-CombinedLogin_radioselected_knownUser}

   <label>
      <input type="radio"
             name="~WS-CombinedLogin_radioname~"
             value="~WS-CombinedLogin_radiovalue_newUser~"
             ~WS-CombinedLogin_radioselected_newUser~>
      Ich möchte ein Konto anlegen
   </label>

   <label>
      <input type="radio"
             name="~WS-CombinedLogin_radioname~"
             value="~WS-CombinedLogin_radiovalue_noLogin~"
             ~WS-CombinedLogin_radioselected_noLogin~>
      Ohne Konto bestellen
   </label>

   <input type="submit" value="Weiter">
</form>

The email address appears only once in the form, because it is needed in all three cases. Only the password fields differ.

As single tags, the _radioselected tags return _checked. They therefore go directly into the input element, without an attribute name before them. As area tags, they apply when the respective option is selected. This lets you show and hide the matching password field, as in the example.

All 18 tags of this family apply exclusively in the LoginUser area of the login template.

Registration after a guest order

If a buyer has ordered without an account, you can offer them immediately afterwards to create an account from the data they entered.

Tag	Returns
`WS-CreateAccountAfterGuestOrder_pw`	the entered password
`WS-CreateAccountAfterGuestOrder_pw_input`	the HTML name of the password field
`WS-CreateAccountAfterGuestOrder_pw_error`	the error style suffix
`WS-CreateAccountAfterGuestOrder_pwagain`	the repetition
`WS-CreateAccountAfterGuestOrder_pwagain_input`	its HTML name
`WS-CreateAccountAfterGuestOrder_pwagain_error`	its error style suffix
`WS-CreateAccountAfterGuestOrder_cancellink`	the link for canceling

{Type-CreateAccountAfterGuestOrder}
   {ST-CreateAccountAfterGuestOrder_method(websale)}
      <input type="password"
             name="~WS-CreateAccountAfterGuestOrder_pw_input~"
             class="eingabe~WS-CreateAccountAfterGuestOrder_pw_error~">
      <input type="password"
             name="~WS-CreateAccountAfterGuestOrder_pwagain_input~"
             class="eingabe~WS-CreateAccountAfterGuestOrder_pwagain_error~">

      <a href="~WS-CreateAccountAfterGuestOrder_cancellink~">Abbrechen</a>
      <input type="submit" name="~BT-CreateAccountAfterGuestOrder~" value="Konto anlegen">
   {/ST-CreateAccountAfterGuestOrder_method(websale)}
{/Type-CreateAccountAfterGuestOrder}

Only the password is still requested. Everything else, from the address to the email address, the buyer has already entered when ordering.

Offer the cancellation visibly. Without WS-CreateAccountAfterGuestOrder_cancellink, the buyer has no way out of the registration, and they have only just placed an order.

The tags apply on the login page and on the order receipt confirmation. The cancel link applies only on the login page.

If a buyer logs in via an external account, the shop system has to find out whether a customer account already belongs to it. For this, it requests the email address and, if an account exists, the associated password as well.

Tag	Returns
`WS-ExternLogin_facebook_connect_email`	the entered email address
`WS-ExternLogin_facebook_connect_email_input`	its HTML name
`WS-ExternLogin_facebook_connect_email_error`	its error style suffix
`WS-ExternLogin_facebook_Connect_pw_input`	the HTML name of the password field
`WS-ExternLogin_facebook_Connect_pw_error`	its error style suffix
`WS-ExternLogin_facebook_Connect_pw_needed`	applies when a password is needed

{Type-ExternLoginConnectAccounts}
   {ST-ExternLogin_facebook_connect}
      <form action="~FORM-ExternLogin_facebook_connect~" method="post" autocomplete="off">
         <input type="text"
                name="~WS-ExternLogin_facebook_connect_email_input~"
                value="~WS-ExternLogin_facebook_connect_email~"
                class="eingabe~WS-ExternLogin_facebook_connect_email_error~">

         {WS-ExternLogin_facebook_Connect_pw_needed}
            <p>Zu dieser Adresse gibt es bereits ein Konto. Bitte bestätigen Sie es.</p>
            <input type="password"
                   name="~WS-ExternLogin_facebook_Connect_pw_input~"
                   maxlength="64"
                   class="eingabe~WS-ExternLogin_facebook_Connect_pw_error~">
         {/WS-ExternLogin_facebook_Connect_pw_needed}

         <input type="submit" value="Verbinden">
      </form>
   {/ST-ExternLogin_facebook_connect}
{/Type-ExternLoginConnectAccounts}

Put the password field in {WS-ExternLogin_facebook_Connect_pw_needed}. If there is no account for the address yet, no password is needed, and a field displayed anyway only causes confusion.

Pay attention to upper and lower case: in the email branch it is connect_email, in the password branch Connect_pw with a capital C. This is how it is stored in the shop system.

Confirming the email address

Tag	Returns
`WS-DoubleOptInLink`	the activation link for the mandatory confirmation
`WS-VoluntaryDoubleOptInVerificationLink`	the link for the voluntary confirmation
`WS-RequestVoluntaryDoubleOptInEmailLink`	the link with which the buyer requests this email
`WS-RequestDeleteAccountDoubleOptInEmailLink`	the link with which they request the email for deleting their account
`WS-EmailVerified`	applies when the address is confirmed

In the email template is the link that confirms the address:

<p>
   Bitte bestätigen Sie Ihre E-Mail-Adresse:
   <a href="~WS-DoubleOptInLink~">Adresse bestätigen</a>
</p>

In the shop is the notice about the still pending status:

{ST-LoggedIn}
   {!WS-EmailVerified}
      <p>
         Ihre E-Mail-Adresse ist noch nicht bestätigt.
         <a href="~WS-RequestVoluntaryDoubleOptInEmailLink~">E-Mail erneut anfordern</a>
      </p>
   {/!WS-EmailVerified}
{/ST-LoggedIn}

WS-EmailVerified is only meaningful in the logged-in state. Put it in {ST-LoggedIn}, otherwise the negative area tag also applies to every visitor who is not logged in, and they get a notice about an account they do not even have.

WS-DoubleOptInLink and WS-VoluntaryDoubleOptInVerificationLink belong in the email templates defined in the sections NewCustomerDoubleOptInMail, ChangeEmailDoubleOptInMail and CustomerVoluntaryDoubleOptInMail of the shop configuration. The two request links belong in the shop.

WS-RequestDeleteAccountDoubleOptInEmailLink does not trigger a deletion, only the sending of the email. The deletion only happens when the buyer clicks the link in this email. Word the text in the template accordingly so that no one gets the wrong impression.

The registration code

{WS-LoginRegistrationCode}
   <p>Registrierungscode: ~WS-LoginRegistrationCode~</p>
{/WS-LoginRegistrationCode}

If the shop works with a registration code for new customers, WS-LoginRegistrationCode outputs the code and, as an area tag, checks whether one is present. WS-LoginRegistrationCode_error returns the error style suffix. Both tags exist in the shop system but are not described in the previous documentation.

If no one is logged in and no code is stored in the account, the tag falls back on the value stored in the shop configuration.

The customer account

Tag	Returns
`WS-LastLoginDate`	the date of the last login
`WS-LastLoginTime`	the associated time
`WS-UserCredit`	the balance of the customer account
`WS-OrderCount()`	the number of orders
`WS-SubAccountID`	the ID of the sub-account for multiple accounts

{WS-LastLoginDate}
   <p>Ihr letzter Besuch war am ~WS-LastLoginDate~ um ~WS-LastLoginTime~ Uhr.</p>
{/WS-LastLoginDate}

After a new registration, WS-LastLoginDate and WS-LastLoginTime return nothing on the first visit, because there is no earlier login yet. The value only appears from the second login onward. Without the area tag, the first visit would show a sentence with an empty gap on the page.

The number of orders

~WS-OrderCount~             <!-- alle Bestellungen im aktiven Subshop -->
~WS-OrderCount(1y,single)~  <!-- des letzten Jahres, aktiver Subshop -->
~WS-OrderCount(6m,all)~     <!-- der letzten 6 Monate, alle verbundenen Subshops -->

No.	Meaning	Values
1	Period	number plus `d` for days, `m` for months or `y` for years
2	Scope	`single` for the active subshop, `all` for all connected ones, default `single`

Without a parameter, the tag counts all orders in the active subshop. The area tag applies if there are any orders at all, and takes the same period into account.

The count is the fastest way to distinguish first-time buyers from regular customers without loading the order history. {!WS-OrderCount(1y)} applies to everyone who has not bought anything in the last year.

WS-SubAccountID exists in the shop system but is not described in the previous documentation. It outputs the ID of the sub-account and applies as an area tag when one is present. In a shop without multiple accounts, it stays silent.

Links into the customer account

Tag	Leads to
`WS-LoginLink`	the login page
`WS-LogoutLink`	logout
`WS-UserAccountLink`	the customer account overview
`WS-AddrManageLink`	the management of address data
`WS-BankManageLink`	the management of bank details
`WS-AutoLoginManageLink`	the management of saved logins
`WS-PrimePackagesManage`	the management of Prime packages
`WS-UserDownloadLink`	the buyer’s download area
`WS-SavedBasketsManageLink`	the management of saved baskets
`WS-PPCVaultManageLink`	the management of stored PayPal payment methods

{ST-LoggedIn}
   <a href="~WS-UserAccountLink~">Mein Konto</a>
   <a href="~WS-AddrManageLink~">Adressen</a>
   <a href="~WS-UserDownloadLink~">Meine Downloads</a>
   <a href="~WS-LogoutLink~">Abmelden</a>
{/ST-LoggedIn}

{!ST-LoggedIn}
   <a href="~WS-LoginLink~">Anmelden</a>
{/!ST-LoggedIn}

The example on the previous page for WS-UserDownloadLink writes <a href="~WS-UserDownloadLink~> without a closing quotation mark. This breaks the element in the browser. The corrected version is shown above.

Most of these links only make sense for a logged-in buyer. Put them in {ST-LoggedIn} instead of relying on the shop system sending a visitor who is not logged in to the login page anyway.

Three of these tags come with their own check and also work as area tags. WS-BankManageLink only applies if saving bank details is enabled. WS-SavedBasketsManageLink only applies when the buyer is logged in. WS-PPCVaultManageLink only applies if storing PayPal payment methods is allowed.

{WS-BankManageLink}
   <a href="~WS-BankManageLink~">Ihre gespeicherten Bankverbindungen</a>
{/WS-BankManageLink}

WS-SavedBasketsManageLink and WS-PPCVaultManageLink exist in the shop system but are not described in the previous documentation. Both generate a complete address via HTTPS.

WS-OSBLink is the odd one out: it does not lead into the customer account but into the shop operator’s online service area, and it belongs in the order receipt email to the shop operator. The address comes from the shop configuration.

The SuperUser customer search

<form action="~FORM-UserSearch~" method="post">
   <input type="text" name="~WS-UserSearch_Input~" value="~WS-UserSearch~">
   <select name="user_search_type">
      <option value="Name">Name</option>
      <option value="Email">E-Mail-Adresse</option>
      <option value="Number">Kundennummer</option>
   </select>
   <input type="submit" value="Suchen">
</form>

{CAT-AdvData($UserSearch,999)}
   <p>Die Suche ergab ~WS-UserSearchResults~ Treffer.</p>
   ...
{/CAT-AdvData($UserSearch,999)}

Tag	Returns
`WS-UserSearch_Input`	the HTML name of the search field
`WS-UserSearch`	the previous input
`WS-UserSearchType`	the selected search type
`WS-UserSearchResults`	the number of hits
`WS-SuperUserID`	the ID of the logged-in SuperUser

The selection list for the search type has the fixed name user_search_type. There is no dedicated tag for it. WS-UserSearchType only returns the selected value so that a JavaScript can mark the correct option again.

The page title of the previous documentation writes the tag as WS-SuperUser-ID with an additional hyphen. In the shop system and in the source’s own examples it is called WS-SuperUserID. Only this spelling works.

Reference: You build the hit list itself with the UL- tags, described on UL- (SuperUser)

The tags at a glance

Tag	Single tag	Area tag	Negative area tag	Loop tag
`WS-UserID`, `WS-Email`, `WS-NewEmail`, `WS-EmailAgain`	yes	–	–	–
`WS-PW`, `WS-NewPW`, `WS-PWAgain`	yes	–	–	–
all associated `_input` tags	yes	–	–	–
all associated `_error` tags	yes	yes	yes	–
`WS-PWRequestZip`	yes	–	–	–
`WS-RequestPWLink`	yes	–	–	–
`WS-SecureLoginConfigurationJS`	yes	–	–	–
`WS-StaySignedIn_input`	yes	–	–	–
`WS-StayFullySignedIn_input`	yes	–	–	–
`WS-UserRequiresReAuthForCritAction`	–	yes	yes	–
`WS-CombinedLogin_radioname`	yes	–	–	–
`WS-CombinedLogin_radiovalue_*`	yes	–	–	–
`WS-CombinedLogin_radioselected_*`	yes	yes	yes	–
`WS-CombinedLogin_eMail` and the three password fields	yes	yes	yes	–
`WS-CombinedLogin_*_input`	yes	–	–	–
`WS-CombinedLogin_*_error`	yes	yes	yes	–
`WS-CreateAccountAfterGuestOrder_pw` and `_pwagain`	yes	yes	yes	–
`WS-CreateAccountAfterGuestOrder_*_input`	yes	–	–	–
`WS-CreateAccountAfterGuestOrder_*_error`	yes	yes	yes	–
`WS-CreateAccountAfterGuestOrder_cancellink`	yes	–	–	–
`WS-ExternLogin_facebook_connect_email`	yes	yes	yes	–
`WS-ExternLogin_facebook_connect_email_input`	yes	–	–	–
`WS-ExternLogin_facebook_connect_email_error`	yes	yes	yes	–
`WS-ExternLogin_facebook_Connect_pw_input`	yes	–	–	–
`WS-ExternLogin_facebook_Connect_pw_error`	yes	yes	yes	–
`WS-ExternLogin_facebook_Connect_pw_needed`	–	yes	yes	–
`WS-DoubleOptInLink`	yes	yes	yes	–
`WS-VoluntaryDoubleOptInVerificationLink`	yes	yes	yes	–
`WS-RequestVoluntaryDoubleOptInEmailLink`	yes	yes	yes	–
`WS-RequestDeleteAccountDoubleOptInEmailLink`	yes	–	–	–
`WS-EmailVerified`	–	yes	yes	–
`WS-LoginRegistrationCode`	yes	yes	yes	–
`WS-LoginRegistrationCode_error`	yes	yes	yes	–
`WS-LastLoginDate`, `WS-LastLoginTime`	yes	yes	yes	–
`WS-UserCredit`	yes	–	–	–
`WS-OrderCount()`	yes	yes	yes	–
`WS-SubAccountID`	yes	yes	yes	–
`WS-LoginLink`, `WS-LogoutLink`, `WS-UserAccountLink`	yes	–	–	–
`WS-AddrManageLink`, `WS-AutoLoginManageLink`, `WS-UserDownloadLink`	yes	–	–	–
`WS-OSBLink`	yes	–	–	–
`WS-BankManageLink`	yes	yes	yes	–
`WS-PrimePackagesManage`	yes	yes	yes	–
`WS-SavedBasketsManageLink`	yes	yes	yes	–
`WS-PPCVaultManageLink`	yes	yes	yes	–
`WS-UserSearch`, `WS-UserSearch_Input`, `WS-UserSearchType`, `WS-UserSearchResults`	yes	–	–	–
`WS-SuperUserID`	yes	yes	yes	–
`WS-AppLoginErrorCode`	yes	yes	yes	–

The login and registration fields apply on the login template, the CombinedLogin family there in the LoginUser area. WS-BankManageLink and WS-PrimePackagesManage apply on the customer account overview, WS-DoubleOptInLink and WS-VoluntaryDoubleOptInVerificationLink in the associated email templates, WS-OSBLink in the order receipt email to the shop operator, and the customer search tags on their template. All others are permitted on all templates.

Guide: Login and registration
Guide: Persistent login
Guide: Double opt-in
Guide: Forgotten password
Guide: SuperUser function
Reference: UL- (SuperUser)

​The three-part pattern

​Login and registration

​The password strength indicator

​Forgotten password

​Staying logged in

​Re-authentication before critical actions

​The combined login

​Registration after a guest order

​Login via an external account

​Confirming the email address

​The registration code

​The customer account

​The number of orders

​Links into the customer account

​The SuperUser customer search

​The tags at a glance

​Related topics

The three-part pattern

Login and registration

The password strength indicator

Forgotten password

Staying logged in

Re-authentication before critical actions

The combined login

Registration after a guest order

Login via an external account

Confirming the email address

The registration code

The customer account

The number of orders

Links into the customer account

The SuperUser customer search

The tags at a glance

Related topics