Subscriber Only restricts posts to logged-in users with a specific role, storing config as wp_postmeta under _subscriber_only_ keys: _subscriber_only_required_role, _subscriber_only_redirect, _subscriber_only_status. The plugin doesn't create custom tables; it reuses wp_posts and wp_postmeta entirely.

The default admin shows the gating option in the post editor. There's no global view of every gated post, no aggregated count by required role, and no quick way to find posts that were meant to be gated but had their rule cleared. For sites running per-post role gating across a content library, those audit questions are exactly the ones that get asked.

SleekView reads wp_posts, joins wp_postmeta on the indexed post_id with a meta_key prefix filter, and exposes role, redirect, status, and modified date as columns. Inline edits route through update_post_meta() so any hooks the plugin registers fire on save.

Per-post role gating works because it stays out of the way. Subscriber Only is a typical example: a simple meta-box in the editor, a redirect URL, and a required role. The trade-off is that no catalogue view exists.

As soon as the content library grows past a few dozen gated posts, the audit questions start to outrun the per-post UI. Membership admins can't bulk-rename roles without scripting. Editors don't know which posts are gated until they open each one.

Compliance can't certify the gating policy across the library. SleekView turns the postmeta keys into columns and gives the team the catalogue layer the plugin doesn't ship. The plugin's storage model stays the same, the editor experience stays the same, and the gating policy becomes auditable instead of implicit.

For sites running per-post gating at any scale, that's exactly the missing piece.