$wsCookie module, you read, set, update, and delete browser cookies directly in the template.
Cookies store information per visitor across multiple page views, for example a chosen display variant, a personal greeting, or a remembered consent. This page covers only the reading and writing of cookies themselves. How you check the user’s consent is described in $wsConsent.
Note: Setting cookies may require user consent depending on the type (technically necessary vs. marketing/tracking). Use $wsConsent.checkAllowed() to verify consent before setting non-essential cookies.
Basic concept
Cookies always follow the same flow: Set → Read → React.Before you can read a cookie, it must first be set. A cookie is always set by an event. Typical triggers are:
- a user action (clicking a toggle or link),
- a state (the customer logs in),
- a dependency (a specific customer data field is present),
- the entry path (access via a campaign link or referrer).
The template code is executed when the page is built, not when the user clicks. 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. Always plan the setting along a page view.
Naming scheme (applies to all methods)
The shop automatically renames its own cookies according to the schemewsvx_<shopId>_cookie<name>. setCookie("test", …) in the shop example becomes the cookie wsvx_example_cookietest in the browser. In the methods, you always work only with the short name (test); the shop adds the prefix itself. This avoids conflicts with other cookies.
Setting and reading use the same scheme. A cookie set with setCookie("test", …) can therefore be read again directly with getCookie("test"), without worrying about the long name.
Exception: externally set cookiesCookies that were not set by the shop (e.g. via custom JavaScript, a third-party tool, or a cookie banner) keep their original name. The automatic scheme would not match them. If you want to read such a cookie, pass the
keepNameAsIs: true option to getCookie so that the name is used unchanged. This option is not available for setting, updating, or deleting, because external cookies are usually managed by the tool that set them.
Module overview
Example / excerpt of$wsCookie
"ƒ()" indicates a function.
Methods at a glance
| Method | Return type | Description |
|---|---|---|
getCookie() | string | Reads the value of a cookie by its name. |
setCookie() | – | Sets a new cookie. |
updateCookie() | string | Updates the value of an existing cookie. |
deleteCookie() | – | Deletes a cookie by its name. |
Templates
All four methods are template functions and are available in every.htm template. The typical flow (Set → Read → React) is described in the Basic concept section.
Variables
No variables are available for$wsCookie.
Methods
$wsCookie.getCookie()
Reads the value of a cookie by its name. Signature$wsCookie.getCookie(name, [options])
Returnstring – value of the cookie. The value is empty if no cookie with this name exists.
Parameters
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
name | string | yes | – | Short name of the cookie, without prefix. |
options | map | no | – | keepNameAsIs (bool) – uses the name unchanged, without the automatic scheme. Required for externally set cookies (see Basic concept). |
$wsCookie.setCookie()
Sets a new cookie. Signature$wsCookie.setCookie(name, value, [age])
Return– (no return value) Parameters
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
name | string | yes | – | Short name of the cookie, without prefix. |
value | string, int, float, list, map, bool | yes | – | Value of the cookie. Complex values (list, map) are stored internally as JSON automatically. |
age | int | no | Session | Validity period in seconds. Without a value, a session cookie is set, which expires at the end of the browser session. Maximum 10 years. Example: 31536000 = 365 days. |
$wsCookie.updateCookie()
Updates the value of an existing cookie. Signature$wsCookie.updateCookie(name, value)
Returnstring – new value of the cookie.
Parameters
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
name | string | yes | – | Short name of the cookie, without prefix. |
value | string, int, float, list, map, bool | yes | – | New value of the cookie. |
$wsCookie.deleteCookie()
Deletes a cookie by its name. Internally, the lifetime is set to-1, which causes the browser to discard the cookie immediately.
Signature$wsCookie.deleteCookie(name)
Return– (no return value) Parameters
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
name | string | yes | – | Short name of the cookie, without prefix. |
Actions
No actions are available for$wsCookie.
Examples
The following examples are ordered from simple to more complex: from a state, through a user action and the entry path, to an externally set cookie.Personal greeting (WelcomeBack cookie)
The trigger here is the “login” state. When the customer opens the shop, they are greeted personally, even if they are not logged in, provided they have logged in at least once before. This preserves a personal touch without requiring the customer to stay logged in permanently. Step 1: Set the cookie on login As soon as the customer has logged in, their display name is stored in the cookie. If the display name is missing or empty, the email address is used instead. The third parameter specifies the validity period in seconds (here 365 days), so that the greeting is preserved over a longer period.Returning customers see their personal greeting until the cookie expires or is deleted.
Storing a display variant (e.g. dark mode)
The trigger here is a user action, namely a click. Since WEBSALE does not work with a theme system, you have to create a display variant yourself. To do this, you store the user’s choice in a cookie and load the matching style sheet when the page is built. Step 1: Provide the trigger The user chooses the variant via a link. The click triggers a page view, and only then can the value be set (see time of execution).The chosen variant is preserved across all page views until the user switches it.
Onsite personalization: audience-specific content
The trigger here is the entry path, i.e. a campaign link through which the visitor enters the shop. Unlike the personal greeting, this is true onsite personalization: you display different content on the shop pages depending on a characteristic of the visitor. The scenario: A pet supplies shop sends separate newsletters to cat and dog owners. Via the link in the newsletter, the shop remembers the target group and from then on shows matching content. Step 1: Campaign link in the newsletter The links in the newsletter carry the target group as a parameter:Visitors from the cat newsletter see the cat content on every visit, visitors from the dog newsletter see the dog content. All others see the default content.
Note: The cookie value is readable in the browser and can be modified by the user. Therefore, use the target group only to display content, not for security-relevant decisions such as prices or access rights. Since this is not a technically necessary cookie, check the user’s consent beforehand.
Reading an externally set cookie
The trigger here is a cookie that was set outside the shop, for example by your own JavaScript or by a third-party tool. Such cookies keep their original name and are not renamed automatically. To read them, passkeepNameAsIs: true. Otherwise, the shop will look for the renamed name and won’t find the cookie.
In the example, a flag set via JavaScript indicates that an info popup has already been seen:
The popup only appears as long as the externally set flag is missing.
Further reading
- $wsConsent – check the user’s consent before setting non-essential cookies.
