Edwiser Bridge Pro mirrors Moodle courses into WordPress as the eb_course post type and stores user-course mappings in wp_moodle_course_users, with sync history typically logged via wp_options or a dedicated log table depending on version. The default Bridge admin shows enrolment counts and sync status per course, which is enough to confirm 'sync ran' and not enough to answer 'which 12 users are stuck mid-sync.'

SleekView reads the bridge tables and Moodle-mirrored CPT directly, so an audit view joins moodle_course_users with wp_users and the eb_course post to show every user-course pair, the last sync timestamp, and the current state. Filters surface enrolments where the Moodle and WP state diverge: WP shows enrolled, Moodle doesn't, or vice versa. A separate view scopes to Single Sign-On creations to catch users provisioned to WP but not yet pushed to Moodle.

Inline status changes route through Edwiser Bridge's enrolment API where supported, so the WP-to-Moodle push fires normally and Moodle stays in sync. Direct writes skip the bridge for back-fill scenarios after a data-import mishap. Multisite installations get per-subsite scoped views so network admins can audit one site without leaking data across subsites.

Bridging WordPress to Moodle is the right architecture for organisations that want public-facing marketing on WP and a proper LMS for delivery, but the integration is only as good as the audit tools around it. Edwiser Bridge Pro does the sync reliably; the open question is always 'how do we know it's actually consistent right now.' Default per-course summaries answer that at the aggregate level and obscure the dozen edge-case rows where WP and Moodle disagree. Support teams discover those edges through learner tickets, which means the audit happens after the problem.

Bridge admins doing data imports want a way to scan thousands of mapping rows after the import lands and resolve mismatches before the next sync. SSO-driven provisioning adds another wrinkle: users land in WP first, get pushed to Moodle on a delay, and may sit in a mismatched state for minutes or hours. SleekView's job is to make those mismatched rows visible and addressable in one screen instead of hidden in logs.

The same data, finally legible at the row level.