Goal

You can see a button, tab, menu item, or screen in your app — but a real user signed in under a particular role tells you it’s missing. This guide walks you through the most common cause behind that gap: content scoped to one role but not another, and the checks that track it down.

Here’s the single most important thing to understand up front: what you see as an admin isn’t necessarily what a real user in a role sees. MAM Suite stores app content per role. When you preview the app, you’re usually previewing one specific role’s content, and an admin previewing in “cloning” mode gets treated differently from an ordinary user. That gap explains most “it works for me” reports.

Prerequisites

• Admin access to Mobile App Manager in WordPress.
• Knowledge of which role the affected user actually has (Subscriber, a custom role from a sibling plugin, or anonymous if they are not logged in).
• The affected user’s report of where the content is missing — a main tab, a left-menu entry, or a button on a screen. This narrows the search.

Not sure of the user’s role? Open Users in WordPress and check their profile, or just ask them whether they’re signed in at all. A user who isn’t logged in falls into the anonymous role, which almost always sees a different content set.

Background: how role scoping works

MAM Suite works out what content and settings to show through a cascade, checking from most specific to least specific:

1. Per-button settings, stored inside the button’s own record (for example a visible flag or a require_login flag on that button).
2. Per-role values, stored under a role-specific variant of the option key (convention: <global-key>_<role>). App buttons themselves are stored per role and per location — a Subscriber’s tab bar and an admin’s tab bar are genuinely different rows of data.
3. Global values, the site-wide default with no role suffix.
4. The built-in default.

The first match wins. Since the navigation buttons a user sees are pulled for their role, content you built while previewing one role simply won’t exist for another role — unless you built it there too, or cloned it across (more on that below).

Two MAM-specific roles matter here:

• anonymous — an unauthenticated visitor. Logged-out users see the anonymous content set, full stop.
• cloning — an admin previewing the app as another role. The canonical flag is MAM_Current_Request::is_cloning(). A cloning admin is handled differently from a real user on purpose — which is exactly why content can show up for you and not for them.

Steps

1. Confirm whether you were previewing as a cloning admin

Start here — it’s the most common trip-up. If you set up the content while signed in as an administrator, you may have been viewing the app in cloning mode — an admin previewing as another role. Cloning turns on via a flag (admin_is_cloning) stored on the cloned user’s WordPress profile, holding the previewing admin’s user ID as its value. Code paths that gate on role check is_cloning() first, so a cloning admin can see content that a genuine member of that role never would.

To rule this out, test as a real user rather than as a cloning admin:

• Sign in to the app (or a fresh app session) with an actual account that has the affected role, or
• Stop cloning (clear the admin_is_cloning flag on the cloned user) and re-load the app.

If the content disappears once you stop cloning, it was never built for the real role — move on to step 2.

2. Identify the affected user’s exact role

Open the affected user’s profile under Users and note their role. Then confirm that role is actually permitted to use the app — MAM gates each WordPress role with a per-role “allowed to manage” option (mam-user-roles-to-manage-<role>). If that role is set to “no,” users in it can be rejected at login or shown nothing at all, no matter how the buttons are configured.

Check this under Mobile App Manager → User Roles settings, where each role has a yes/no dropdown.

3. Compare the per-role content for that role against your own

Remember, app buttons are stored per role and per location — main tab bar, left menu, or a given screen. Open App Setup and switch the role/preview selector to the affected user’s role instead of your own admin role.

• Not present for that role? It was built for a different role — head to step 5 to copy it across.
• Present for that role? The content exists but something’s hiding it — go to step 4.

4. Check the per-button visibility and login gates

If the content exists for the role but still won’t render, look at the button’s own settings — two per-button flags are the usual culprits:

• visible — when this isn’t set to on, the button stays hidden even though it exists. Tab-bar and layout entries get skipped whenever visible is not on.
• require_login — when this is set, the button only renders for a signed-in user. A logged-out (anonymous) user, or a session that’s dropped its login, won’t see a login-gated button. This is a very common reason a button “works for the admin” (always logged in) but not for a visitor.

Confirm the affected user is actually authenticated. If the report is about the anonymous role, a require_login button is expected to be hidden — that’s working as designed.

5. If the content is missing for the role, clone it across

Good news: once you’ve confirmed the content exists for one role but not the affected role, you don’t have to rebuild it by hand. MAM can clone a role’s content to another role for a given location. In the role/content area of App Setup, choose the location, pick the role to copy from, and apply it to the target role.

⚠️ Cloning replaces the target role’s content for that location — the existing buttons for the target role and location are deleted before the source role’s buttons are copied in. Make sure you’re copying into the role that’s actually missing content, and that you’re not overwriting something you want to keep. If in doubt, jot down the target role’s current buttons first.

After cloning, re-test as a real user in the target role (step 1) to confirm the content shows up now.

6. Re-verify per-role settings, not just buttons

Buttons are the case you’ll see most often, but the same per-role cascade applies to settings too — radius, layout, and the like. A setting you configured globally or for one role may resolve to a different value for the affected role. If it’s a behavior that differs rather than a missing button, check whether that setting has a per-role override for the affected role that doesn’t match yours.

Quick checklist

• [ ] I tested as a real user in the affected role, not as a cloning admin.
• [ ] The affected role is permitted to use the app (User Roles settings).
• [ ] I compared App Setup content with the role selector set to the affected role.
• [ ] The button’s visible flag is on.
• [ ] The button’s require_login flag matches the user’s login state (and the user is actually signed in).
• [ ] If content was missing for the role, I cloned it across and re-tested.

Related

• Per-button and per-role settings — how the cascade resolves per-button, per-role, and global values.
• User roles, login, and cloning — what cloning is and how is_cloning() changes behavior.
• Settings cascade overview — the order in which scoped settings resolve.

What’s next

If content is correct per role but a specific user still sees nothing, the problem is more likely authentication or session state than role visibility. Confirm the user can log in, then check the login and session troubleshooting articles.