Summary

mam-main organizes into 22 subsystems across ~145 PHP files. The shape splits cleanly into three layers:

1. Cross-cutting infrastructure (Phase 1 of the refactor) — request-context, account-code, migrations, repositories. Load-bearing for every other subsystem.
2. Pipelines (Phase 2) — phone-data (mobile JSON), notifications-manager/dispatcher (email/SMS/push). Single entry points for the platform’s two highest-traffic operations.
3. Feature subsystems — app-settings, forms-manager, content-classes, user-roles, push-notification-manager, setup-wizard, publish-app, setcron-manager, plugin-update-manager, plus the smaller subsystems.

Every sibling plugin extends mam-main exclusively through filters and actions. mam-main never imports sibling-plugin classes.

Cross-cutting abstractions

MAM_Current_Request (includes/request-context/)

Per-request context object. Replaces the legacy $mam_user / $mam_user_id / $mam_user_role / $is_cloning globals. Accessed via mam_current_request(). Initialized once per request near the top of the bootstrap; subsystems read identity state from it instead of mutating shared globals.

$req = mam_current_request();
$user_id    = $req->user_id();
$role       = $req->user_role();
$is_cloning = $req->is_cloning();

MAM_Account_Code_Manager (includes/account-code/)

Centralized owner of the local-app-account_code option (frozen public contract — customer enrollment ID). All reads/writes route through this class. Includes a transient cache and graceful-degradation hooks for enrollment-server unreachability.

Encryption-at-rest is not yet implemented; the option remains plaintext.

MAM_Migration_Tasks (includes/migrations/)

Framework for safe option/table renames. Used at boot time only to keep legacy callers (in unmaintained customer-site plugin copies) reading the old keys via alias filters.

Repositories (includes/repositories/)

DB abstraction layer. One repository per owned table. All $wpdb calls against owned tables route through repositories.

Pipelines

Phone Data Pipeline (includes/phone-data/)

Entry points:

• AJAX: local_app_get_phone_data (frozen public contract)
• Function: mam_get_phone_data() (delegates to MAM_Phone_Data_Pipeline::run())

Phases:

phase_auth     →  phase_settings  →  phase_content  →  phase_finalize
identity         load settings,     fire             home_cats injection,
hydration        cache decision,    mam_get_         output cleanup,
                 short-circuit      phone_data_      apply final-block
                 check              before_send,     overrides
                                    inject form_data,
                                    nonce, etc.

State is carried by MAM_Phone_Data_Context. At the legacy filter boundary it converts to/from an array so existing mam_get_phone_data_before_send subscribers keep working untouched.

See Phone data pipeline overview and Phone data pipeline phases.

Notification Dispatcher (includes/notifications-manager/dispatcher/)

do_action('mam_notification_send_message', $msg)
                │
                ▼
   MAM_Notification_Dispatcher::dispatch()
                │
   ┌────────────┼────────────┐
   ▼            ▼            ▼
Email        SMS          Push
Sender       Sender       Sender
   │            │            │
wp_mail()    Twilio       APNs / FCM
or queue     or queue     via MAM_PushDispatcher

Channel routing is driven by the mam_notification_list filter (68+ subscribers). Each registered type declares which channels it supports plus per-channel templates. Queueing decision: count > 10 OR global cron enabled.

See Notifications overview.

Boot order

MAM_Main_Manager::__construct() calls 15 register_*() methods in a fixed order (mam-main.php:503–517):

1. register_core — request context, account code, migrations
2. register_database — repositories, table-existence checks
3. register_app_users — user-roles bootstrap
4. register_user_management — login, profile, phone-code
5. register_forms — Gravity Forms integration
6. register_tab_bar — tab manager filter wiring
7. register_app_settings — admin UI
8. register_push_notifications — APNs/FCM senders, token registration
9. register_notifications — dispatcher hook + admin UI
10. register_publishing — app-submit pipeline
11. register_cron — mail/PN/SMS cron + custom cron registration
12. register_setup_wizard — onboarding + enrollment
13. register_admin_ui — top-level menu + dashboard widgets
14. register_plugin_updates — software entitlements + update checks
15. register_entitlements — per-plugin licensing

The constructor itself contains zero direct add_action/add_filter calls. The crash-reporter loads earlier still, before plugins_loaded, via a top-level include in mam-main.php so it can capture errors during boot.

Dependency graph

─── Cross-cutting (Phase 1) ─────────────────────────────
request-context     ← used by ~everything
account-code        ← enrollment-aware code
migrations          ← boot-time only
repositories        ← consumed by mail-cron, notifications, push,
                      helper-classes, grid-classes

─── Pipelines (Phase 2) ─────────────────────────────────
phone-data          ← called by app-connect; depends on request-context,
                      app-settings, content-classes, forms-manager, user-roles
notifications-manager → repositories, push-notification-manager,
                        mail-cron-manager

─── Feature subsystems ──────────────────────────────────
app-connect            → phone-data
app-settings           → content-classes, helper-classes
user-roles             → app-connect, app-settings, notifications,
                          forms-manager
push-notification-manager → request-context, MAM_Phone_Token_Repository
forms-manager          → app-settings, user-roles, content-classes
setup-wizard           → app-settings, user-roles, plugin-update-manager,
                          account-code
plugin-update-manager  → setup-wizard, support-manager, account-code
publish-app            → app-settings, helper-classes
grid-classes           → repositories, request-context
helper-classes         → app-settings, user-roles, content-classes
content-classes        → app-settings, app-connect, user-roles

Sibling-plugin extension surface

The primary surfaces a sibling plugin reaches for:

Priority conventions for mam_get_phone_data_before_send:

• 1 — base settings
• 10 — default cohort (most sibling plugins)
• 99–100 — late-running enrichments (faceted-search, localize, payment gateways)
• 199 — form-state validation
• 999+ — niche overrides (weather, delivery, payment processors)
• 1000 — MAM_Main_Manager::manage_phone_data (home_cats injection); must run after all priority-<1000 subscribers
• 1001+ — use-case-specific total overrides

See Priority conventions for phone-data subscribers.

Where to add a feature

If your feature crosses subsystem boundaries, the answer is almost always “add a new filter and let subscribers register against it” — that’s how the entire plugin scales.

Verification

This article was last verified against:

• Plugin: mam-main v2.1.11
• mam-main/ARCHITECTURE.md
• mam-main/REFACTOR_PLAN.md
• mam-main/mam-main.php (boot order)

Re-verify whenever a new subsystem is added, a register_*() method is added or reordered in MAM_Main_Manager::__construct(), or a cross-cutting abstraction’s public interface changes.

Related articles

• Plugin: mam-main
• Phone data pipeline overview
• Notifications overview
• Settings cascade overview
• Frozen public contracts reference
• Extending mam-main: developer guide

Metadata