Muut Forum embeds a JavaScript widget on WordPress pages, with the forum data itself hosted on Muut. The WordPress plugin handles embed configuration and SSO identity, storing per-page settings as muut_* keys in wp_postmeta and per-user identity flags in wp_usermeta. The default plugin admin handles configuration but doesn't offer a flat audit of which pages have which embed type, which embeds reference orphaned forum paths, and which users have completed identity sync.

SleekView reads wp_posts filtered to pages and posts carrying any muut_* meta key, joins those keys as named columns, and joins wp_users for the page author. Filter by embed type to scope to channel embeds versus full-forum embeds, sort by last-modified to find recently changed embed configs, and bulk-clear orphaned muut_path values when a forum on Muut gets renamed or deleted.

Inline edits go through update_post_meta and the plugin's own filters so cascade logic stays consistent. Direct postmeta writes are available behind a flag for cleanup of orphaned embed state with conflict detection on the meta_id column.

Embedding a third-party forum on WordPress is a deliberately quiet integration. Muut hosts the forum, the WP plugin keeps a thin layer of embed config and identity flags in postmeta and usermeta, and the rest of WordPress doesn't really know the forum is there. That's fine while the integration is healthy and the linked Muut paths still exist.

It breaks down the moment the team needs to audit: where are all the Muut embeds across the site, which ones reference paths that no longer exist on Muut, which users completed SSO and which didn't. None of those are views the default admin offers because the data lives in long-format meta. SleekView's job is to pivot that meta into a real audit workspace where embed pages, orphaned paths, and identity-sync state surface as named filters.

Same data, same WP meta APIs on writes, dramatically less SQL spelunking when the integration needs attention or when a migration plan starts taking shape.