Facebook Login is the category of single-provider WordPress plugins that wrap Facebook's OAuth flow, log the user in, and persist the link as a row in wp_usermeta (typical keys: facebook_id, fb_user_id, _facebook_login_uid). The default WordPress users screen does not surface that meta key, so admins cannot tell at a glance which accounts are Facebook-linked and which are not.

SleekView reads wp_users and joins the Facebook-link meta key, producing one row per user with columns for the Facebook identifier, the link timestamp, and the last-login date. Filters like 'Facebook-linked users only' or 'users with a Facebook ID but no recent login' become first-class chips, useful before deprecation work or after Facebook permission changes invalidate sessions.

Edits route through the plugin's documented unlink path when available, and fall back to direct meta edits with an explicit admin override. The view is an operations and compliance layer alongside the plugin's own admin, not a replacement for the OAuth connect flow.

Single-provider Facebook Login plugins are the operational equivalent of a black box: they work fine until Facebook changes a scope, and then there is no admin surface to ask 'how many of my users only ever logged in with Facebook'. The data is right there in wp_usermeta but the default WordPress users screen has no notion of a Facebook column, so the question stays unanswered until a permission change converts it into a support fire drill. SleekView lifts the meta key into a first-class column and the operational picture sharpens immediately.

Identity admins can plan deprecations. Compliance teams can produce exports for the DPO. Support agents can confirm whether a stuck user even has a Facebook link before suggesting a fix.

The data is not new; the view is. That is the entire point of treating wp_usermeta as a real schema rather than a serialized closet.