Why caching exists

The phone-data pipeline rebuilds the mobile JSON on every app load. A typical app has dozens of forms — registration, profile, contact, listing submission, claim, send notification, etc. — and each one runs through GF’s full schema fetch and the mam-suite transformation chain.

Without caching, every cold app launch triggers a flurry of GF API calls plus the per-field-type filter chain for every field on every form. With caching, the transformed shape is served from a per-request in-memory array and a per-post serialized copy.

What’s cached

There are two layers:

• $local_app_form_array — a per-request in-memory indexed array of fully-shaped form payloads. mam_form_manager_cache_manager (includes/forms-manager/form-cache-manager.php) manages membership via is_form_in_array() and add_or_update_form_in_array(). This is the cache that mam_gf_get_form_from_cache reads.
• form_cache post meta — local_app_gravity_forms::get_data_for_app() writes the serialized transformed form to update_post_meta( $post_id, 'form_cache', $data ) for post-backed forms, and reads it back on the next build unless excluded.

Each cached payload contains the transformed field schema, resolved settings (mam_gf_get_form_settings), theme colors, and per-field display rules (mam-for-gf-form-field-display-*). Cache hits skip the transformation chain.

There is no mam-form-cache-* option key — verify against the source before relying on one.

Invalidation triggers

The form_cache post meta is invalidated by:

• A form submission — submit-app-form.php calls delete_post_meta( $post_id, 'form_cache' ) after processing
• An explicit delete_post_meta( $post_id, 'form_cache' ) at any write site that changes a post-backed form’s output

Stale-cache symptoms

Diagnosis

delete_post_meta( $post_id, 'form_cache' );

If the symptom resolves after clearing the form_cache post meta, the invalidation for whatever changed is missing. Add a delete_post_meta( $post_id, 'form_cache' ) call to the write site for that setting.

Programmatic invalidation

delete_post_meta( $post_id, 'form_cache' );   // single post-backed form

There is no invalidate() / invalidate_all() method on mam_form_manager_cache_manager — the class only exposes is_form_in_array() and add_or_update_form_in_array() over the in-memory $local_app_form_array. To force a global rebuild, clear the form_cache meta across the relevant posts.

Gotchas

• The cache is form_cache post meta plus the $local_app_form_array global — not an option. Clear it with delete_post_meta().
• $local_app_form_array is 1-based on the wire — rows reference forms by (string)($index + 1); don’t reorder it.
• A stale form_cache is the most common source of “app still shows the old form.” Delete the post’s form_cache meta at any write site that changes a post-backed form’s output.

Related articles

• Forms manager overview
• Form submission lifecycle
• Custom field types
• Phone data pipeline overview

Metadata