Goal

Understand what local-app-account_code is, how it gets populated, why every publish action verifies against the WPMAM enrollment server, and what to do when verification fails.

Background

local-app-account_code is the customer enrollment ID — the string that ties a WordPress site to a specific customer record on the WPMAM (Tiny Screen Labs) enrollment server. It is the most-frozen option in the codebase: roughly 2K customer sites have a value persisted, the mobile app references it, and the publish pipeline uses it to route iOS/Android builds to the right App Store Connect / Play Console accounts.

It is owned by MAM_Account_Code_Manager (includes/account-code/). Every read and write goes through this class. The manager:

• Caches the value in a transient
• Provides graceful-degradation hooks for enrollment-server unreachability
• Is the only legitimate path to mutate the option

Reading the option directly with get_option('local-app-account_code') is allowed (legacy callers do it everywhere), but writing it directly is not.

Steps

1. Inspect the current value

SELECT option_value FROM wp_options WHERE option_name = 'local-app-account_code';

Or in PHP:

$code = MAM_Account_Code_Manager::get();

A populated value is a non-empty string assigned by the enrollment server. An empty value means the site has not yet been enrolled.

2. Run the setup wizard

Mobile App Manager → Setup Wizard is the on-ramp for new sites. It:

1. Calls the WPMAM enrollment endpoint with the site URL
2. Receives an account code
3. Persists it via MAM_Account_Code_Manager::set()
4. Sets local-app-onboarding-status to track wizard progress

If the wizard fails, the most common causes are:

• The site URL isn’t reachable from the WPMAM enrollment server (basic auth, IP allow-list, dev environment behind VPN)
• The enrollment server is temporarily unreachable
• The site URL doesn’t match a record Tiny Screen Labs has on file (contact support)

3. Verify on the publish page

Mobile App Manager → Publish Your App runs verify_account_code() on every page load. The check:

1. Reads local-app-account_code from the local site
2. Calls WPMAM with the site URL
3. Compares — if WPMAM has a different code (or no code) for this URL, the page surfaces the mismatch

⚠️ Verification is a guard, not a fix. If the codes drift, the publish UI will show the mismatch but won’t auto-correct. This is customer-support territory — a mismatch usually means the site was migrated, cloned, or the WPMAM record needs to be updated by Tiny Screen Labs.

4. Handle a missing or wrong code

If the code is missing or wrong:

1. Don’t manually edit the option — MAM_Account_Code_Manager::set() is the only legitimate write path, and even that should be triggered by a re-enrollment, not by hand.
2. Contact Tiny Screen Labs support with the site URL and (if known) the customer name.
3. Support will issue a fresh enrollment which re-populates the option through the wizard’s enrollment endpoint.

What references the account code

Frozen contract callout

local-app-account_code is one of the explicitly frozen public contracts:

• ~2K customer sites have a value persisted today
• Customer mobile apps in the field reference it
• The publish pipeline depends on its presence
• Renaming requires a coordinated migration of every site, every app build, and the WPMAM enrollment server

Frozen contract — do not rename. All writes route through MAM_Account_Code_Manager. Encryption-at-rest is a tracked hardening task; today the option is stored plaintext.

Verification

• MAM_Account_Code_Manager::get() returns a non-empty string
• The publish page does NOT show a “WPMAM disagrees” warning
• The setup wizard’s onboarding-status indicator shows enrollment as complete

Related articles

• Recipe: Build an app end-to-end
• Recipe: Publish your app to iOS and Android
• Frozen public contracts reference
• Hook: mam_plugin_entitlement

Metadata