Members and accounts

What the Member module owns

The Member module owns the concept of a member account. It creates the member table for the accounts themselves and the member_auth table for the ways a member can sign in, and it provides the member-facing pages such as login, register, forgot and the code-entry page. It is the home of the member area: everything about who a member is and how they get in lives here, while the rest of the membership family builds on top of it. Authentication is deliberately not baked in; sign-in methods are separate submodules that register themselves, which the Authentication and sessions page covers.

Turning on members

A site turns members on the same way it configures any module: by providing that module's settings in index.php. MEMBER_URL is where the member pages are mounted, and MEMBER_REGISTER_ENABLED turns registration on or off:

Config::Provide('Member', [
    'MEMBER_URL'              => '/member',
    'MEMBER_REGISTER_ENABLED' => true,
]);

Both are declared as required in the module's index file, so the security check stops a site that mounts the Member module without saying where its pages live or whether registration is open.

Member records

A member account is a small record: an id, when it was added, and whether it has been deleted. Personal details, contact details and documents are not stored on the account itself. That keeps the account a stable identity that other modules can hang data off, without the Member module needing to know what any particular site collects about its members. Richer per-member data lives in its own modules, described under Identity and verification and Member settings and folders. Optional per-member feature flags let a site mark individual accounts as having a capability the rest of the site can then check for.

The member area

The member pages are mounted under MEMBER_URL and cover the account lifecycle: signing in, registering, recovering a forgotten password, and entering a one-time code. The Member module owns these routes and the forms on them, but the actual sign-in fields come from whichever method modules are installed, so the login and register pages show exactly the methods a site has turned on. URLs into the member area are built by name through MemberUrl (for example MemberUrl::Login()) rather than by hand-writing paths, so a site can move MEMBER_URL without breaking links.

Who is signed in

The logged-in viewer is resolved from the member session: the Member module reads the session and works out which account, if any, is signed in. A page that needs a member simply asks, and if nobody is signed in the module throws MemberNotLoggedInError rather than returning null and forcing every caller to check. The site catches that one error around its render pass and redirects to login. That end-to-end flow, along with the sessions it rests on and the sign-in methods, is the subject of the next page.

Next: Authentication and sessions.