JustFlows

De documentatie is voorlopig alleen in het Engels. De rest van de site volgt uw taal.

Account pages

Every signed-in user gets an /account page. Edit its layout in the page builder, let plugins add sections, and give workspace owners one place to manage their sites.

5 min leestijd

Every signed-in user on a site has a frontend account at /account, separate from the admin. It shows their profile, sign-out, and sections from active plugins, such as Shop's orders and subscriptions. The page is ordinary content of the built-in Account type, so it uses the site's theme, header, footer, and styles.

Edit the page

Open Content → Account and edit Your account in the page builder. Change headings and text, add layout blocks, and move, remove, or add Account section blocks. Each one shows one of these:

  • Account controls — sign out and messages after an action.
  • Profile — the user's own details.
  • Plugin sections — every plugin's contribution, or one section by id, such as justflows.shop.orders.
  • Workspaces — the workspaces the user owns (on the installation's main site).
  • All account sections — everything together.

Section titles can be hidden so your own heading block supplies the wording. An empty section shows no empty panel. The page stores only layout: account data comes from the signed-in request and is never saved into the page. In the builder, sections show a placeholder; preview the page on the site to see real data.

Private by design

  • An account page always needs a signed-in session. Publishing it makes the layout available to signed-in users, not to the public.
  • Account pages and APIs send private, no-store to browsers, no-store to CDNs, and noindex, nofollow. They bypass the page cache, static export, the PWA service worker, and object storage.
  • They are left out of the public content API, search, sitemaps, and archives, and cannot be the home page.
  • Renaming the page's slug updates the sign-in links, and the old URL redirects. /account stays an entry point, and /platform-account redirects to it.

Workspace owners

On the installation's main site, a workspace owner's account lists only their own workspaces, sites, subscriptions, and resource limits. Owners can rename their workspaces and sites, create another site under the platform domain within their plan's allowance, and open each site's sign-in. Owners and users without admin access land here after signing in. Owners cannot change limits, enter database details, or manage anyone else's workspace.

Creating a workspace also gives its first administrator a Subscriber account on the main site, used for billing; an existing account with the same email is reused unchanged. Platform → workspace details show that owner's name, email, and user ID. See Multisite.

Add a section from a plugin

Contribute server-rendered sections with the account.sections filter. The host escapes all text; links accept same-origin paths or HTTPS URLs. An action posts to your own endpoint, which must check that the signed-in user owns the data.

ts
ctx.hooks.filter("account.sections", (sections, account) => [
  ...sections,
  {
    id: "acme.memberships",
    title: "Membership",
    cards: [
      {
        title: "Gold",
        fields: [{ label: "Renews", value: "1 November 2026" }],
        links: [{ label: "Benefits", href: "/membership" }],
        actions: [{ label: "Cancel", endpoint: "/api/acme/account/cancel", confirm: "Cancel your membership?" }],
      },
    ],
  },
]);

Note

Migration 0045_account_pages seeds the default page on existing sites, without touching a page you already customised, renamed, or deleted. Plugin routes under /api/<namespace>/account get the same private, no-store policy.