How replacement tokens (e.g., [user_login], [passwordcode], [order_id]) work in notification templates: per-type token list declared in mam_notification_list, supplied at fire time, substituted by the channel sender.
MAM_Phone_Data_Pipeline is the canonical builder of the mobile app’s JSON payload. 4 phases (auth → settings → content → finalize), state carried by MAM_Phone_Data_Context, ~70 sibling-plugin subscribers via the legacy…
A worked example walking a single form from declaration through submission: the mam_gf_get_form_settings entry, slug→field-id admin mapping, cache pre-warm, dynamic data injection, the three row→form surface patterns, and the submission…
The three patterns a content row can use to open a form: tabbar button, custom_form_array on a row, and content_type=form tap. Each path’s data shape, the iOS resolver site, and…
End-to-end trace of an app form submission: AJAX POST → mam_gf_processing_form → field validation → mam_for_gravity_forms_form_submitted_{id} → result envelope → mam_form_manager_send_notifications.
Can't find the answer you're looking for? Don't worry we're here to help!