Summary

Every button a customer admin creates in Mobile App Manager → Buttons is persisted as an entry in a serialized array stored in the local-app-button-array* option family. This storage is one of the most-frozen surfaces in the codebase — customer sites have years of accumulated button configs depending on the existing schema.

Where it appears

Reading either name returns the same value via the migration framework’s pre-option filters.

Storage shape

get_option( 'local-app-button-array_subscriber' );

// returns:
array(
    array(
        'id'              => 'btn_42',
        'title'           => 'Edit listing',
        'content_type'    => 'open_form',
        'class'           => 'local_app_open_form',
        'icon'            => 'black_edit',
        'visible'         => 'on',
        // per-button settings declared by the content class:
        'require_login'   => 'yes',
        'pass_user_id'    => 'yes',
        'style_bg_color'  => '#1A73E8',
        // ... arbitrary keys the content class declared via app_settings()
    ),
    array(
        'id'              => 'btn_43',
        ...
    ),
    // ... up to N entries
);

The array order is significant — admin UI ordering corresponds to the array order. Reorder via the mam_app_settings_button_order filter.

Per-row keys

Why the option key is frozen

• ~2K customer sites have populated local-app-button-array* with their config
• Mobile apps in the field read the resulting JSON and assume the button shape
• Migration cost is high — renaming requires updating every site’s serialized array

Frozen contract — do not rename. A rename would require iterating every customer’s wp_options to copy + delete + verify.

Schema gotchas

• No normalized schema. A button missing a key your code expects produces a PHP notice. Always ?? $default.
• Class names inside class are frozen. Renaming local_app_login_button orphans every site’s saved login button.
• content_type is a user-facing label. Changing it (e.g., from “Login Button” to “Sign in”) doesn’t break storage but changes what admins see.

Modifying button arrays programmatically

Read:

$buttons = get_option( 'local-app-button-array_subscriber', array() );

Or via the cascade-aware filter:

$buttons = apply_filters(
    'mam_app_settings_get_buttons',
    false,             // default
    'subscriber',      // role
    'main'             // 'main' | 'left' | 'tab'
);

Write:

apply_filters(
    'mam_app_settings_set_button',
    $modified_button_blob,
    'subscriber',
    'btn_42'
);

Or for bulk reorder:

apply_filters(
    'mam_app_settings_button_order',
    $reordered_array,
    'subscriber'
);

Or to delete:

apply_filters(
    'mam_app_settings_delete_button',
    'btn_42',
    'subscriber'
);

⚠️ Don’t update_option directly with a hand-built array — the data manager runs validation and (where applicable) cache invalidation.

Related articles

• Settings cascade overview
• Per-button and per-role settings
• Content classes overview
• Frozen public contracts reference
• Hook: mam_app_settings_get_buttons

Metadata