The split

mam-main’s forms-manager handles code-based (programmatic) forms as a first-class capability. A site can ship a fully working form system — registration, validation, submission, notifications — with no Gravity Forms installation at all. The sibling plugin declares its fields in PHP, mam-main does the rest.

mam-gravity-forms-manager is the optional Gravity Forms customization layer. Install it when a site needs to:

• Let a non-developer admin tweak form fields, labels, conditional logic, or routing from the WP admin
• Bring an existing Gravity Form (built outside the MAM Suite) into the app
• Use GF features the code-based path doesn’t expose (visual builder, GF entries storage, GF add-ons, etc.)

If the form’s contract is stable and lives in code, you don’t need this plugin. If the customer expects to edit the form in WP, you do.

Comparison

Hybrid forms

The two paths are not mutually exclusive. A common pattern: build the form skeleton in Gravity Forms (so admins can tweak labels and add static fields), but register a code-based wrapper through mam_gf_get_form_settings that:

• Maps GF field IDs to stable slugs (so handlers don’t break when admins reorder fields)
• Injects dynamic dropdown choices at runtime via mam_populate_gravity_form
• Routes submissions to a code-based handler via mam_for_gravity_forms_form_result_form_<ID>

That’s how mam-aquaman-boat-booking and mam-geodirectory operate today.

What this plugin contributes

1. GF web submission routing

When a form is submitted through GF’s web UI (not the app), this plugin catches it via gform_after_submission and dispatches it through a custom filter that mirrors the app-side one. Web submissions land in the same handler shape app submissions do.

// mam-gravity-forms-manager.php
add_action( 'gform_after_submission', array( $after_submission, 'after_submission' ), 10, 2 );

// includes/submit-web-form.php
// → fires: mam_for_gravity_forms_web_form_result_form_<ID>

Sibling plugins register their web-submission handlers exactly like app handlers, just with a different filter name:

add_filter(
    'mam_for_gravity_forms_web_form_result_form_' . get_option( 'mam_aquaman_day_settings' ),
    [ $form_handler, 'save_day_settings_web' ]
);

If your handler should accept both flows, register the same callback on both filter names.

2. GF catalog contribution

This plugin contributes its catalog of GF-backed forms to mam_form_manager_get_forms_from_plugins so that mam-main’s discovery sees them alongside any code-based forms registered by other plugins.

add_filter( 'mam_form_manager_get_forms_from_plugins',
    array( $this, 'mam_form_manager_get_forms_from_plugins' ) );
add_filter( 'mam_form_manager_get_from_plugins',
    array( $this, 'mam_form_manager_get_from_plugins' ), 10, 2 );

3. Nested-form field bridging

GF supports nested-form fields (a field whose value is another form). The mapping from GF’s nested-form structure to the MAM mobile content-class type lives here:

add_filter( 'mam_form_manager_content_class_form',
    array( $this, 'mam_form_content_class_type_form' ), 10, 4 );

4. Notification dispatch wiring

When mam-main fires mam_form_manager_send_notifications after a successful submission, this plugin’s listener forwards the entry into the GF→mam-notifications bridge. That’s how a GF submission can drive a mam_notification_send_message flow without sibling plugins wiring it themselves.

add_action( 'mam_form_manager_send_notifications',
    array( $this, 'mam_form_manager_send_notifications' ), 10, 2 );

What this plugin relies on mam-main for

Treat this list as the contract — mam-gravity-forms-manager doesn’t try to replace any of it.

Decision tree: do I need this plugin?

Does the site admin need to edit form fields/labels in the WP admin?
  → Yes: install mam-gravity-forms-manager + Gravity Forms

Are you bringing in a pre-existing Gravity Form built outside MAM?
  → Yes: install mam-gravity-forms-manager + Gravity Forms

Are you using a GF-only feature (entries storage, visual builder, GF add-ons)?
  → Yes: install mam-gravity-forms-manager + Gravity Forms

Is the form contract fully owned by your plugin (defined in PHP, no admin edits expected)?
  → No: use mam-main's mam_form_manager_get_forms_from_plugins. Skip this plugin

Decision tree: where does my code go?

Walk the question top to bottom. The first “yes” is your answer.

Does it run only on a GF web submission (gform_after_submission)?
  → mam-gravity-forms-manager / your own plugin's handler on
    mam_for_gravity_forms_web_form_result_form_<ID>

Does it run only on an app submission?
  → your own plugin's handler on
    mam_for_gravity_forms_form_result_form_<ID>

Does it need to inject dropdown choices, defaults, or populate_with_key?
  → your own plugin, hook mam_populate_gravity_form (in mam-main)

Does it need to declare a new GF-backed form?
  → your own plugin, hook mam_gf_get_form_settings (in mam-main)

Does it need to declare a new code-based (programmatic) form?
  → your own plugin, hook mam_form_manager_get_forms_from_plugins (in mam-main)

Is it touching the GF schema/storage directly (entry, form fields)?
  → mam-gravity-forms-manager

If you find yourself wanting to modify mam-gravity-forms-manager to add plugin-specific behavior, stop. It’s almost always a filter call from your own plugin instead.

Companion docs to read next

• Activate the plugin — wires the integration on
• Add a form to the app — happy path for GF-backed forms
• Route a web submission — handler shape
• Hook: web-form result
• Hook: get-form-settings
• mam-main forms-manager overview — system-wide context
• mam-main forms providers and extensibility — code-based forms in depth
• mam-main end-to-end cookbook — worked example (uses the GF-backed path)
• mam-main hook reference — every form-manager hook in firing order
• mam-main prefill paths — row-to-form prefill mechanisms

Metadata