Summary

mam_codex_manager (includes/app-settings/codex-manager.php) fetches and caches the MAM Codex settings catalog from the canonical WPMAM platform endpoint. The Codex is the master reference of every registered setting and its metadata; this class pulls it down and stores it locally so admin tooling (a settings-search UI, an admin-side documentation generator) can read it without re-deriving it from source.

It is not user-facing and it is not called from a synchronous request handler. MAM_Remote_Sync_Manager owns the cadence and calls sync_now() on its scheduled tick; this class just performs the fetch.

Public surface

This is the only public method. There is no local get_all_settings() / get_categories() accessor — reading the cached catalog is a plain option read.

Cached options

sync_now() writes what it fetches into WordPress options:

Each catalog entry mirrors what app_settings() returns from a content class:

array(
    'category'    => 'login',
    'title'       => 'Require Login?',
    'variable'    => 'require_login',
    'type'        => 'yes-no',
    'id'          => 'tsl-require_login',
    'environment' => 'global',
    // ...
)

Hook involved

When to use the cached catalog

• Building an admin search UI — read get_option('mam-codex-data') to let admins search “what setting controls the geofilter radius?”
• Auto-generating docs — produce a Markdown / HTML reference of every setting from the cached catalog
• External integrations — an external editor that needs to know what settings exist

When NOT to use it

• Don’t call sync_now() from a request handler. It performs an HTTP fetch against the platform endpoint; MAM_Remote_Sync_Manager already schedules it. Read the cached mam-codex-data option instead.
• For per-request setting reads. Use mam_app_settings_get_setting for those — not the codex catalog.
• For determining “does this setting exist?” at runtime. Check the option directly — codex is a reference catalog, not a runtime gate.

Gotchas

• The catalog is fetched, not derived locally. sync_now() pulls it from wpmobileappmanager.com and caches it in mam-codex-data. On the canonical WPMAM instance itself it instead fires mam_codex_update_settings (the server builds its own catalog) and returns early.
• Cursor-based no-op. The since= / mam-codex-last-modified cursor lets the server answer {"status":"no_updates"}; sync_now() just refreshes mam-codex-date and returns true in that case.
• Failure is a soft false. HTTP errors, non-200, and invalid JSON log a Codex_error via mamdebug and return false — the previously-cached catalog is left untouched.
• Help descriptions are lazy — they require a mam_settings_set_help_desc subscriber to populate. Without one, the help_desc field is empty.

Related articles

• Settings cascade overview
• Content classes overview
• Hook: mam_app_settings_get_setting

Metadata