WP Import Pro uses a wpip_import custom post type for the job definition and stamps each run's _wpip_last_run, _wpip_created, _wpip_updated, _wpip_skipped, and _wpip_status into wp_postmeta. The default plugin admin renders each job's log as a per-import screen, which is fine for one feed and painful when fifteen scheduled imports run on staggered crons.

SleekView reads wp_posts (post_type=wpip_import) joined to those meta keys as a flat workspace. Counts for created, updated, skipped, and deleted become first-class columns, sortable across every import. A second view joins wpip_imported_posts meta back to wp_posts so any product or CPT row carries the import that last touched it.

That two-view setup answers the questions support tickets actually ask: which import created this orphan product, why are skipped counts climbing on the vendor catalog, and which scheduled imports have not run since the last cron rewrite. None of those need SQL once the views exist.

WP Import Pro is rarely deployed as a single feed. Most production sites run a vendor catalog import, a stock-levels feed, a price feed, and a few legacy CSVs scheduled across the day. The plugin's own UI is built around editing one import at a time, so a missed run on the stock feed and a partial run on the vendor catalog do not show up together unless someone opens both screens.

That is exactly when data drift becomes a customer support ticket. Reading the wpip_import post type and its meta directly turns the question "which import did this come from" into a sortable column. Skipped counts climbing on the vendor catalog stop hiding behind per-import pagination.

Stale scheduled imports that have not run since cron got rewritten surface in a single filter. The imported-post-ids meta makes orphan-record investigations a one-click filter on source import and last-run timestamp. That visibility shifts WP Import Pro from a tool ops teams hope is working to one they can audit before the morning standup.