The Cloudinary WordPress plugin stores per-attachment data in wp_postmeta under keys like _cloudinary_public_id, _cloudinary_sync_signature, _cloudinary_v2, and _cloudinary_overwrite_transformations. Global configuration including the cloud name and the default transformation lives in wp_options under cloudinary_settings. The default admin shows a sync queue and an overall progress bar, but the per-asset state is buried inside each attachment's edit screen.

SleekView reads the postmeta and joins each row to its wp_posts attachment. The result is one row per image or video with its title, MIME type, public_id, sync state (synced, queued, error), the active transformation string, and whether per-asset overrides are set. Sort by sync state to find failed uploads, filter to attachments with a specific transformation prefix, or group by MIME type to see how video and image syncs differ.

Inline edits route through the plugin's own meta API and trigger the sync hooks where supported, so Cloudinary remains the source of truth for what is on the CDN. Saved views like Failed sync only or Videos pending can be scoped per role, useful for letting a developer fix sync errors without exposure to the Cloudinary API secret in cloudinary_settings.

The Cloudinary plugin's job is to keep WordPress's media library and Cloudinary's storage in sync, rewriting URLs on render and queuing uploads on save. When it works, the experience is invisible. When it does not, the operational gap shows up immediately: a few hundred attachments fail to sync after a credentials rotation, a transformation drifts on product images, or a video stalls in the queue for reasons that never surface in the global progress bar.

The default admin gives you the queue and a per-attachment edit screen, which is the wrong shape for triaging across thousands of assets. SleekView turns the same postmeta into a list with sync state, public_id, transformation, and MIME type as columns. Failed syncs sort to the top.

Specific transformations cluster by post type. Media managers fix problems without ever seeing the API secret, and developers run resyncs against a real inventory. The plugin keeps owning the upload pipeline; SleekView just lets the team responsible for the library read the result.