Signature

do_action( 'mam_gd_manage_favorites' );

No arguments. The action is fired without context — listeners must read $_REQUEST directly if they need to know the listing ID, the user, or the action (favorite / unfavorite).

Purpose

Fires after the plugin’s mobile-favorites AJAX endpoint has finished updating the user’s favorites list. By the time the action fires:

• The listing’s gd_favourite_users post meta has been updated.
• The listing’s gd_favourite_users_count post meta has been recalculated.
• The user’s gd_user_favourite_post user meta has been re-saved.

This is the right place to add side effects: log the favorite, write to an analytics table, kick off a re-recommendation job, etc.

When it runs

Inside mam_geodirectory_mam_main_ajax::manage_favorites():

update_user_meta( $user_id, 'gd_user_favourite_post', $favorites );
do_action( 'mam_gd_manage_favorites' );
$result['jsonData'] = local_app_get_phone_data( true );

It fires once per AJAX request, after the user-meta update and before the response is sent. The handler dies right after calling local_app_get_phone_data — your action handler does not have time to enqueue anything async; long-running work needs to be deferred (e.g., via WP-Cron).

Reading context

Because the action fires without arguments, listeners read the request directly:

add_action( 'mam_gd_manage_favorites', 'my_app_log_favorite' );

function my_app_log_favorite() {
    $post_id = absint( $_REQUEST['id'] ?? 0 );
    $action  = sanitize_key( $_REQUEST['pingaction'] ?? '' ); // 'favorite' or 'unfavorite'
    $user_id = mam_user_id();

    if ( ! $post_id || ! $user_id ) {
        return;
    }

    // Log the event...
}

$_REQUEST['id'] is the listing post ID (already validated by the time the action fires). $_REQUEST['pingaction'] indicates the direction (favorite to add, unfavorite to remove).

Examples

Increment a per-listing favorite-events counter

add_action( 'mam_gd_manage_favorites', 'my_app_count_favorite_events' );

function my_app_count_favorite_events() {
    $post_id = absint( $_REQUEST['id'] ?? 0 );
    $action  = sanitize_key( $_REQUEST['pingaction'] ?? '' );
    if ( ! $post_id || ! in_array( $action, [ 'favorite', 'unfavorite' ], true ) ) {
        return;
    }
    $key = $action === 'favorite' ? 'my_app_favorited_count' : 'my_app_unfavorited_count';
    $current = (int) get_post_meta( $post_id, $key, true );
    update_post_meta( $post_id, $key, $current + 1 );
}

Gotchas

• No arguments. Use $_REQUEST to read the post ID and direction. Don’t trust those values for write operations without your own sanitisation — the AJAX endpoint already absint’s the ID, but the action runs after that, so you have the sanitised value via $_REQUEST['id'].
• Synchronous. The handler dies right after firing — the AJAX response will reflect a slow handler’s runtime. Defer expensive work to the next request cycle.
• Fires for every toggle. Both add and remove fire the same action. Disambiguate via $_REQUEST['pingaction'].

Verification

This article was last verified against:

• Plugin: mam-geodirectory v2.1.5
• Source: includes/mam_geodirectory_mam_main_ajax.php — manage_favorites()

Re-verify whenever the AJAX response is moved (the action would need to fire before the response is sent), additional arguments are added, or the meta-key names change.

Related articles

• Plugin: mam-geodirectory
• Mobile listing data shape
• Listing tab bar buttons

Metadata