Skip to main content

Theme Customer Accounts

Stores can render customer account pages (login, registration, order history, addresses, password reset) directly from the active theme instead of the built-in account pages. When the feature is on and the theme ships the account templates, the storefront serves them inside the normal theme layout — same header, footer, fonts, and settings as every other page.

Enabling theme account pages

Merchants enable the feature in the admin under Settings → Preferences → Customer accounts by choosing Theme account pages. The fallback is automatic and per-page:
  • Feature off (default) → the built-in account pages render, exactly as before. Themes without account templates need no changes.
  • Feature on, theme ships templates/customers/* → the theme’s templates render.
  • Feature on, theme lacks a given template → the storefront serves the built-in page for that route automatically. Nothing breaks.
Theme developers should ship the full template set (below) so merchants get a consistent experience when they switch the toggle on.

Template set

Account templates live under templates/customers/ and follow the same rules as every other template: they can be JSON section templates (.json, composing sections) or plain Aqua/Liquid templates (.aqua / .liquid). Either form is rendered inside the theme layout.

Routes

Redirect behavior is enforced by the platform — themes don’t need their own guards:
  • A logged-out customer requesting /account, /account/addresses, or /account/orders/{id} is redirected to /account/login.
  • A logged-in customer requesting /account/login or /account/register is redirected to /account.
  • GET /account/recover redirects to /account/login#recover — themes conventionally use the #recover fragment to reveal the recovery form.
Use the routes object rather than hard-coding paths: routes.account_url, routes.account_login_url, routes.account_logout_url, routes.account_register_url, routes.account_addresses_url, routes.account_recover_url.

Forms

All account forms use the standard {% form %} tag. The tag renders the <form> element with the correct action URL and method and injects any required hidden inputs — themes only supply the visible fields.

customer_login

Posts email + password. On failure the page re-renders with form.errors set.

create_customer

Registration. Posts to /account; on success the customer is logged in and redirected to /account. On failure the register page re-renders with form.errors, and the submitted first_name, last_name, and email values are echoed back on the form object so inputs can keep their values.

recover_customer_password

Password-recovery request. Takes a bare email input (no customer[...] prefix). To prevent account enumeration, the platform always reports successform.posted_successfully? is true after any submission, so show a neutral “check your email” message.
The reset email links the customer to /account/reset/{customer_id}/{token}, which renders customers/reset_password.

reset_customer_password / activate_customer_password

Set a new password from a reset link, or a first password from an invite link. Both take customer[password] and customer[password_confirmation]. The identifying token from the URL is injected automatically as hidden inputs by the {% form %} tag — themes add nothing.
On success the customer is logged in and redirected to /account.

customer_address

Create or edit an address. Pass customer.new_address to create, or an existing address to edit — the form tag picks the right action URL either way.
Inside a customer_address form: Notes:
  • address[country] submits the full country name (that’s what the option tags emit as values).
  • address[default] = 1 marks the address as default — this is what form.set_as_default_checkbox renders.
  • customer_address forms never return field errors — the submission always redirects back to /account/addresses, and form.posted_successfully? is always true for this form type.
Deleting an address is a POST to the address URL with a _method=delete override. A plain form works:
Account pages also ship a small platform helper script that provides the classic POST-link helper (synthesizes exactly this form + _method submission from JavaScript) and the country/province selector — existing theme JavaScript that constructs these helpers keeps working unmodified. See Helper JavaScript.

Form state: errors and success

form.errors is iterable (yields error codes such as email, password, or the generic form) and supports contains:
For a one-liner, pipe through default_errors to render a ready-made error list:
A failed login sets the single generic form error code (with a default message like “Incorrect email or password.”) — no hint is given about whether the email exists.

Objects

customer

Available on all account pages (and globally on every page when the customer is logged in — {% if customer %} works in headers as usual).

order

Available as order on customers/order, and as each entry of customer.orders on customers/account.
All money values on order, its line items, and customer.total_spent are integers in the currency’s minor units (e.g. cents). Always pipe through the money filter family for display.

order line item

address

Used by customer.addresses, customer.default_address, order.shipping_address, and order.billing_address. Render a full address block with the format_address filter:

Platform extensions

The following properties are LaunchMyStore-specific — they go beyond the classic customer-accounts object model, so guard them with {% if %} in themes meant to stay portable.

line_item.selling_plan_allocation

Present on a line item when it was purchased on a selling plan (subscription):

order.subscription_status

On orders that carry an active subscription, the current billing status: active, trialing, paused, past_due, or canceled.

line_item.requires_shipping and line_item.digital_downloads

Digital products have requires_shipping: false and, once the order is paid, digital_downloads — an array of { name, url } download links the customer can use from their order page.

Example: subscriptions + digital goods on customers/order

Helper JavaScript on account pages

Account pages automatically include a small platform helper script — themes don’t need to load anything. Country / province selector. Populate the country <select> with the all_country_option_tags object. Each emitted <option> carries the country name as its value and a data-provinces attribute holding that country’s provinces as JSON. The helper wires a paired province <select> to update whenever the country changes, and preselects the value named in each select’s data-default attribute:
country_option_tags is also available and currently renders the same full country list. POST-link helper. The classic helper that submits a POST from a link — used by address-book templates to delete an address by posting to /account/addresses/{id} with _method=delete. Existing theme code that calls the country/province and POST-link helpers works unmodified; the plain-form alternative shown in the customer_address section works everywhere.

Paginating orders

customer.orders works with the standard {% paginate %} tag:

SEO

Account pages are personal: the storefront emits <meta name="robots" content="noindex"> on every customers/* page and excludes /account routes from the sitemap. Themes don’t need to add anything.