Subscribe to Comments piggybacks on the core WordPress comments schema. Per-comment subscriptions live in wp_commentmeta under keys like subscription_email, subscribed_to_post, and subscription_confirmed. Global "subscribe to all comments" opt-ins live in wp_usermeta under per-blog keys. The default admin shows comments, not subscriptions: there is no screen that lists who is subscribed to what or which addresses bounced on the last notification batch.

SleekView reads wp_commentmeta rows where meta_key starts with subscription_, joins to wp_comments for the post context, and joins to wp_users when an email matches a registered account. Subscriber email, target post, double opt-in state, last-notified timestamp, and unsubscribe-token presence all become first-class columns. Filter to unconfirmed opt-ins older than 48 hours, sort by post to clean up subscriptions for retired articles, or bulk-delete bounce-flagged rows in one pass.

Inline edits route through update_comment_meta and update_user_meta so existing add-on filters and hooks fire as they would on the per-row edit screen. Direct table writes are available for one-time cleanups of orphaned subscription rows where you do not want to retrigger notification side effects.

Comment subscriptions are an email channel hiding inside the comments table, and most sites discover that only when a deliverability problem forces an audit. The default plugin admin can show a per-comment list but cannot answer "which subscribers have not confirmed in a week" without custom SQL. As soon as a blog grows past a few hundred active posts, stale opt-ins, bounces, and orphan rows on deleted posts pile up in wp_commentmeta and nobody notices until the notification engine starts failing.

Editors want to scrub subscribers from retired posts. Support wants to look up a complaining address and unsubscribe in one click. Compliance wants an exportable view by email for data-subject requests.

SleekView gives each of those workflows a saved table that reads from the same wp_commentmeta rows the notification engine already writes, instead of a fresh SQL session every time. The data stays in WordPress, the writes go through the plugin's own meta hooks, and the team stops blocking on whoever can run the queries.