$wsAccount module, you read the account and address data of the currently logged-in customer and display it in the template.
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 customer 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, the account queries return empty values. That is why almost every example on this page starts with an
isLoggedIn check.
Module overview
Example / excerpt of$wsAccount
"ƒ()" denotes a function (method).
Variables overview
Methods overview
Templates
The data of a logged-in customer can be loaded and displayed on any template. In the standard delivery shop, the templates for the customer account pages are located in theviews/account directory. They serve as a basis for displaying and editing customer data. However, you can also use this data in other templates. The prerequisite is that the customer is logged in (see Basic concept).
Variables
$wsAccount.isLoggedIn
Returns whether the user is logged in. This check stands at the beginning of almost every account evaluation, because all other variables only return meaningful values when the user is logged in.$wsAccount.email
Returns the email address of the customer account. At checkout, a customer can also order as a guest. In that case, no account email is available, 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 order process.
$wsAccount.id
Returns the user ID of the customer account. Use it to uniquely identify a customer, for example for tracking.$wsAccount.isAccountVerified
Returns whether the customer account has been verified. Evaluate this if certain features should only be unlocked after verification.$wsAccount.isAutoLoggedIn
Returns whether the user was logged in automatically (via “Stay signed in”). This is relevant because an automatic login can be restricted (seeisAutoLogInRestricted).
$wsAccount.isAutoLogInRestricted
Returns whether not all shop functions are available during an automatic login. Evaluate this before offering security-relevant actions (e.g. changing an address) to an automatically logged-in customer, since these may require a new sign-in.More on this in the configuration.
$wsAccount.autoLogInRestriction
Returns the status of the auto-login restriction as a string. More on this in the configuration.$wsAccount.lastLogin
Returns the date of the last login as a string.$wsAccount.isPasswordResetRequired
Returns whether the password must be reset. Evaluate this to guide the customer specifically to change their password.More on this in the configuration.
$wsAccount.customerData
Returns customer-specific fields as amap (e.g. label, type, and value). Use this variable to display additionally configured customer fields without having to know each field individually.More on this in the configuration.
$wsAccount.addressFields
Returns a list of all available address fields with their configuration. Each element is an object with the propertiesname (field name, e.g. firstName), label (configured label, may be empty), and dataId. This list can be used to build address forms dynamically from the configuration.
Each entry additionally contains the field nodeId, the ID of the configuration node, which can be used as a second parameter for $wsOptions.get(name, nodeId) (see Options).
$wsAccount.backInStockList
Returns the products for which the customer has requested a back-in-stock notification. Display the list in the customer account, for example, so that the customer can see and manage their pre-noted products.$wsAccount.pseudoCreditCards
Returns the stored credit cards in pseudonymized form. The pseudonymization is intentional, because full card data must not be displayed in the frontend for security and data protection reasons.$wsAccount.typeSeparation
Returns information about address type separation. Via this map, you can check whether billing and shipping addresses are managed separately and which restrictions apply.Properties of $wsAccount.typeSeparation
$wsAccount.defaultBillAddress
Returns the customer’s main billing address as an address map (includingid), provided one is marked as default. Use it when you specifically need the main billing address. The available properties correspond to those of $wsAccount.addresses.
$wsAccount.defaultDeliveryAddress
Returns the customer’s default shipping address as an address map (includingid), provided one is marked as default. Use it when you specifically need the default shipping address. The available properties correspond to those of $wsAccount.addresses.
$wsAccount.addresses
Returns the list of all stored addresses of the customer. Use it for an address book or when you want to iterate over all addresses.Each address from
$wsAccount.addresses (and also 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)
Returns 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 prefill fields with meaningful defaults. Signature$address.defaultValue(fieldName, addressType)
Returns 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 address. This is planned for a future version.Methods
$wsAccount.loginRequired()
Returns whether the user must be logged in for a specific action. Evaluate this before offering an action so that you guide a non-logged-in customer to the login beforehand, instead of letting them run into a rejected action. More on this in the configuration. Signature$wsAccount.loginRequired(actionName)
Returns 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 output the billing or shipping address chosen by the customer. Signature$wsAccount.loadAddress(addressId)
Returns map – the loaded address with the properties from $wsAccount.addresses.
Parameters
$wsCheckout.selectedBillAddress comes from the $wsCheckout module and returns the ID of the billing address chosen during the order process.$wsAccount.hasPaymentVault()
Checks whether the logged-in customer has a link to the payment provider of the specified payment method. Call the method on a page in the customer account to either show the existing link with an option to remove it, or to display the offer to link the account. The link is not assigned to the payment method itself, but to the payment provider and its merchant ID. Multiple payment methods that use the same payment provider with the same merchant ID therefore share the same link. Signature$wsAccount.hasPaymentVault(paymentId)
Returns bool – true if a link exists, false if none exists. null is returned if no check is possible, for example if no or an empty paymentID value was passed, if the paymentId is unknown, or if the payment method does not support linking at all.
Parameters
Example that manages the link in the customer account. The distinction using
== true or == false is deliberately chosen here so that the null case does not fall into either branch.
Without being logged in, the method returns
false, not null – therefore, first check $wsAccount.isLoggedIn before you conclude from false that the customer has not yet created a link.Within the order process, use $wsCheckout.hasPaymentVault() – this method checks without parameters against the payment method chosen in the checkout and always returns a boolean.
Actions
$wsAccount itself only reads data. Actions that change data (create, edit, or delete an address, change password or email) are documented separately: Actions → Account.
Examples
The following examples are ordered by use case: from the simple state check to a personal greeting to address resolution in the checkout. All examples require a logged-in customer and check for that at the beginning.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.Logged-in customers see the personal area, non-logged-in visitors see the login offer.
Personal greeting for a logged-in customer
The trigger is the login state. If a customer is logged in, address them with the first and last name from their billing address. Theif check on the address prevents empty greetings if no address has been stored yet.
Logged-in customers with a stored billing address are greeted by name.
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.
Logged-in customers receive a link that reliably points to the overview page.
Display the billing address
The trigger is the login state. You read the main billing address and display it with an edit link. The link passes the addressid so that the action edits the correct address.
The billing address is displayed and the edit link leads to the correct address.
Address book: iterate over all addresses
The trigger is the login state. You iterate over all stored addresses and show an edit link for each address. The loop variable ($address) is used consistently so that the link targets exactly the address of the current iteration.
Each stored address is listed with an edit link that redirects to the address overview page.
Further links
- Actions → Account - change addresses and account (create, edit, delete), because
$wsAccountitself only reads. - $wsCheckout - provides the address IDs chosen in the order process (
selectedBillAddress,selectedShippingAddress) and the guest email address used in the examples. - Configuration: Accounts / user accounts - controls auto-login, verification, and address fields that several variables refer to.
