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, a role allow-list, and Cloudflare Turnstile.
Social sign-in
Section titled “Social sign-in”Twenty providers are supported, including Google, Apple, Facebook and GitHub. Configure them on the feature, and members get provider buttons on the sign-in screen.
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.
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 Manage Social Connections.
Signing in, including a social provider
record → src/assets/media/sign-in.mp4
Turnstile
Section titled “Turnstile”Cloudflare Turnstile can protect Default Login and Default Register. It needs both halves of the key pair:
- The site key is compiled into your app.
- The secret key stays on your site and verifies the challenge.
With only the site key set, the challenge renders and every verification fails.
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 |
| 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 |