WP Community builds public member directories, profile pages and contribution surfaces on top of WordPress users. Profile fields live in usermeta keyed by user_id, role and registration date come from wp_users and any contribution activity (posts, comments, gallery items) is stored as standard WordPress content keyed to the author. The plugin renders this as a directory and per-profile pages on the front end, which is right for visitors and unhelpful for operators trying to audit the community as a whole.

SleekView reads wp_users joined with WP Community's profile usermeta and wp_posts/wp_comments authored by each member, then renders the result as a sortable audit table. Filter to last-30-days sign-ups for onboarding review, sort by contribution count for ambassador shortlists, group by role to surface tier balance. The same dataset the chart view aggregates becomes a row-level surface for community managers, moderators and admins.

The plugin keeps owning directory rendering and profile pages on the front end. The table view owns the cohort surface, so the members WP Community already maintains stop hiding inside directory cards and become something community ops can actually query.

WP Community already captures the data an operator needs: who joined, in what role, when they registered and what they have contributed. The default surface places that data inside directory cards and per-profile pages, which is right for visitors and unhelpful for almost everything operators do at the cohort level. A queryable member table answers the questions managers actually ask: who just joined, who has gone quiet, who is doing the work.

Same user rows, same registration timestamps, completely different decision posture. The table renders the community WP Community already maintains as an auditable cohort, which is the difference between knowing the site has members and knowing what to do with the community this quarter.