Choose how users sign in: email validation, Google, or sign-up codes

Goal

Before anyone can use your app, they need a way in. MAM Suite gives you three ways to let them through the door, and you’re free to offer more than one at a time:

  • Email — users create an account with an email address and password.
  • Apple and Google — users sign in with their existing Apple or Google identity instead of a password.
  • Enrollment / sign-up codes — users enter a pre-issued code during sign-up, which you can use to gate access or attach them to a group.

You can also ask for email validation on top of any of these, so a new account only goes live once the user confirms a code sent to their inbox. Work through this article and you’ll end up with a login screen offering exactly the sign-in options you want, Google login and code-gated sign-up included if you need them.

These options mostly live in one place because they all belong to the same screen — the Login button’s settings. (The one exception is the enrollment-code setup in step 6, which lives on the global App Settings page under Misc.) It’s normal to switch several of these on together — a typical app might allow both email and Apple/Google, hide the password-reset link, and require email validation.

Before you begin

  • You are signed in to WordPress as an administrator.
  • Your app has a Login button placed in its navigation. The login settings described here belong to that button, so the app needs one before the options appear. If you are not sure, check App Navigation for a Login item in either the main tab bar or the left menu.
  • For Google sign-in only: a Google Cloud project with OAuth credentials, so you can copy a client ID. You can set the other options first and come back to this.

These settings are global — they apply to every user role, not per role.

Steps

1. Open the Login button’s settings

In the MAM dashboard, open your app’s settings and select the Login button (or the Login Settings group). You’ll find most of the options below waiting there together — the enrollment-code settings in step 6 are the one exception, tucked into the global App Settings → Misc group instead.

If you don’t see a Login button to configure, add one in App Navigation first, then return here.

2. Decide whether sign-in is required

  • Require Login? — When on, the login screen greets users first, and they have to sign in (or create an account) before they can reach any content. When off, the app opens straight into its content and signing in becomes optional — users can still log in later, whenever they want a feature that needs an account, like favorites, orders, or a profile.

Switch this on for member-only apps. Leave it off when most of your content is public and only a handful of features need an account behind them.

3. Choose your sign-up methods

Turn on each method you’d like to offer — nothing stops you from enabling more than one.

  • Allow user to sign up with Email — Shows the Sign up with Email option, letting new users create an account with an email and password. Turn this off if you’d rather stick to social login or pre-issued codes.
  • Allow user to sign up with Apple and Google — Shows Sign in with Apple and Sign in with Google buttons, so users can sign in with an Apple or Google identity they already have instead of typing an email and password.

If you turn email off, double-check that at least one other method is still on — otherwise users are left with no way in at all.

4. Configure Google sign-in (only if you enabled Apple/Google)

Turning on Allow user to sign up with Apple and Google is all Apple needs — it works right away. Google asks for one more thing first, a client ID — the credential that tells Google’s servers your app is allowed to use its sign-in:

  1. In the Google Cloud Console, open your project’s OAuth credentials and copy the client ID.
  2. Back in the Login settings, paste it into Google Login API.

Skip this and the Google button still shows up, but tapping it won’t actually sign anyone in. (Apple needs nothing entered here.)

5. Require email validation (optional)

  • Require email validation during account setup — When on, a new account created with email doesn’t activate until the user confirms a code emailed to them during sign-up. It’s one extra step, but it keeps fake or mistyped addresses from creating accounts.

Turn this on and anyone signing up sees a “we’ve sent you a code” prompt, and has to enter it before they’re logged in — the new account sits as unverified until then. This only applies to the email sign-up path; Apple and Google identities arrive already verified by their provider.

6. Turn on code-gated sign-up (optional)

If you hand out enrollment codes — for members, employees, students, event attendees, and the like — you can put a code field right on the login/sign-up screen. These two settings break the pattern from the rest of this article: they live on the global App Settings page under the Misc group, not on the Login button:

  • Show enrollment code on login screen? — When on, an enrollment-code field appears on the login/sign-up screen.
  • Enrollment code placeholder — The greyed-out hint text inside that field (for example, “Enter your member code”).

Whatever a user types gets captured during sign-up and handed off (via the mam_user_roles_after_create_user filter) so other parts of MAM Suite can act on it — validating the code, say, or attaching the new user to a group. What any given code actually does depends entirely on how your site is set up to handle enrollment codes. Turning this option on just shows the field; the meaning behind each code is defined elsewhere.

Back on the Login button, two more text settings let you fine-tune the wording of the app’s code prompts:

  • Sign Up Code Placeholder — hint text inside the code-entry field during sign-up.
  • Sign Up Code Reminder — short helper text near the field (for example, “Check your email for the code we just sent”).

7. Tidy up the login screen for your chosen methods

A couple of small options keep the screen honest about which methods you’ve actually turned on:

  • Hide Forgot Password Button — Hides the Forgot Password? link. Turn this on for apps that use code-based or social login only, where password recovery doesn’t apply.
  • Login Button Title, Signup Button Title, Send Code Button Title — Custom labels for those buttons (for example, “Sign In”, “Create Account”, “Email My Code”). Leave blank to use the app’s default wording.

8. Save and preview

Save your settings, then open the app in the previewer (or a test device) and see for yourself that the login screen shows the right buttons:

  • Each enabled sign-up method has a button.
  • The Google button completes a real sign-in (not just appears) — this is the quickest way to confirm your client ID is correct.
  • If you required email validation, a fresh email sign-up prompts for the emailed code.
  • If you enabled the enrollment code, the code field appears with your placeholder text.

Notes and gotchas

  • All global. Every option here applies to all roles — there’s no per-role sign-in configuration on these screens.
  • The Google button can appear without working. Enabling Apple/Google shows both buttons, but Google won’t actually authenticate anyone until you’ve entered the Google Login API client ID. Always test the button, don’t just eyeball it.
  • Leave a way in. It’s fine to turn off email sign-up, but only once Apple/Google or codes are enabled in its place — never disable every method at once.
  • “Show enrollment code” vs. what the code does. This login option only controls whether the field is shown and the code captured. What that code actually does — gating access, assigning a group — is handled elsewhere in your site’s setup.
  • Getting started: Login and accounts — the higher-level tour of how accounts work in a MAM app.
  • Setting up your app’s navigation — placing the Login button so these settings appear.
  • App Setting Reference: require_login, sign_up_with_email, sign_up_with_google, sign_up_with_email_validation, login_google_client_id, allow_code_on_signup, and the login code/button label settings.

What’s next

With sign-in configured, it’s time to make the login screen look like yours — background color or image, top logo, button colors, and your Terms and Conditions message and link, all waiting in that same Login Settings group.

Was this article helpful?
Contents

    Need Support?

    Can't find the answer you're looking for? Don't worry we're here to help!