Repository navigation
Members
The Members system gives your visitors their own accounts, separate from the admin Users who manage your site. Members can sign in, keep a profile, and (if you want) be the only people who can see certain parts of your site.
This is a different system from admin Users (see Managing users) - members never have access to your admin area, and admins never appear in the members directory. Under the hood the two never mix; in the admin, though, members and staff are listed together in one combined Users table for convenience (see Admin tools below).
Go to Users → Settings in the admin and tick Members system enabled (the checkbox sits above the Registration/Avatars/Usernames/Account sections/Access control tabs - it's visible no matter which one you're on). Nothing changes for visitors until you do this.
Once it's on, your site gets:
- A registration page and a sign-in page, both under a web address you choose (see Member area address below).
- A public profile page for every member, at
/members/<their-username>. - Member management tools on the Users page and Settings page in your admin (see Admin tools below).
Members can sign in three ways, and each one has its own setting (Users → Settings → Access control):
- Passkey - fingerprint, face unlock, or a security key. The quickest and most secure option. Optional by default.
- Email sign-in link - a one-time link emailed to them. No password to remember. Optional by default, and it's what a brand-new member uses the very first time, before they've set anything else up.
- Password - the traditional option, off by default. If you turn it on, the password is always followed by a short code sent to the member's verified email address. They can choose an authenticator app or text messages instead.
Each method is one of three things:
- Off - never offered to anybody.
- Optional - offered, and members set it up if they fancy it. This is how the site has always behaved.
- Required - every member must have it. They're walked through setting it up on their way in, and nothing else in their account opens until they have.
The email sign-in link has no Required option, and that's deliberate rather than an oversight: there's nothing for a member to set up. Their inbox is the credential, and they proved they have it when they verified their address.
Setting Password to Required also puts a password box on the sign-up form, so new members choose one as they join. The email code needs no separate setup; a member only has something to enrol if they choose an authenticator app or text messages instead.
With Password set to Optional the sign-up form offers a password box too, which you can turn off with Ask new members to set a password under Registration. Passwords stay available either way - members just add one from their own Account & Security page rather than being asked for one before they've so much as looked round.
Members can still add a passkey, set a password, or turn on the extra sign-in step for themselves from their own account's Account & Security page - you don't need to do anything per-member. What they can't do is remove something you've marked Required; the site says so plainly rather than letting them delete it and immediately asking for it back.
Turning the email sign-in link off is the one setting that can strand people. Passkeys and passwords are both set up from inside an account, and a member who has only just registered can't get inside one yet - so with the link off, a brand-new member has nothing they can use. Existing members with a passkey or a password carry on perfectly happily. The settings page says as much when you switch it off, and refuses outright to save with all three methods off, which would lock the doors on everybody.
It asks for the email address first, and nothing else. Once they press Continue, it offers only the ways that particular account can sign in:
- Added a passkey? They get the passkey button, offered first.
- Set a password? They get the password button.
- Done neither - which is everyone on day one - the sign-in link is simply sent there and then, and they're told to check their inbox. No second button to press, because there was only ever one thing they could have pressed.
Once a member has a working password or passkey, the sign-in link is no longer offered and a new one cannot be requested for that account. It remains the way in for members who have neither. Nobody is shown a button that could only ever fail, and nobody has to remember which of three things they set up last spring. There's a "use a different email address" link underneath - on the choice of methods and on the "check your inbox" message alike - for the inevitable typo.
An address that isn't registered at all gets the same "check your inbox" message as a real one - the form never lets on whether an account exists. What lands in that inbox differs: a registered address gets its sign-in link, an unregistered one gets a short email saying no account was found there, with a link to register. So a mistyped address doesn't just go quiet - the person who typed it finds out, without the sign-in form itself giving anything away.
Clicking the link out of the inbox signs them in and drops them on their account. If they were part-way through something when they were asked to sign in - checking out, say, or opening a page only members can see - they carry on from there instead.
If the site can't reach its own settings for a moment - a wobbly connection at their end - the form quietly offers every method you've switched on rather than hiding one, so a passkey holder is never stuck looking at a form that won't take their passkey.
If a text-message module (such as Twilio) is installed and configured, members using a password can have their sign-in codes texted to a mobile number instead of emailed. Users → Settings → Access control → Mobile number for sign-in codes controls whether that's their choice:
- Optional (the default) - members may add a mobile number from their account page if they fancy it.
- Required - members with a password must add one. Anyone who hasn't yet is still let in with an email code (nobody gets locked out), but they're taken straight to the add-your-number card after signing in and reminded on every account page until it's done.
Without a text-message module installed, the setting quietly does nothing - there's no way to send the texts.
Knowing how people sign in is no use if they can't find where. The Members: Sign In block is the one control you drop into a header, a footer bar, or any page, and it looks after the rest.
Find it in the page builder under Members, or in the header editor under Site. It's built to sit happily next to a shop basket icon, so a header with both doesn't look like two people designed it.
What it looks like
- Icon - a person, a person in a circle, a padlock, a key, an arrow through a door, or no icon at all.
- Text label - "Sign in" by default. Clear the box and you get a bare icon, the way the basket does it. A bare icon isn't left to be guessed at: hover it, or reach it with the keyboard, and a small label appears underneath saying what it is - "Sign in", or "My account" once they're signed in. It's the same tooltip the admin uses on its own icons, so it looks like it belongs. Leave a text label in the box and there's no tooltip, since it would only be reading the button out loud back to you.
- Style - a bordered pill, a filled block, or plain text with no box, plus colours and corner rounding to match your header. There's a Hover colour too; leave it blank and the block warms to your site's main colour under the mouse, exactly as the theme toggle and Icon Link do, so a row of header icons all answer the cursor the same way.
What happens when someone clicks it
- Go to the sign-in page - the ordinary route. Once they're in, they're taken to their account.
- Open a sign-in panel over the page - the form floats over whatever they were looking at while they sign in, then takes them to their account. It's the same sign-in form as the real page, so passkeys, sign-in links, passwords and codes all behave identically. You can set the panel's heading, its width, its corner rounding, and whether it offers a "create an account" link underneath. That link stays hidden if you've set registration to invite-only, since there'd be nothing behind it.
You can also name a specific page to send people to after they sign in. Leave it blank and they go to their account overview.
Once they're signed in
The block doesn't just sit there saying "Sign in" at someone who already has. Choose whether it becomes an account link, an account link with a sign-out button beside it, or nothing at all. It can show the member's own picture in place of the icon, and it takes itself off the sign-in page entirely, on the grounds that the form is already right there. A member who hasn't got a picture - nothing uploaded, and nothing waiting for them at gravatar.com - simply keeps your icon. The initials avatar stays on their profile page and in the member directory, where it's doing a useful job of telling two people apart; in a header it's just a pair of letters where an icon used to be.
Trying it out first
Set Who can see this to Admins only and the block appears for you and nobody else while you're signed into the admin. Handy for having a look at it on the real site before your visitors do. Set it back to Everyone when you're happy.
The block only appears on your site at all when members are switched on. Turn members off and it politely vanishes rather than offering a door to nowhere.
Users → Settings → Registration controls who can sign up:
- Open - anyone can register.
- Invite only - people need an invite link, which you generate from Users → Invites. Each invite can be used once and expires after however many days you set.
- Approval required - anyone can register, but their account waits in a queue (Users → Pending Approval) until an admin approves it.
You can also require email verification before an account becomes active (on by default), and restrict registration to specific email domains or block specific ones.
The sign-up form asks for an email address, a username and an optional display name, plus a password if you offer them. All but the email address can go:
-
Ask new members to choose a username - turn it off and the box disappears. Cactus makes one up from their email address instead, with a few random digits after it, so
chris@example.combecomes something likechris4821. - Ask new members for a display name - turn it off and the optional display-name box disappears too.
Both switches follow the member into their account, not just the sign-up form. Turn one off and the matching box vanishes from Profile as well, along with anything else that mentions it: no "change your username" offer for a handle they never picked, and the overview stops listing a missing display name among the things they still ought to fill in. With the username switch off, the overview greets them by the front half of their email address rather than by the made-up handle, on the grounds that being welcomed by a name you've never seen before is unsettling.
The offer to change a username now also waits until you've actually allowed username changes (Users → Settings → Usernames), which is off to begin with. Members used to get the box and the button regardless, and pressing it was politely refused every single time.
- Ask new members to set a password - turn it off and signing up asks for nothing to remember. This one only appears while passwords are set to optional: with passwords off there is nothing to ask about, and with them required the form has to ask.
Turning the password box off doesn't take passwords away. Members can add one whenever they like from Account & Security in their account, which is where they'd set up the short code that goes with it anyway. It's often the kinder order of events: signing up takes one box and a click on an emailed link, and the password conversation waits until they've decided they're staying.
Hiding a box genuinely removes it rather than tucking it out of sight, so nobody can fill it in by being clever with the form.
If your site's outgoing email is misconfigured, the account is still created, and the person signing up is told plainly that the email couldn't be sent rather than being parked on a page waiting for a link that will never arrive. The reason lands in your deployment logs. The quickest way to see it for yourself is Settings → Configuration → Email → Send test email, which reports whatever your mail provider said back. A common culprit is a from address your mail provider doesn't consider yours: most of them, iCloud especially, refuse to send on behalf of an address that isn't the account you're signing in as or one of its verified aliases.
A registration link can arrive with the email address already filled in - add ?email=someone@example.com to the sign-up link and the box starts with it typed. It's a convenience, nothing more: the address is still theirs to change, and it still has to be verified. The Shop's post-purchase "create an account" prompt does the same thing without the link: it puts the sign-up form on the order confirmation itself, already holding the address they ordered with, so the order they just placed joins the new account.
Once they've signed up, people wait on a page that names the address the link went to and offers a Send it again button, limited to one send a minute so your mail provider stays friendly.
That minute is counted from the moment they arrive, because the link they're waiting for has only just gone out. Offering the button straight away was worse than useless: the site quietly declines to send a second link within a minute of the first, so an eager click reported success and did nothing at all - which looks exactly like email being broken when it isn't.
It shows that address as plain text rather than in an editable box. Re-sending is the only thing the page can do, so a box invited people to "correct" a typo there, and the correction would have gone quietly nowhere while still looking like it had worked.
For a genuine typo the page offers a sign up again link instead, which is the only real fix - the half-finished account left behind stays unverified and out of everyone's way. That link is hidden on invite-only sites, where signing up again would need an invite they haven't got.
Someone arriving at that page cold, from a bookmark or a link they dug up weeks later, is asked for their address instead, since nothing in the link says whose account it is.
Clicking the link verifies the address and signs them in, landing them in their account area with nothing else to do. Fetching a link out of your own inbox proves the address is yours every bit as well as an email sign-in link does, so asking for a sign-in immediately afterwards was making people prove the same thing twice in a row - which is precisely where a good number of them wandered off.
The good news travels with them: Your email is verified and you are signed in. Welcome. appears as a small pill at the top of the page they land on, and takes itself away after a few seconds.
Sites that hold new accounts for approval are the exception, and deliberately so: there the pill says the account is awaiting approval and no sign-in happens, because there's nothing to sign in to yet. Suspended and deleted accounts are turned away the same way, by the same check every other sign-in method uses.
A link that has expired, or has already been used, still says so on the verification page itself, with the Send it again button underneath - that's a page with something left to do on it.
Once signed in, members land on an overview page that tries to answer the obvious questions before they have to go looking: who they're signed in as, when they joined, whether their email address still needs confirming (with a button to send the link again), how their sign-in is set up, what's still blank on their profile, and the last few things that happened on their account. Everything else lives behind the tabs above it, which you can individually switch on or off (Users → Settings → Account sections):
The greeting at the top uses their first name once they've given one - just the first word of it, since "Hi, Chris" is what a person says and "Hi, Chris Taylor-Guest" is what a bank says. Without one it falls back to their display name, then their username, then the part of their email address before the @. A member with no full name on a site that's also turned the Profile tab off simply gets "Hi there", because there'd be nowhere for them to correct a name we'd guessed at.
Sitting near the top of that page is Your details, holding the member's full name and, beside it, an optional Organisation name - the company, school or practice they buy on behalf of. They can change either whenever they like. On a narrow screen the two sit one under the other rather than shoulder to shoulder. With the Shop installed both are filled in for them at the checkout, so a returning customer types them once and never again. It's deliberately not part of the Profile tab and doesn't disappear with it: a display name is a public handle you may not even ask for, whereas this is simply who an order is made out to, and a shop whose accounts exist purely to sign in and pay still needs one.
The organisation box can be switched off under Users → Settings → Sections if your site has no use for it, and then it's properly gone - not merely hidden, since nothing new can be saved into it either. Anything already there is left alone, so switching it back on brings everything back. It's on to begin with, being one optional box and rather useful to anyone selling to businesses.
Underneath that switch sits Make it required, which does what it says: the box stops calling itself optional, the Save button won't go until there's something in it, and the same rule is applied when the details are saved rather than only in the browser. Off to begin with, since a shop selling to the public would otherwise be stopping people saving their own name until they'd invented a company. Nobody who signed up years ago is chased for it - they're simply asked the next time they open the page.
Members who arrived through the checkout don't start empty either. Once the email address has been verified, guest orders placed at that address are matched to the account, and the name and organisation from the most recent one are copied onto it - and the same happens when somebody already signed in places an order. It isn't a one-off at the moment of matching: any visit to the account or the order history will fill in a blank name or organisation from the member's own order history, so a member left blank by an earlier version doesn't stay that way. Only ever into blanks: anything the member has typed on their own account page wins, so a correction is never quietly undone by an older order.
There's no phone number beside any of this, on purpose - a number is how a courier reaches whoever's at a particular door, so the Shop keeps one against each saved address instead.
-
Profile - display name, bio, website, avatar (uploaded photo, Gravatar, or automatically generated initials), and which of these show up on their public profile. The three picture sources sit behind a set of radio buttons under the avatar, and only the ones actually available are offered: no Gravatar unless you have allowed it (Users → Settings → Avatars), and no uploaded photo until there is one. Where Gravatar is allowed, new members start on it, so a member who already has a picture attached to their email address at gravatar.com arrives with it in place rather than having to go and find the setting. Anybody who hasn't simply gets their initials, which is what they would have had anyway. The username and display-name boxes only appear if you ask for them at sign-up (see Shortening the sign-up form). The website box only accepts an ordinary web address beginning
http://orhttps://, since that box becomes a real link on a public page and anything else there is either a mistake or somebody being clever. The same applies when an admin edits a member's website on their behalf, and an address saved before that rule existed simply stops being rendered as a link. Switch this one off and the page genuinely goes: the tab disappears, the card on the overview disappears, and typing the address in by hand gets a Not found rather than the page. Nothing on it can be saved either, so a member with it already open in an old tab is told it's been switched off instead of quietly getting their changes dropped. Worth doing on a site where an account is only ever a way to sign in and pay, and a bio nobody will read is just another empty box to look at. Their existing details aren't deleted - switch it back on and everything is where they left it. - Account & Security - their email address, passkeys, password, two-factor authentication, active sessions, and trusted browsers. See Changing their email address just below.
- Notifications - how members want to hear about anything your installed modules notify them about: by email, by text message, or both. The text column only appears where the site can actually send one (the Twilio module, with a text-enabled number added) and where the module in question offers it. Some things can be moved but not switched off - order updates, for one - so a member can choose email or text or both, but not silence. Nothing installed offers any notifications yet? The tab hides itself rather than sending members to a page that only tells them there is nothing to choose. Texts go to the phone number on the order they're about, which is why there's no separate mobile number box on the account.
- Activity - a simple history of their sign-ins and other account activity.
- Danger Zone - requesting a copy of their data, or deleting their account.
Switching any of the other four off takes its tab away, and its card off the overview with it. Profile is the one that goes further and shuts the page itself, because it's the one people most often don't want offered at all.
Users → Settings → Account sections → Put the whole account on one page does what it says: every section a member can see is drawn down the overview, one under the next, instead of sitting behind a page each. The tabs stay exactly where they were - clicking one glides down to that part of the page rather than loading anything - and the tab bar pins itself under your site header as they scroll, so it's never more than a glance away. Whichever section they're reading is the one lit up in the bar.
It suits an account with three or four short sections on it, where a tab per page is more clicking than reading. Leave it off for a busier one: a long page of everything is its own kind of unhelpful.
Switching a section off still removes it, here as everywhere - its tab, its card and now its stretch of the page go together. The sections come down the page in the order their tabs are listed across the top. Tabs added by modules come down with them where the module offers a section to draw: with the Shop installed, Orders and Addresses & Phone Numbers are stretches of the same page, sitting after Account & Security exactly where their tabs do, and their tabs scroll to them like any other. An individual order still opens on a page of its own - it has rather more on it than a summary - and every one of those module pages carries on working for a bookmark or a link in an email. And a member who'd bookmarked one of the old section addresses lands on the right part of the one page instead of a dead end.
Turning the Profile tab off is not the same as hiding members from the public side of your site - that's Public profile visibility, a few lines further down, and the two work independently.
Installed modules can add tabs of their own here, and they slot in after Account & Security - the things members actually came for shouldn't sit past the tab about deleting their account. With the Shop installed, members get Orders and Addresses & Phone Numbers there, and those pages sit inside the account with the same tabs across the top rather than dumping people on a bare page with no way back (on a one-page account they're part of the page instead) - see Shop.
Members can move their account to a new email address themselves, from Account & Security. It takes two steps, and on purpose: the site emails a six-digit code to the new address, and only moves their sign-in across once that code comes back. Until then everything carries on going to the old address, so a mistyped one costs a wasted email and nothing else - rather than quietly sending every future sign-in link to a mailbox nobody can read.
A few things happen around it without anyone having to ask:
- If they have a password, they're asked for it first. It's the one thing somebody who has wandered up to an unlocked laptop hasn't got.
- The old address is told a change has been requested, and told again once it goes through. If it wasn't them, that's their cue to change their password while they still can.
- The new address counts as confirmed the moment the code is used - they've just proved they can read it - so nobody is asked to verify the same mailbox twice.
- Your domain rules still apply. An address on a blocked domain, or off an allow-list, is refused here exactly as it would be at sign-up.
- The change shows up in their Activity list, and the code expires after ten minutes.
Two cases where the option isn't offered: a site with no email sending set up yet (there'd be no way to send the code), and admins using the member area with their staff sign-in - their address belongs to the admin account, so it's changed from the admin account page instead.
Signing in to your admin and signing in as a member are two different things - deliberately, since members have no business holding admin credentials and vice versa. That used to mean that opening /account while signed in to your own admin asked you to sign in again, which is a fair impression of a broken website.
Now it doesn't. The first time you open the member area while signed in as an admin, the site quietly gives you a member account of your own - same email address, ready to use - and lets you in. Your admin sign-in is what it goes on, so there's no second password to remember and no code to wait for. If you already had a member account on the same address, that one is used rather than a second one being invented.
Two things worth knowing:
- Your member account shows up in the Users list marked Staff account, so seeing yourself twice there is expected, not a duplicate to tidy away.
- Sign out in the member area still signs you out of it, and stays signed out, even though your admin session is still live. When you want back in, the sign-in page offers you a Continue to your account button - one click, no password.
You can't delete this member account from the member area's Danger Zone, since removing your admin account is what actually removes it.
Members can request a copy of all their data at any time - it's bundled up and available to download for 48 hours. If they delete their account, it's not removed immediately: there's a grace period (you choose how long, default 14 days) during which they can change their mind, before it's permanently deleted.
Every member gets a profile page at /members/<username>. You control who can see it (Users → Settings → Account sections → Public profile visibility):
- Public - anyone, including visitors who aren't signed in.
- Members only - only people signed in as a member.
- Hidden - profiles are switched off entirely.
There's also an optional member directory (a page listing everyone), which you can switch on separately.
Member management lives alongside your ordinary admin Users, rather than in a section of its own:
- At-a-glance member counts appear on your admin Dashboard, alongside your page/user/media counts.
- Members show up right in the main Users list, alongside admin staff - see Managing users for how that combined list works. Every member is automatically given a system Members role the moment they register, so they carry a role badge in that list the same way staff do (it's just for show - it doesn't grant any admin permissions, since members never touch the admin area).
- The Users page keeps two extra tabs when Members is switched on:
- Pending Approval - the queue when registration mode is set to Approval required.
- Invites - generate and revoke invite links.
- A member detail page for each person (click their row in Users) - edit their profile, suspend or approve them, mark them as trusted, revoke their sign-in sessions, reset their password and two-factor setup, trigger a data export on their behalf, leave internal notes, and see a full history of admin actions taken on their account. This is also where you suspend/approve/trust/delete an individual member - the old bulk multi-select list is gone now that Members lives inside the combined Users table.
- Your Settings page gains:
- A GDPR & Legal section covering consent records, data export requests, and pending deletions, all in one place.
- A Users tab holding Registration, Avatars, Usernames, Account sections and Access control (all the member settings covered on this page), plus Roles (who can do what - see Managing users). The wording of member emails is no longer edited here: it lives on Settings → Email → Templates with every other email the site sends - see Configuration reference.
Users → Settings → Access control → Site-wide members-only mode locks your entire public site behind sign-in - visitors must be a member to see anything. You can list specific pages as exceptions (for example, your homepage or a "why join" page), and admins always get through regardless.
If you'd rather show a locked-down preview to guests instead of blocking them outright, turn on Guest preview as well.
Individual modules can also mark specific pages as members-only (or "trusted members only") independently of this site-wide switch - check that module's own wiki page for details.
By default, members reach their account area at /account (e.g. yoursite.com/account/login). You can change this to something else via the MEMBER_AREA_PATH environment variable - see Configuration reference. Like the admin path, this is set at deploy time, not from within the admin, and changing it requires a redeploy.
Wiki: Home · Managing users · Managing pages · Configuration reference · Architecture overview