Purpose

Per-item visibility filter for tab-bar buttons. Lets a sibling plugin hide a registered button on a per-item / per-user basis without owning the button definition.

Runs before mam_main_add_tab_bar_item_{slug} dispatch — preferable to gating inside an “add” filter you don’t own, because the skip filter short-circuits earlier and doesn’t depend on cooperating with the button’s registered handler.

Signature

$tab_bar = apply_filters(
    'mam_main_skip_tab_bar_button',
    array $tab_bar,
    array $data_array
);

Returns: array — $tab_bar to keep the button, [] to hide it.

Example: hide the generic Share button from staff

add_filter( 'mam_main_skip_tab_bar_button', function ( array $tab_bar, array $data_array ): array {

    if ( ( $tab_bar['id'] ?? '' ) !== 'share_listing' ) {
        return $tab_bar;
    }

    if ( $this->current_user_is_staff_for( $data_array['id'] ?? 0 ) ) {
        return array();   // hide
    }

    return $tab_bar;
}, 10, 2 );

Skip vs. add filter

The skip filter is preferable when you don’t own the button, because:

• It runs first (before the add filter)
• You don’t need to know the button’s registered slug — match by $tab_bar['id']
• You don’t fight with the button’s add handler

Gotchas

• Returning [] hides; returning $tab_bar keeps. Don’t return false or null.
• $tab_bar['id'] is the dispatch key. Always check it before deciding.
• Hot path. Fires once per tab-bar button per item. Cache role / context lookups.
• You don’t see whether the item’s add handler would have hidden the button anyway. Skip and add are independent gates; both can hide.

Related articles

• Recipe: Configure the tab bar
• Hook: mam_main_add_tab_baritem{slug}
• Hook: mam_tab_manager

Metadata