Who this is for. Everyone starting on a member site: the theme developer, the content modeller and the integrations engineer. Afterwards you know which record a piece of member data belongs on, and how to read the signed-in visitor in a template.
Three records
| Record | Is | Holds |
|---|---|---|
| Person | The human | Email address, title, first, middle and last name, gender, addresses, groups, custom fields |
| User | The login, belonging to one person | Username, password (or none, for someone who signs in only through a provider or a passkey), type, status, custom fields, and the person's API keys, tokens and sign-in methods |
| Author | A public byline, belonging to one person | Display name, biography, website, social links, picture. Blogs and blog posts use it |
A person can exist without a user: a newsletter subscriber, someone who filled in a form, a customer imported from another system. A person has at most one user and at most one author. The author has nothing to do with signing in: being a byline neither needs nor grants a login.
A member and an editor, side by side
| A member | An editor who writes for the blog | |
|---|---|---|
| Person | Yes: name, email address, addresses | Yes: name, email address |
| User | Yes, of type Frontend user: signs in on the website | Yes, of a backend type such as Administrator: signs in to the admin |
| Author | No | Yes: the name and picture shown on their posts |
The user's type is what makes one a member and the other an administrator; the records are otherwise the same. Members and backend users covers the types and what keeps members out of the admin.
Where member data belongs
- Contact details go on the person, never copied onto the user or the author. The email address is the person's.
- The email address is unique among all the people of the account: a second person with the same address is refused with "This email is already used." People and users belong to the account, not to one site, so a client with several sites on one account has one set of them.
- Data the member owns, such as a phone number or preferences, goes in custom fields on the person; data that repeats or has its own life goes in related records (Profile data: custom fields or a related record).
- Addresses are the person's address book (Addresses and the address book).
- What the member may see comes from groups and permissions (Groups and permissions), never from a value stored on the member's own records.
An integration that imports customers creates people; it creates users only for the customers who are to sign in. A form submission can create a person too, and that person still cannot sign in (Create a person record from a form submission).
The current user in a template
Every template receives _currentUser, a small helper describing who is looking. It is not the user record:
| Method | Returns |
|---|---|
isLoggedIn() | Whether anyone is signed in |
getId(), getPersonId() | The user's id and their person's id |
getUsername(), getFullName(), getType() | As the names say; the type is frontend, backend, admin, superadmin or developer |
isFrontendUser(), isBackendUser() | Whether the type is frontend, or anything else |
isAdmin(), isSuperAdmin(), isDeveloper() | True for administrators, super admins and developers; super admins and developers; developers |
getPerson() | The person record, or nothing when nobody is signed in |
Two details catch people out. isFrontendUser() is also true for a signed-out visitor, whose type defaults to frontend, so test isLoggedIn() first. And getPerson() is empty for a signed-out visitor, so calling a method on it without the test stops the page.