Magic Link Login replaces password prompts with an emailed link that contains a short-lived token. The plugin writes a row per request, capturing user, expiry, and redemption state, either as serialised data in wp_options or in a dedicated table depending on the build. The default screens cover configuration: link lifetime, email template, allowed roles. What they do not cover is the cross-user log of who has been requesting links and how often they actually click through.

SleekView reads the redemption log directly. User, requested at, expires at, redeemed at, IP, and user agent become filterable columns. Filter to redeemed equals false to find users with deliverability problems. Group by IP to spot abuse. Sort by requested-at descending to see live activity during a release window when many users sign in at once.

The plugin owns token generation, email dispatch, and the redemption endpoint. SleekView adds the audit table that the default screens were never designed to be.

Magic-link authentication is one of the simplest ways to remove password reuse and weak-password risk from a content site, but it shifts the audit surface from the login form to the token log. If the token log lives in wp_options or a hidden table and the admin UI does not browse it, the operational story (issued, delivered, redeemed, expired, abused) becomes invisible. SleekView reads the underlying log and renders it as a queryable workspace with redemption state, IP, and user agent as first-class columns.

Support gets a per-user view that answers 'where is my link' tickets. Security gets burst detection by IP. Compliance gets exports that match the audit window without a WP-CLI session.

The plugin keeps owning generation, delivery, and redemption. The team gains the missing audit surface and stops treating a hidden options blob as the source of truth for authentication events.