Signature

POST | GET  /wp-admin/admin-ajax.php

Action:    local_app_get_phone_data   (frozen — older mobile clients)
   OR:    mam_get_phone_data          (modern alias — same handler)

Auth:      both (logged-in + nopriv)
Handler:   mam_get_phone_data() → MAM_Phone_Data_Pipeline::run()
Response:  JSON envelope (50–200 KB typical)

⚠️ Frozen public contract — do not rename. Both action names are observed by deployed mobile clients. Do not introduce a third alias.

Purpose

The single entry point the mobile app uses to fetch the entire screen-graph for the current user — buttons, layouts, forms, notifications, content sections, sibling-plugin payloads. Every cold app launch and many in-app refreshes hit this endpoint.

Request payload

The pipeline tolerates additional unknown params — they’re passed through to subscribers via $_REQUEST.

Response payload

{
  "user": { "id": "0", "role": "anonymous", ... },
  "settings": { ... },
  "main_button_array": [ ... ],
  "left_button_array": [ ... ],
  "tab_bar_settings": { ... },
  "form_data": { ... },
  "nonce": "<wp-nonce>",
  "ajax_url": "...",
  "home_cats": { ... },
  "notifications": [ ... ],
  "favorites": [ ... ],
  ...sibling-plugin keys
}

See Mobile JSON shape for full per-section conventions.

Triggers

The handler runs the four-phase pipeline (see Phone data pipeline phases):

1. phase_auth — identity hydration
2. phase_settings — settings + cache + short-circuit check
3. phase_content — button loop + form data + sibling-plugin injection
4. phase_finalize — home_cats + output cleanup

Hooks fired during the pipeline (selected — see Phone data pipeline phases for the full list):

• mam_local_app_data (short-circuit)
• mam_get_phone_data_before_send (~70 subscribers)
• mam_main_check_initial_form
• mam_app_settings_get_buttons
• mam_tab_manager (per-button)
• mam_main_add_tab_bar_item_{slug} (per-tab)

When called as PHP (not AJAX)

$data = mam_get_phone_data( $return_data = true, $single_button_id = false );

Some sibling plugins call this directly to assemble the array without sending HTTP. The pipeline runs the same phases; the response is returned instead of wp_send_json‘d.

$single_button_id (when set) restricts the response to a single button’s data — used for cache-warming and admin debug surfaces.

Performance

• Cold call (no cursor): 50–200 KB response, builds full payload, hits ~70 subscribers, ~30+ DB queries
• Cursor hit (no changes): sections previously sent serve as null (“keep your cache”) — total response ~5–20 KB
• Cloning admin: bypass_caching = true, full rebuild every request
• Snapshot regression harness at tests/snapshot/snapshot-phone-data.php captures fixtures for diff verification

Gotchas

• Frozen contract. Don’t rename the action, the handler, or the response shape.
• Both action names are alive. Deployed mobile clients call local_app_get_phone_data; modern callers can use mam_get_phone_data. Both route to the same handler.
• Unauthenticated calls produce a payload. The pipeline always returns something — anonymous users see the public layout. Don’t assume a logged-in user.
• Cursor is a frozen behavior. A subscriber that ignores the cursor and rebuilds its section every request defeats the cache for the entire response.
• The response is JSON, not HTML. Direct echo from a subscriber corrupts the payload. Use $data_array['my_key'] = ... only.

Related articles

• Phone data pipeline overview
• Phone data pipeline phases
• Mobile JSON shape
• Cursor cache mechanism
• Frozen public contracts reference
• Hook: mam_get_phone_data_before_send
• Hook: mam_local_app_data

Metadata