Signature

apply_filters( 'mam_gf_get_form_settings', array $settings_array );

Returns: array — the augmented $settings_array. You must return it.

Purpose

Provider hook. mam-gravity-forms-manager consumes this filter (it does not register a callback against it itself); other plugins add entries to its return value to tell the manager:

• “GF form whose ID is in option X is mine.”
• “When that form is submitted on the web, write a post of CPT Y.”
• “Use these field slugs as post_title, these as post_content.”
• “These are the slugs and the GF field IDs they correspond to.”

It is the configuration source for the entire gform_after_submission flow. If a form’s submission isn’t doing anything, the first place to look is whether a mam_gf_get_form_settings entry exists for that form.

mam-special-offers, mam-geodirectory, and the GF-path of mam-contact-form are all subscribers. So is your custom integration plugin, if you have one.

When it runs

Twice per web submission, both inside mam_gf_submit_web_form::after_submission():

1. First call — to read each entry’s data.fields so the plugin can map GF entry values into a $values array keyed by your slug.
2. Second call — to read each entry’s data.cpt, data.post_title, and data.post_content so the plugin can build the post and decide which CPT to write to.

Both calls pass an empty array as the seed; both expect the same return. Make sure your callback is idempotent and cheap — it runs at minimum twice on every submission, and is also called by other MAM Suite admin pages that want to enumerate registered forms.

Entry shape

[
    'category'    => 'general',                     // free-form grouping label
    'title'       => 'My App: Offers',              // human-readable, surfaces in admin lists
    'variable'    => 'none',
    'type'        => 'gravity_form',                // always this value for this hook
    'id'          => 'my_app_offers_offers_form',   // ★ option key, NOT a form ID
    'environment' => 'backend',                     // 'backend' | 'frontend' | 'both'
    'data' => [
        'cpt'          => 'offer',                  // post_type to write to
        'post_title'   => [ 'offer-title' ],        // slugs to concatenate into post_title
        'post_content' => [ 'description' ],        // slugs to concatenate into post_content
        'fields' => [                               // slug → GF-field-id mapping
            [ 'id' => 1, 'slug' => 'offer-title',  'title' => 'Offer Title',  'type' => 'text' ],
            [ 'id' => 2, 'slug' => 'description',  'title' => 'Description',  'type' => 'textarea' ],
            // ...
        ],
    ],
],

The two unusual keys:

id (option key, not form ID)

The id field is the WordPress option key that holds the GF form ID for this install. The plugin compares incoming submissions like this:

if ( get_option( $field['id'] ) == $entry['form_id'] ) { /* this entry matches */ }

So an admin (or your install routine) must call update_option( 'my_app_offers_offers_form', 42 ) to point your entry at the actual GF form on this site. This indirection is what lets the same plugin work across sites where the form has different IDs.

data.fields[].id and update_option()

For each field in data.fields, the GF field index is also stored in an option, named {root}{slug}_{field-slug}. Look at any reference subscriber and you’ll see this pattern in their callback:

foreach ( $fields as $field ) {
    update_option( "{$root}{$slug}_" . $field['slug'], $field['id'] );
}

The plugin then reads each field’s index back out via get_option( $root . $slug ) when it builds the $values array. This is the same indirection as the form ID — it lets the same code work across installs where the GF field IDs differ.

Example: register a single-form integration

add_filter( 'mam_gf_get_form_settings', 'my_app_register_offers_form' );

