$wsAccount - Account & address data
With the$wsAccount module, you read the account and address data of the currently logged-in customer and display them in the template.
This page is aimed at frontend developers who design customer account pages or personalized areas of the shop. It assumes that you are familiar with the structure of WEBSALE templates and the template syntax ({{ ... }}). If not, first read Introduction to templates, because the examples on this page use this syntax consistently.
This page is exclusively about reading and displaying existing account and address data. Everything that changes data (create, edit, or delete an address, change a password) is described under Actions → Account, because the triggering actions and their parameters are documented there.
Most values of
$wsAccount are only filled if the customer is logged in. Therefore, check with $wsAccount.isLoggedIn whether a customer is logged in before accessing them – otherwise you will read empty values and unintentionally display empty fields.Basic concept
Working with$wsAccount always follows the same flow: check the login state → read data → react.
Before you read customer data, you need to know whether a customer is logged in at all. Only the logged-in state fills the variables with values. Then you read the desired data (e.g. the display name or an address) and react to it, for example with a personal greeting or by displaying the address book.
When the data is available: If no customer is logged in, account variables return empty values. This is the reason why almost every example on this page starts with an isLoggedIn check – without it you would output empty or missing fields for non-logged-in visitors.
Time of execution: The template code is executed during page build, not during a later user action. So $wsAccount contains the account state at the time the page is generated. If a customer just logs in, their data is only available on the next page request.
Address model (applies to all address accesses)
A customer usually has more than one address. So that you can read out the correct address for the correct purpose,$wsAccount distinguishes several access paths:
addresses– the complete list of all stored addresses. Use this list when you display an address book or iterate over all addresses.defaultBillAddress– the main billing address. Use it when the billing address is specifically needed.defaultDeliveryAddress– the default shipping address. Use it when the shipping address is specifically needed.typeSeparation– information on whether billing and shipping addresses are managed separately. Evaluate this map before offering the customer to create a new billing address.
firstName, street, zip). These properties are described once centrally under Properties of $wsAccount.addresses so that they do not have to be repeated for each access path.
Module overview
Example / excerpt of$wsAccount
"ƒ()" denotes a function (method).
Variables overview
To be checked: The
mainAddress variable is used in some existing examples but does not appear in the observed JSON output above. Before mainAddress is documented, it must be checked against the code/actual behavior whether this variable still exists. The examples on this page therefore consistently use the fields defaultBillAddress, defaultDeliveryAddress, and addresses confirmed in the JSON output.
Address maps additionally provide two of their own methods:
customLabel() and defaultValue().
Templates
The data of a customer can – provided that they are logged in – be loaded and displayed in any.htm template.
In the standard delivery shop, the templates for the customer account pages are located in the views/account directory. They serve as the basis for displaying and editing customer data. However, you can also use the same data in other templates, for example for a personal greeting on the home page – the only prerequisite is that the customer is logged in (see Basic concept).
Variables
$wsAccount.isLoggedIn
Returns whether the user is logged in. This check is at the start of almost every account evaluation, because all other variables only return meaningful values in the logged-in state.$wsAccount.email
Returns the email address of the customer account. In the checkout, a customer can also order as a guest. In that case, there is no account email, but a guest email address from the checkout. The following example therefore covers both cases so that the appropriate address is always displayed:
$wsCheckout.guestMail comes from the $wsCheckout module and is only filled during the ordering process.
$wsAccount.id
Returns the user ID of the customer account. Use it to uniquely reference a customer, for example in links or tracking.$wsAccount.displayName
Returns the display name of the customer. Use it for a personal greeting without having to load a complete address.$wsAccount.isAccountVerified
Returns whether the customer account has been verified. Evaluate this if certain functions should only be unlocked after verification.$wsAccount.isAutoLoggedIn
Returns whether the user was logged in automatically (via “Stay logged in”). This is relevant because an automatic login can be restricted – seeisAutoLogInRestricted.
$wsAccount.isAutoLogInRestricted
Returns whether not all shop functions are available during the automatic login. Evaluate this before offering a customer who is logged in automatically security-relevant actions (e.g. address change) – these may require a renewed login. More information in the configuration.$wsAccount.autoLogInRestriction
Returns the status of the auto-login restriction as a string. More information in the configuration.$wsAccount.lastLogin
Returns the date of the last login. Use it, for example, for a notice “Your last login was on …”.$wsAccount.isPasswordResetRequired
Returns whether the password needs to be reset. Evaluate this to specifically guide the customer to change the password instead of letting them run into a blocked function. More information in the configuration.$wsAccount.customerData
Returns customer-specific fields (e.g. label, type, and value). Use this variable to display additionally configured customer fields without knowing each field individually. More information in the configuration.$wsAccount.addressFields
Returns a list of all available address fields with their configuration. Use it to build address forms dynamically from the configuration instead of hard-wiring fields.$wsAccount.backInStockList
Returns the products for which the customer has requested an availability notification. Display the list in the customer account so that the customer can see and manage their watched products.$wsAccount.pseudoCreditCards
Returns the stored credit cards in pseudonymized form. The pseudonymization is intentional: complete card data may not be available in the frontend for security and data protection reasons.$wsAccount.typeSeparation
Returns information about the address type separation. Via this map, you check whether billing and shipping addresses are managed separately and what restrictions apply. Evaluate it before offering the customer to create a new billing address – otherwise you offer an action that the shop would reject.Properties of $wsAccount.typeSeparation
$wsAccount.defaultBillAddress
Returns the customer’s main billing address as an address map (includingid), provided that one exists. Use it when the billing address is specifically needed. The available properties correspond to those of $wsAccount.addresses.
$wsAccount.defaultDeliveryAddress
Returns the customer’s default shipping address as an address map (includingid), provided that one exists. Use it when the shipping address is specifically needed. The available properties correspond to those of $wsAccount.addresses.
$wsAccount.addresses
Returns the list of all the customer’s stored addresses. Use it for an address book or when you want to iterate over all addresses.Each address from
$wsAccount.addresses (and likewise from defaultBillAddress, defaultDeliveryAddress, and loadAddress()) provides the following properties.Properties of $wsAccount.addresses
$address.customLabel()
Returns the custom label for a specific address field depending on the address type. Use the method to take form labels from the configuration instead of hard-coding them in the template. Signature$address.customLabel(fieldName, addressType)
Return value string – the configured label for the field.
Parameters
$address.defaultValue()
Returns the configured default value for a specific address field depending on the address type. Use the method to pre-populate fields with sensible defaults. Signature$address.defaultValue(fieldName, addressType)
Return value string – the configured default value for the field.
Parameters
Note: The methods
customLabel() and defaultValue() currently only take effect in the checkout once the customer has selected an address. In the customer account, they do not yet distinguish between shipping and billing addresses – this is planned for a future version.Methods
$wsAccount.loginRequired()
Returns whether the user has to be logged in for a specific action. Evaluate this before offering an action, so that you guide a customer who is not logged in to the login beforehand, instead of letting them run into a rejected action. More information in the configuration. Signature$wsAccount.loginRequired(actionName)
Return value bool – true if a login is required, otherwise false.
Parameters
$wsAccount.loadAddress()
Loads a single address by its ID and returns it as an address map. Use the method in the checkout to resolve the billing or shipping address selected by the customer. Signature$wsAccount.loadAddress(addressId)
Return value map – the loaded address with the properties from Properties of $wsAccount.addresses.
Parameters
$wsCheckout.selectedBillAddress comes from the $wsCheckout module and returns the ID of the billing address selected during the order process.
Actions
$wsAccount itself only reads data. Actions that change data (create, edit, or delete an address, change a password or email) are documented separately: Actions → Account.
Examples
The following examples are arranged by use case: from the simple state check, through the personal greeting, to address resolution in the checkout. All examples assume a logged-in customer and check this at the start.Check the login state and differentiate content
The trigger is the login state. Depending on whether a customer is logged in, you display different content – for example a personal greeting or a login form.Personal greeting of a logged-in customer
The trigger is the login state. If a customer is logged in, you address them with their first and last name from their billing address. Theif check on the address prevents empty greetings if no address has been stored yet.
Link to the customer account overview
The trigger is the login state. For logged-in customers, you generate a link to the overview page. The URL is built via$wsViews.viewUrl() so that the path to the template is resolved correctly instead of being hard-wired.
Display billing address
The trigger is the login state. You read out the main billing address and display it with an edit link. The link passes the addressid so that the action edits the correct address.
Address book: iterate over all addresses
The trigger is the login state. You iterate over all stored addresses and display an edit link per address. The loop variable ($address) is used consistently so that the link hits exactly the address of the current iteration.
Load addresses in the checkout
The trigger is the ordering process. During the checkout, $wsCheckout provides the IDs of the selected addresses. WithloadAddress(), you resolve these IDs into complete addresses, because in the checkout only the selection IDs are available, not the address data itself.
Logout link
The trigger is the login state. For logged-in customers, you generate a logout link via the logout action. After logging out, the customer is directed to the specified target page.
$wsActions.url() comes from the $wsActions module. The exact spelling of the action names (e.g. for password or email change) is documented under Actions → Account.
Related links
- Actions → Account – Change addresses and the account (create, edit, delete), because
$wsAccountitself only reads. - $wsCheckout – provides the address IDs selected during the order process (
selectedBillAddress,selectedShippingAddress) and the guest email address used in the examples. - wsActions – generate the template and action URLs used in the examples.
- Configuration: Accounts / customer accounts – controls auto-login, verification, and address fields referenced by several variables.
- Practical examples: customer account – continuous practical example for customer account pages.
The template code is executed during page build, not on click. A cookie is therefore not set at the moment of the click, but only when the click triggers a new request and the template is executed again as part of it. Therefore, always plan setting along a page request.
- $wsConsent – check the user’s consent before setting non-essential cookies.
