Profile Magic builds custom registration, login and profile pages on top of wp_users and wp_usermeta. Every field on a Profile Magic form lands in wp_usermeta as a key/value row keyed by user_id, and role assignments plus account flags live there too. The default plugin admin shows per-profile pages and a basic member list, which is right for individual member work and wrong for understanding the membership as a whole.

SleekView reads wp_users joined with the Profile Magic usermeta keys and pivots the fields into named columns at query time. Each member is one row. Role, account_status and any custom meta_key (country, occupation, plan) become real columns. Filter to pending registrations, sort by user_registered for onboarding triage or group rows by role for segmentation.

The plugin keeps owning forms, login flows and per-profile rendering. The table view owns the audit surface, so the fields Profile Magic already writes stop hiding behind per-profile pages and become real, queryable columns.

Profile Magic is structurally a usermeta-driven plugin: every registration field becomes a meta_key on submission and lives in wp_usermeta keyed by user_id. That schema is flexible and unreadable at the same time, because the default admin lists members and exposes per-profile screens but never pivots the data into columns. SleekView pivots the Profile Magic meta_keys into named columns at query time, so country, occupation and account_status become sortable columns rather than hidden key/value rows.

Filters stack into a single query so the approvals queue, the country segment and the lapsed-member list become one-click saved views. The plugin keeps owning forms, login pages and notifications, while membership managers get the per-row surface usermeta always deserved.