function my_app_register_offers_form( $settings ) {
    $root   = 'my_app_offers_';
    $slug   = 'offers_form';
    $fields = [
        [ 'id' => 1, 'slug' => 'offer-title',  'title' => 'Offer Title',  'type' => 'text' ],
        [ 'id' => 2, 'slug' => 'description',  'title' => 'Description',  'type' => 'textarea' ],
        [ 'id' => 3, 'slug' => 'start-date',   'title' => 'Start Date',   'type' => 'date' ],
        [ 'id' => 4, 'slug' => 'end-date',     'title' => 'End Date',     'type' => 'date' ],
        [ 'id' => 5, 'slug' => 'post-id',      'title' => 'Offer ID',     'type' => 'hidden' ],
    ];

    // Persist each field's GF index into its option key.
    foreach ( $fields as $field ) {
        update_option( "{$root}{$slug}_" . $field['slug'], $field['id'] );
    }

    $settings[] = [
        'category'    => 'general',
        'title'       => __( 'My App: Offers', 'my-app' ),
        'variable'    => 'none',
        'type'        => 'gravity_form',
        'id'          => $root . $slug,
        'environment' => 'backend',
        'data' => [
            'cpt'          => 'offer',
            'post_title'   => [ 'offer-title' ],
            'post_content' => [ 'description' ],
            'fields'       => $fields,
        ],
    ];

    return $settings;
}

Pair this with update_option( 'my_app_offers_offers_form', 42 ) (where 42 is the actual GF form ID on this install) and a callback on mam_for_gravity_forms_web_form_result_form_42. See Recipe: Route a web submission to a custom post type for the full setup.

Example: register multiple forms in one callback

add_filter( 'mam_gf_get_form_settings', 'my_app_register_all_forms' );

function my_app_register_all_forms( $settings ) {
    $settings[] = my_app_offers_settings_entry();
    $settings[] = my_app_listings_settings_entry();
    $settings[] = my_app_reviews_settings_entry();
    return $settings;
}

Each entry stands on its own — there is no parent grouping. The plugin iterates the array linearly and matches each entry against the incoming form_id.

Gotchas

• id is an option key, not a form ID. This is the most common confusion when reading existing consumer code. The actual form ID lives in get_option( $entry['id'] ). Always.
• data.fields[].id is the GF field ID, not an array index. It must match the GF field’s id property exactly. If the form is rebuilt or fields are added before existing ones, the IDs may shift — re-run your install routine that calls update_option().
• The filter runs twice per submission. And again on admin pages that enumerate forms. Don’t query the database, hit an external API, or write to logs in your callback. Cache anything expensive.
• Field types beyond text/textarea/select need extra handling. The plugin special-cases checkbox and radio to read the joined inputs[] keys instead of a single field index. Other types — address, name, list, multifile — will get the raw GF index value, which may not be what you want. Test each field type individually.
• zero field IDs are dropped. If update_option() for a field’s slug ever returns 0 (because the option was never set), the plugin’s isset( $form['fields'][ $field_index ] ) check will skip the field. You’ll silently lose that field’s value. Always confirm update_option() ran with a non-zero ID.
• post-id is a special slug. When the plugin builds the $values array, it looks for post-id and uses its value as the update target. You can omit it on a pure-create flow; include it (with a hidden GF field) for an edit flow.
• Returning a non-array kills every other entry. Forgetting return $settings; strips the array. Don’t return early without returning the original.
• environment is informational here. The web-submission flow doesn’t gate on this value. Some admin UIs use it for grouping; the post-creation logic ignores it.

Verification

This article was last verified against:

• Plugin: mam-gravity-forms-manager v2.3
• Source: mam-gravity-forms-manager/includes/submit-web-form.php
• Reference subscriber: mam-special-offers/includes/mam_special_offers_form_manager.php (mam_gf_get_form_settings())

Re-verify whenever the entry shape (id, category, type, environment, data.cpt, data.post_title, data.post_content, data.fields) changes; the option-key indirection (get_option( $entry['id'] ) == $entry['form_id']) changes; the special-cased field types (checkbox, radio) in after_submission() change; or the redundant double-apply_filters() call inside after_submission() is consolidated.

Related articles

• Plugin overview: mam-gravity-forms-manager
• Recipe: Route a web submission to a custom post type — uses this hook to register an integration
• Hook: mam_for_gravity_forms_web_form_resultform{form_id} — the per-form result hook that fires after the post is created

Metadata