Primary responsibility

Renders the user’s saved-items list. The actual favorites data comes from sibling plugins (mam-geodirectory contributes GD listings, mam-special-offers contributes promotions, etc.). The content class itself is a thin shell — get_content_type_form() returns “No settings required” and get_data_for_app() passes the category through unchanged; the favorites list and its flags are assembled by the phone-data pipeline (the user’s saved ids live in the favorites usermeta key).

Settings

The Favorites content class declares no per-button settings of its own — the button’s edit form literally returns “No settings required.” The one related setting is a global app setting owned by the app-settings registry, not by this class:

The hide_remove_all_favorites flag is surfaced to the app through the global settings section of the phone-data JSON.

Hooks

JSON shape

The favorites response section looks like:

{
  "favorites": ["123", "456", "789"],
  "hide_remove_all_favorites": "yes"
}

favorites is read from the favorites usermeta key and is an array of post-id strings (typed as strings — many mobile clients expect strings, not integers).

Gotchas

• Favorites are stored in the favorites usermeta key. mam-main’s handle_favorites() persists the toggle there and the phone-data pipeline reads it back. Sibling plugins (mam-geodirectory, mam-special-offers) contribute the source records that populate the list.
• favorites is a strings-array, not ints. Don’t return integer ids from your sibling plugin’s contribution.

Related articles

• Content classes overview
• Hook: mam_manage_favorites
• Mobile JSON shape

Metadata