Goal

Add one or more custom fields to a MAM Suite app form — the Contact Us form or the GeoDirectory Add/Edit Listing form — using a PHP filter, so your fields ship as version-controlled code in your own plugin or theme. You never edit a MAM Suite plugin file, so a plugin update won’t overwrite your work.

This how-to also shows how the field’s mobile keyboard (text, email, phone, etc.) is controlled, so a phone number opens the numeric keypad and an email address opens the email keyboard on the device.

Both forms expose a dedicated “add fields” filter. They behave similarly but are not identical — pick the section that matches the form you’re extending.

Prerequisites

• MAM Suite with mam-main activated, plus the plugin that owns the form you’re extending:
  Contact form: mam-contact-form (current release).

• Add/Edit Listing form: mam-geodirectory (current release).

• A place to put your code that loads on every request — a small custom plugin (preferred) or your theme’s functions.php. Do not put it inside a MAM Suite plugin.

• Basic familiarity with add_filter() and returning a modified array.

• For the forms-plugin setup path (either form), access to your forms plugin’s editor and the Mobile App Manager admin screens, since the filter only declares a field slot — you still map it to a real form field. The site can use Gravity Forms (mam-gravity-forms-manager) or Ninja Forms (mam-ninja-forms-manager); this guide’s examples use Gravity Forms, and the Ninja Forms steps are the same in its editor.

Which filter to use

The gf_ in the contact form filter name is historical. The filter is path-agnostic — it applies on the built-in (default) form handler and the forms-plugin path alike, whether the site’s provider is Gravity Forms or Ninja Forms. Do not wrap your callback in an “is Gravity Forms active” check, or you’ll skip your own fields on the default path. Likewise, there is no separate mam_default_* filter to look for; this is the one filter for both paths.

Steps — Contact form

The contact form filter takes the form’s logical field list and lets you append to it. Each entry is a small array, and one of its keys (type) drives the mobile keyboard.

1. Hook the filter

add_filter( 'mam_gf_get_form_settings_fields_contact_form', 'my_contact_form_fields' );

function my_contact_form_fields( $fields ) {
    // Append — never replace — the default fields.
    return $fields;
}

2. Append your field definitions

Each field is an array with five keys. Append to $fields; the default fields occupy IDs 1–6, so start your numeric IDs above that range (a high value like 100+ is safe if you’re unsure).

function my_contact_form_fields( $fields ) {
    $fields[] = [
        'id'                => 100,
        'title'             => 'Account number',
        'slug'              => 'account_number',
        'populate_with_key' => 'account_number',
        'type'              => 'phone',   // numeric keypad on the device
    ];
    return $fields;
}

3. Choose the mobile keyboard via type

The type key carries through to the field definition the mobile app consumes, and the app uses it to pick the on-device keyboard. The defaults model the pattern: email opens the email keyboard, phone opens the numeric keypad, text is the standard keyboard, and textarea is a multi-line text box.

Setting the right type means your field gets the correct keyboard automatically on the default path — no per-field “special handling” step.

4. Always return the array

Forgetting return $fields; strips all default fields silently and breaks the form on both paths. Append, then return.

5. (Gravity Forms path only) Wire the field in the editor

On the default path you’re done — the new field renders the next time the app loads the form, and it’s included in the admin notification. On the Gravity Forms path, the filter only exposes the slug as mappable:

• In Gravity Forms, add the matching field to your contact form.
• Go to Mobile App Manager → Contact Form → Field Settings. Your new slug appears in the mapping dropdowns.
• Map the Gravity Forms field to your slug, then save.
• Submit a test entry and confirm the field appears in the admin notification.

Steps — Add/Edit Listing form

The GeoDirectory filter extends the field list that the Add/Edit Listing form registers, so the new field shows up in the admin field-visibility manager and the runtime knows to look for it. Its entries are simpler — title and slug only.

1. Hook the filter

add_filter( 'mam_geodirectory_add_edit_form_fields', 'my_app_add_listing_field' );

function my_app_add_listing_field( $fields ) {
    return $fields;
}

2. Append your field slot

function my_app_add_listing_field( $fields ) {
    $fields[] = [
        'title' => 'Hours of operation',
        'slug'  => 'hours',
    ];
    return $fields;
}

After this, the field-visibility manager on the GeoDirectory admin settings page includes a row for your field, and its slug becomes part of the form’s expected field set.

3. Wire a Gravity Forms field to the slug

The listing filter does not render a field on its own — it only declares a slot. You must add a Gravity Forms field whose slug matches, then let the per-post-type form mapping pick it up. See Form: Add/Edit Listing for the full wiring (which Gravity Form to attach per post type and how field visibility is toggled).

4. Always return the array

As with the contact form, forgetting return $fields; strips the entire form definition.

Gotchas

• The slug is the contract. It’s the internal identifier and (for the contact form) the replacement key in notifications. Once shipped, renaming it breaks existing data and, on the Gravity Forms path, existing mappings.
• Slugs must be unique. Reusing a default contact-form slug overwrites that field’s behavior — including the auto-population of name, email, and phone from the user’s profile. On the listing form, a duplicate slug means only the last one wins on save.
• These filters run on every load. The contact form filter fires on every form render, every notification-list rebuild, and every submission; the listing filter runs on every admin page load. Keep your callback fast — no external API calls, no database queries. Cache aggressively if you must compute anything.
• Append, don’t replace. Removing default entries breaks the form.
• Don’t gate on Gravity Forms for the contact form. The filter is path-agnostic despite the gf_ name.

Related

• Hook: mam_gf_get_form_settings_fields_contact_form — full reference for the contact form filter, including the default field list and the exact field shape.
• Hook: mam_contact_form_populate_contact — pair with the contact form filter to pre-fill your custom fields with user-profile values.
• Hook: mam_geodirectory_add_edit_form_fields — full reference for the listing form filter.
• Form: Add/Edit Listing — how the listing form is wired per GeoDirectory post type.
• Plugin: mam-contact-form — overview, setup paths, and the mobile JSON contract.

What’s next

If you added contact-form fields and want them pre-filled when a signed-in user opens the form, move on to the populate-contact hook. If you added listing fields, finish the wiring in Form: Add/Edit Listing and confirm the field saves back to the GeoDirectory post.