What it does

mam-gravity-forms-manager is the bridge between Gravity Forms and the MAM Suite form pipeline. It does not add an admin UI of its own. Instead, it teaches MAM Suite how to read Gravity Forms as a form source and how to fan a Gravity Forms web submission back out to MAM consumers.

There are two distinct flows the plugin handles:

1. App-submitted forms — a mobile app submits form data through the MAM pipeline. The plugin uses GFAPI::add_entry() to create a Gravity Forms entry from that data and GFAPI::send_notifications() to trigger every notification the GF form has configured. The app sees a normal MAM form result; the WordPress site sees a normal Gravity Forms entry, including in Forms → Entries.
2. Web-submitted forms — when a user fills out a Gravity Form on the WordPress site (not in the app), the plugin’s gform_after_submission listener maps the entry’s field values to a custom-post-type post, saves them as post meta, and fires mam_for_gravity_forms_web_form_result_form_{form_id} so a downstream plugin (e.g. mam-special-offers, mam-geodirectory) can finish the job.

The plugin is extension-first. Most apps don’t need to touch it directly — they install it and another plugin (Special Offers, GeoDirectory, Contact Form’s Gravity Forms path) does the consuming.

Where it appears in the app

The plugin itself renders no UI in either WP admin or the mobile app. Its presence shows up indirectly:

• In Mobile App Manager → App Settings, any dropdown that asks “which form?” (e.g. for Special Offers, Edit Listing, User Profile) is populated with all active Gravity Forms because of this plugin’s mam_form_manager_get_forms_from_plugins handler.
• In the mobile app, a screen wired to a GF form ID renders the form’s fields using MAM’s renderer. The form definition is fetched by ID via this plugin’s mam_form_manager_get_from_plugins handler.
• In Forms → Entries (Gravity Forms), every app-submitted entry shows up alongside web entries. There is no “submitted from app” badge — the entry looks identical to a web one.

Requirements

• WordPress 6.3+
• PHP 8.1+
• MAM Suite with mam-main 1.9.1 or later
• Gravity Forms (any active license)
• MAM Suite plugin entitlement for mam-gravity-forms-manager

If GFAPI is not available — Gravity Forms is deactivated or missing — the plugin’s GF-specific methods become no-ops. The plugin will not error, but no GF forms will appear in MAM dropdowns and no entries will be created. See Recipe: Activate the plugin.

Setup paths

The plugin’s behavior depends on which other MAM plugins are installed and which GF forms they register against mam_gf_get_form_settings. The two common shapes:

You don’t pick a path explicitly — it’s determined by which downstream plugins are active and what they register.

Hooks exposed

This plugin also handles four MAM Suite hooks that originate in mam-main:

The four mam_form_manager_* hooks are documented in mam-main‘s reference; they are listed here only so it is clear how this plugin participates in the MAM form pipeline.

Data flow — web submission

gform_after_submission (Gravity Forms)
  └── mam_gf_submit_web_form::after_submission( $entry, $form )
        ├── Gate: has_filter( 'mam_for_gravity_forms_web_form_result_form_{form_id}' )
        │         └── Exit early if no consumer is registered
        ├── apply_filters( 'mam_gf_get_form_settings' )       ← provider hook
        │         └── Returns the field slug→GF index mapping
        ├── Map $entry values into a $values array
        ├── wp_insert_post() or wp_update_post()              ← CPT from settings
        ├── update_post_meta() per mapped field
        └── apply_filters( 'mam_for_gravity_forms_web_form_result_form_{form_id}',
                           $form_id, $post_id )               ← outbound hook

The plugin itself does not know what a “Special Offer” or a “Listing” is. The CPT, the post title/content composition, and the field slugs are all supplied by the consumer through mam_gf_get_form_settings. See Hook: mam_gf_get_form_settings.

Data flow — app submission

Mobile app POST
  └── MAM Suite form pipeline (mam-main)
        └── do_action( 'mam_form_manager_send_notifications', $entry, $form )
              └── mam_gravity_forms::mam_form_manager_send_notifications()
                    ├── GFAPI::add_entry( $entry )
                    ├── GFAPI::get_entry( $entry_id )
                    └── GFAPI::send_notifications( $form, $saved_entry )

The app-submission flow does not call mam_for_gravity_forms_web_form_result_form_{form_id}. That filter is exclusively for the web flow. App submissions that need post-processing use mam_gravity_forms_after_form_processed_{form_id}, which lives in mam-main.

Common tasks

• Activate the plugin and confirm GF is wired up → Recipe: Activate the plugin
• Use a Gravity Form to back a feature in your mobile app → Recipe: Add a Gravity Form to your app
• Turn a web Gravity Form submission into a custom post → Recipe: Route a web submission to a custom post type
• Register a new field-mapping for a custom feature → Hook: mam_gf_get_form_settings
• React to a web form submission in your own plugin → Hook: mam_for_gravity_forms_web_form_resultform{form_id}

Verification

This article was last verified against:

• Plugin: mam-gravity-forms-manager v2.3
• mam-main v1.9.1+ (required)
• Gravity Forms (required)
• Reference consumers: mam-special-offers, mam-geodirectory, mam-contact-form

Re-verify whenever the entitlement gate in mam_gravity_forms::__construct() changes, the mam_form_manager_* hook contract changes in mam-main, the gform_after_submission handler in includes/submit-web-form.php changes its post-creation order, or the mam_for_gravity_forms_web_form_result_form_{form_id} filter signature is altered.

Related articles

• Recipe: Activate the plugin
• Recipe: Add a Gravity Form to your app
• Recipe: Route a web submission to a custom post type
• Hook: mam_for_gravity_forms_web_form_resultform{form_id}
• Hook: mam_gf_get_form_settings

Metadata