Yes. The same ewwwio_images and ewwwio_queue tables are written whether optimization runs locally with the bundled tools or remotely through the EWWW Cloud API. SleekView reads both the same way. Cloud-only features such as automatic AVIF conversion and Easy IO CDN delivery surface as additional columns when those services are active.

Yes. SleekView calls EWWW's own optimize function on the inline action, so the same logic that runs from the bulk screen handles the retry. Credits, async workers, and the optimization log behave exactly as they would after a re-run from the EWWW UI, and the bulk action handles multiple rows at once.

Yes when Easy IO is active. EWWW records which attachments are eligible for Easy IO delivery, and SleekView surfaces that as a boolean column. A view of attachments not yet served via the CDN makes it easy to verify coverage after enabling Easy IO on an existing site or after switching domains.

Yes. EWWW can optimize images outside the WordPress media library through its custom folders feature, with rows recorded in the same ewwwio_images table. SleekView surfaces those folders as their own filter so theme assets and plugin images appear in dedicated views next to the standard attachment view.

Yes. The queue view shows active and pending rows with age, last attempt, and last error. Sort by age to spot stuck batches and use the inline remove-from-queue action to clear poison rows that keep retrying. The async worker continues to process the queue exactly as configured.

No. SleekView paginates against the existing ewwwio table indexes and only loads the visible page. Heavy filters resolve in the database the same way EWWW's own admin queries do, and saved views do not pre-fetch anything until they are opened, so the WP admin stays responsive on libraries of any size.

Yes. EWWW's WP-CLI worker writes to the same ewwwio_queue and ewwwio_images tables that the admin UI uses. SleekView reads from those tables, so a queue processed by the CLI worker shows up the same way as one processed from the bulk screen, with rows transitioning through states as the worker advances.

Yes. The restore action calls EWWW's own restore function, which pulls the original from the backup directory and updates the ewwwio_images row accordingly. SleekView never touches backup files directly; the backup directory and EWWW's log remain authoritative, with SleekView just exposing the action where the row already lives.