What it does

forms-manager (includes/forms-manager/) bridges Gravity Forms into the mobile app. Customer admins build forms in WP using Gravity Forms; this subsystem caches them, transforms them into a mobile-app-renderable shape, processes app-side submissions, and routes results back through the notification dispatcher.

The five primary responsibilities:

1. Form discovery — pulls Gravity Forms definitions plus forms registered by sibling plugins (mam_form_manager_get_forms_from_plugins)
2. Caching — serialized form definitions cached in options (mam-form-cache-*) to avoid repeated GF API calls during phone-data builds
3. Mobile transformation — converts GF schema into mobile-app field types, fires per-field-type filters so sibling plugins can extend
4. Submission handling — receives app submissions via AJAX, runs validation, fires post-process filters and mam_form_manager_send_notifications
5. Phone manager — separate concern: validates SMS phone numbers used for verification codes and notification opt-in

Public surface

AJAX endpoints

The app’s form-submission AJAX is registered separately by mam_gf_submit_app_form.

Hooks fired (extension surface)

Form discovery

Pre-send transformation

Submission lifecycle

Admin UI

Reads / writes

• Owned options: mam_forms_db_version, mam_gravity_forms_db_version, mam_generated_forms, mam_gd_forms, mam_forms_colors_defaults_set, mam_forms_colors_defaults_set_{role}, mam_theme_color_dark, mam_theme_color_light, mam-for-gf-form-field-display-*
• External: Gravity Forms native tables + wp_postmeta
• Phone validation: Optional integration with a phone-number validation service if configured

Gotchas

• Cache invalidation is the hard part. Form schemas are cached aggressively because the phone-data pipeline rebuilds JSON on every app load. A stale cache means admins update a form and the app keeps showing the old version. The cache manager keys by form id + relevant settings; if you add a setting that changes form output, invalidate the cache when it’s written.
• Custom field types require two hooks — mam_form_manager_process_field_type_{type} to translate at build time, AND a corresponding submit-time handler so submissions of that field validate. Forgetting one breaks the round trip silently.
• Per-form dynamic hooks are the per-form override pattern. If you need a customer-specific transformation, hook mam_for_gravity_forms_form_submitted_{their-form-id} rather than the generic version.
• mam_form_manager_send_notifications is the contract between forms-manager and notifications-manager. Don’t fire mam_notification_send_message directly from form-handling code — go through this action so admin overrides can intercept.
• mam_gf_user_profile_submit_title etc. are user-roles hooks that flow into this subsystem — user profile screens are rendered as forms.

Related articles

• Plugin: mam-main
• Form submission lifecycle
• Custom field types
• Form cache and invalidation
• Phone validation
• Hook: mam_form_manager_get_forms_from_plugins
• Hook: mam_form_manager_process_fieldtype{type}
• Hook: mam_form_manager_send_notifications
• Hook: mam_for_gravity_forms_form_resultform{id}

Metadata