Summary

MAM_Account_Code_Manager (includes/account-code/) is the centralized owner of the local-app-account_code option — the customer enrollment ID that ties a WordPress site to a customer record on the WPMAM (Tiny Screen Labs) enrollment server.

This is one of the explicitly frozen public contracts in the codebase: ~2K customer sites have a value persisted, the mobile apps reference it, and the publish pipeline depends on it.

Public API

// Read (with transient cache)
$code = MAM_Account_Code_Manager::get();

// Write (only legitimate write path)
MAM_Account_Code_Manager::set( $new_code );

// Force a re-fetch from the enrollment server
MAM_Account_Code_Manager::refresh();

// Verify against WPMAM
$ok = MAM_Account_Code_Manager::verify();

All reads/writes go through this class. Direct get_option('local-app-account_code') reads still work (legacy callers do this everywhere) but writes must go through the manager.

Enrollment server handshake

The setup wizard (includes/setup-wizard/mam-site-enrollment.php) handles the initial enrollment:

1. POST to the WPMAM enrollment endpoint with the site URL
2. Receive the assigned account code
3. MAM_Account_Code_Manager::set( $assigned_code ) persists it
4. Set local-app-onboarding-status to track wizard progress

Subsequent verifications (on the publish page, on plugin entitlement checks) compare the local value against what WPMAM has on file.

Transient cache

MAM_Account_Code_Manager::get() caches the option value in a transient to avoid repeated DB reads. The cache is invalidated on set().

For the enrollment server’s view (used by verify()), there’s a separate transient with a longer TTL — verifying on every page load would otherwise hammer the WPMAM endpoint.

Graceful degradation

The enrollment server can be unreachable (network blip, WPMAM maintenance window). The manager exposes hooks for graceful degradation:

// Override the verify result when the server is unreachable
add_filter( 'mam_account_code_verify_fallback', function ( $default ) {
    // e.g., assume "still valid" during planned maintenance windows
    return true;
}, 10 );

By default, an unreachable enrollment server produces a soft warning on the publish page rather than a hard block.

What references the account code

Related options

Hooks

Frozen contract callout

local-app-account_code is frozen — do not rename. Concretely:

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

Encryption-at-rest is a tracked hardening task. Today the option is plaintext.

Gotchas

• Write only through MAM_Account_Code_Manager::set(). Direct update_option('local-app-account_code', ...) bypasses the transient cache and the side-effect hooks.
• Don’t auto-correct mismatches. A drift between local and WPMAM means contact support — auto-correcting risks rerouting publishes to the wrong customer’s App Store account.
• Verify is cached. A 10-minute window where the WPMAM record changed but the verify cache is still warm shows the old result. Use refresh() to bust both.
• Plaintext storage. Tracked hardening item.

Related articles

• Recipe: Customer enrollment and account code
• Recipe: Publish your app to iOS and Android
• Hook: mam_plugin_entitlement
• Frozen public contracts reference

Metadata