Sign-in and registration
Memberside offers two separate sign-in stacks. Choose one — mixing them is the most common sign-in problem.
Two stacks
Section titled “Two stacks”| Ultimate Member | WordPress core | |
|---|---|---|
| Features | Login, Register, Forgot Password, Logout | Default Login, Default Register |
| Fields come from | Your Ultimate Member forms | WordPress core |
| Endpoint group | Authentication | Default Authentication |
| Needs Ultimate Member | Yes | No |
Use the Ultimate Member stack when your registration collects custom fields, uses roles, or runs approval workflows. The app renders your actual form.
Use the WordPress core stack when you want a plain sign-in, or your site does not run Ultimate Member. It carries its own appearance settings and a role allow-list. (Cloudflare Turnstile is available on either stack — see below.)
Forgot Password and Logout work with either stack. On a site without Ultimate Member, a signed-out member lands on Default Login, and a new app’s starting layout places Default Login, Default Register and Delete Account for you.
Social sign-in
Section titled “Social sign-in”Members can sign in with an account they already have. Set a provider up on your site, pick it on the feature, and its button appears on the sign-in screen — see Social sign-in for the provider grid and a setup guide for each one.
Two rules worth knowing:
Email verification is required. A provider that does not return a verified email cannot be used to sign in to an existing account by email match, because that would let anyone with an unverified address claim it. Which providers those are is listed on Social sign-in.
Native Google sign-in is tied to your signing certificate. It works in the preview and fails in the built app until the app’s SHA-1 fingerprint is registered with your OAuth client. See Android signing.
Members manage their linked accounts through Social Connects.
Turnstile
Section titled “Turnstile”Cloudflare Turnstile can protect every sign-in screen, on either stack — Login, Register, Forgot Password, Default Login and Default Register. Each has its own switch, under Features in its tab settings, so you can challenge registration without challenging sign-in.
Both halves of the key pair live on your site, under Memberside → API Keys. We store neither:
- The site key is read from your site each time you build, and compiled into that build.
- The secret key stays on your site and verifies the challenge. It never ships.
Because the key is read at build time, adding it to your site needs a rebuild before the challenge appears. Builds read it through the Site → capabilities endpoint; placing a sign-in feature switches that group on for you, but with it off the build fails rather than shipping an app that shows no challenge against a site that still demands one.
Forgot Password is worth a thought before you switch it on. The challenge fails closed: while Turnstile’s verification service is unreachable, password resets stop working for everyone. That is the right trade for a form that sends mail to any address a caller names, but it is the one screen where a member locked out has no other route. Clearing the secret on your site switches it off everywhere at once.
With only the site key set, the challenge renders and every verification fails.
Your site follows each app’s switch
Section titled “Your site follows each app’s switch”Saving the app sends each sign-in feature’s Turnstile switch to your site. From then on your site asks for the challenge on a form only for apps that have it on. Turn Turnstile off on Login and members of that app sign in without one, while an app with it on keeps requiring it.
Three things stay fixed whichever way a switch is set:
- A token that is sent is always checked, and a bad one is refused.
- Apps built before this change send no app name with their requests, so your site holds them to its site-wide Require the challenge switch, under Memberside → API Keys → Cloudflare Turnstile. Rebuild an installed app for it to follow its own switches.
- A form whose feature you have not placed also follows that site-wide switch.
The Cloudflare Turnstile screen on your site lists each app’s choice per form, so you can see why a sign-in went through without a challenge. Those choices are set in the builder only.
This needs Memberside 2.38.0 or later on your site. After you switch Turnstile off on a feature, the builder warns Save to apply this to your site until you save: until then your site still requires the challenge, and members are refused.
Terms & Conditions
Section titled “Terms & Conditions”Switch on the Terms & Conditions service on your site and every sign-up screen in your app asks the new member to agree to your terms before their account is created. Your site records the agreement, and wp-admin shows who agreed and when.
It is a service inside the Memberside plugin, free on every plan. It is off until you switch it on, and it needs a recent version of Memberside on your site.
Turn it on
Section titled “Turn it on”- In wp-admin, open Memberside → Services.
- Switch on Terms & Conditions. Its settings open straight away, because nothing shows in the app until a page is chosen. Later, reach them with Manage on the card.
- Choose your Terms & Conditions page. Click the box to see your pages A to Z, or start typing a title to search. Typing a page’s ID number finds that page too.
- Check the Privacy Policy page. It starts as the page set under WordPress’s Settings → Privacy.
- Choose your Cookie Policy page, or leave it on None. The × in a box clears it back to None.
- Change the wording if you want your own, then select Save wording. The preview under it shows the sentence your members will read.
| Setting | What it does | Default |
|---|---|---|
| Terms & Conditions page | The first page named in the sentence | None |
| Privacy Policy page | The second page named | WordPress’s privacy page |
| Cookie Policy page | The third page named | None |
| Checkbox text | The words before the page names | I agree to the |
| Message when it is not ticked | Shown under the checkbox when a member submits without ticking it | Please agree to the Terms & Conditions to continue. |
Only published pages can be chosen. Each suggestion shows the page it sits under, so two pages with the same title can be told apart. The card on the Services screen says No pages chosen until at least one is.
Each page is optional. A page left on None drops out of the sentence. With the service on and no page chosen, the app shows nothing, because a checkbox with nothing to agree to is worse than none.
Switching the service on also switches on the Terms & Conditions endpoint group, which the app reads the sentence from. Placing Register or Default Register switches it on for you as well.
What your members see
Section titled “What your members see”A checkbox above the submit button, on every screen that creates an account:
- Register, the Ultimate Member form.
- Default Register, the WordPress core form.
- The social buttons on those two screens.
- An Entry Form block that creates members, when someone signed out fills it in.
The sentence reads I agree to the Terms & Conditions, Privacy Policy and Cookie Policy. Each page title is a link. Tapping one opens the page inside the app, without your site’s header and footer, and the back arrow returns to the form.
The member cannot submit until they tick it. Submitting without it shows your error message under the checkbox. The social buttons on a register screen stay greyed out until the box is ticked, with Agree to the terms above to continue. under them.
Login screens do not change. A member who already has an account is never asked.
In the builder, the Register and Default Register settings show a Terms & Conditions line above the Turnstile switch, read from your site:
- On — managed in Memberside → Services. Every sign-up screen shows the checkbox.
- On, but no pages chosen yet — choose them in Memberside → Services. The service is switched on with nothing to agree to, so the app shows nothing.
- Using Ultimate Member’s Terms & Conditions on this form. Register only: the service is off and the chosen form uses the extension’s own agreement.
- Off.
The line is missing when your site’s Memberside is too old to answer.
Where agreements show in wp-admin
Section titled “Where agreements show in wp-admin”Users gains a Terms column. A member who agreed has a green tick; hover it for the date and where they agreed, such as Agreed 3 October 2026 10:42 · app sign-up. A member who did not has a dash. Click the heading to sort by it. The column appears once the service is on, or while Ultimate Member’s own Terms & Conditions extension is active.
Each member’s profile screen in wp-admin has a read-only Terms & Conditions row: the date, the sign-up screen, and each page they agreed to with the date that page was last changed. No IP address is stored.
Ultimate Member’s Terms & Conditions extension
Section titled “Ultimate Member’s Terms & Conditions extension”If your site runs Ultimate Member - Terms & Conditions, its per-form setting works in the app too. With the Memberside service off, a registration form that has the extension switched on shows the extension’s own agreement sentence on the app’s Register screen, followed by a Read link to the page you chose there. Agreeing writes the extension’s own record as well, so its Account tab and its admin email stay in step.
The Memberside service wins whenever it is on. Every sign-up screen then uses the service’s pages and wording, including Register forms that have the extension switched on. Agreeing still writes the extension’s record on those forms.
The extension covers the Ultimate Member Register screen only. For Default Register, the social buttons and the Entry Form, use the service.
Limits
Section titled “Limits”- Social sign-in on a login screen. Someone brand new who taps a social button on a Login or Default Login screen gets an account with no agreement recorded. Put the social buttons on your register screen too, and point new members there.
- Older app builds. An installed app built before this change shows no checkbox. Your site still lets its members register, and records them as not agreed. Rebuild the app to show it.
- It records consent. It is not a lock. Someone calling your site’s API directly, rather than through the app, can skip the checkbox. What it gives you is a record for every member who signed up in the app.
- Your website’s own forms are not covered. The service asks on sign-ups made in the app. Registrations on your website follow whatever that form asks.
- Sorting skips extension-only agreements. A member who agreed only through Ultimate Member’s extension shows a tick, but sorts with the members who did not agree when you sort the Terms column.
- Asking again after a page changes is not built yet. Your site stores the date each page was last changed when the member agreed, so the record is there, but members are not asked to agree a second time.
Registration fields
Section titled “Registration fields”The Ultimate Member registration screen renders your registration form, including conditional fields — a field that shows based on another’s value does the same in the app.
ACF fields are supported on Default Register where Advanced Custom Fields is active, with the ACF endpoint group enabled.
After sign-in
Section titled “After sign-in”Each auth feature has an “after” target: where the member lands once they sign in, register or sign out. Set it on the feature, under Features in its tab settings.
If you leave it unset, members stay where they are, which is rarely what you want after registration.
What a signed-out member sees
Section titled “What a signed-out member sees”Tabs restricted to a role are hidden entirely before sign-in, because a signed-out visitor has no role. That means a restricted tab cannot be part of your signed-out experience.
Decide deliberately whether your app is browsable before sign-in. A community that shows a directory and a feed to visitors converts better than one that shows a sign-in wall — but if your content is members-only, restrict it properly on your site rather than by hiding tabs, since restrictions hide navigation, not data.
When it does not work
Section titled “When it does not work”| Symptom | Cause | Fix |
|---|---|---|
| Sign-in fails with correct credentials | The wrong endpoint group for the stack you placed | Members cannot sign in |
| The sign-in screen has no fields | The Ultimate Member form has not opted into the API | Forms and directories |
| Turnstile always fails | Only the site key is set | Set the secret key on your site |
| “Please complete the verification challenge” with Turnstile off on the feature | The change has not been saved to your site, the site runs Memberside older than 2.38.0, or the installed app predates it | Save the app, update Memberside, and rebuild |
| Build fails: the site key cannot be read | The capabilities endpoint is off | Enable the Site group under Memberside → REST API |
| Social sign-in works in preview, not on the phone | The signing SHA-1 is not registered | Android signing |
| Registration works, sign-in then refused | The account needs approval or email confirmation | Check its status in WordPress |
| Terms & Conditions is on, and no checkbox appears | No page is chosen, the Terms & Conditions endpoint group is off, or the installed app predates the feature | Choose a page, enable the group under Memberside → REST API, and rebuild |
| The builder shows no Terms & Conditions line | Your site runs a Memberside version from before Terms & Conditions | Update Memberside |
| Members who signed up show a dash in the Terms column | They registered from an app built before the feature, or through a social button on a login screen | Rebuild the app, and offer social buttons on the register screen |
| Ultimate Member’s extension checkbox is missing from Register | The Memberside service is on, so its wording replaces the extension’s | Expected. Switch the service off to use the extension’s wording |