Content Restriction by User Role flags each post or page with the WordPress roles allowed to view it, storing the rule in wp_postmeta. The plugin honours role capabilities and falls back to a configurable message or redirect for unauthorised visitors. The tight integration with core WordPress is its strength.

That same tight integration is why the default admin gives no library-wide overview. Each post knows which roles see it; the site as a whole has no screen that answers how much of the library a subscriber actually sees versus an administrator, or which roles act as the real premium tier in practice. Those questions are answerable against postmeta but invisible per-post.

SleekView reads wp_posts joined to wp_postmeta on the role-restriction meta keys. Every gated post becomes one row with allowed roles rendered as a comma-separated, independently filterable column, alongside post type and last update. Sortable on any column, filterable on role or post type, and inline-editable so bulk role reassignments route through WordPress core APIs.

Role-based content restriction is the simplest model that scales: assign content to a role, give the right users that role, let WordPress enforce the rest. The simplicity is the strength and the visibility cost. With every gating decision living in postmeta on individual posts, the editorial lead has no way to answer the basic strategic question (which role is the real premium tier on this site, and how much content sits behind it) without a spreadsheet or a custom query.

SleekView joins wp_posts to the role-restriction meta and surfaces every gated post as one row in one workspace. Editorial leads spot a sprint that shipped unprotected. Compliance reviewers confirm sensitive content sits behind the right role.

Membership operators size the premium library against the subscriber base. Same plugin data, dramatically less manual counting.