Additional Variation Images stores a gallery image-ID list on each variation post in a meta key (commonly woo_variation_gallery_images). The plugin solves the front-end question: each variation shows its own gallery. The catalog-wide question, which variations actually have images and which fall back to the parent product image, stays invisible behind variation edit screens.

SleekView reads the product_variation post type and joins that gallery meta as a derived image-count column. Filter to variations with zero images to brief a photo shoot. Sort by parent to find products whose color variations are richly photographed and whose are not. Filter to one attribute (color rust, size XL) to check coverage against a campaign brief. The same dataset the chart view aggregates becomes a row-level surface for creative ops, merchandising and ecommerce managers.

The plugin keeps owning the front-end gallery rendering. The table view owns the audit surface, so the gallery meta Additional Variation Images writes stops requiring a click-into-each-variation tour and becomes something creative ops can actually filter.

Photo coverage at the variation level is the kind of dataset a list view buries. A catalog of ten thousand variations with image counts tells nobody where the gaps are; a filter to zero-image rows and a sort by parent does. Additional Variation Images already writes the gallery meta; the question is whether the team can read it across the catalog in one screen.

SleekView reads product_variation joined with the gallery meta and renders the rows as a queryable audit table with image count, parent and attributes as first-class columns. Filters stack so the photo brief queue, the per-attribute coverage audit and the catalog cleanup review become saved views rather than spreadsheet exercises. The plugin keeps owning the storefront gallery, while creative ops gets the per-row surface the coverage data always deserved.