WP Image Zoom does not create posts or custom tables. Its data is the settings array in wp_options that defines lens shape, lens size, zoom level and the rules for which images get the zoom: WooCommerce product galleries, post content images, ACF fields, Elementor widgets, page builder images. The settings shape is small, but the coverage question across the site is real.

SleekView treats the WP Image Zoom settings as the eligibility rule and scans the relevant content surfaces against it. One row per zoom-eligible image with parent post, surface (WooCommerce, post content, ACF, Elementor), product category and field key as columns. Filters narrow by surface, category or post_type.

Every row reads through the same wp_options settings plus the wp_posts and postmeta the rule applies to, so front-end zoom behaviour is unchanged. The dashboard view of the same dataset is one click away.

WP Image Zoom is the smallest data shape in this batch: no CPT, no custom tables, just a settings array in wp_options that defines lens shape and which surfaces the rule applies to. The coverage question is still real. A WooCommerce store with hundreds of products only benefits from zoom on the products that have proper gallery imagery.

An editorial site only benefits on the posts whose images meet the rule. The default settings screen confirms the rule is enabled but never says where it actually fires. SleekView applies the rule across the database and renders the answers as rows.

Surface becomes a filter, product category becomes a column, parent post anchors the audit. The settings are small, the coverage list is long, and the table turns it into a managed surface.