An image swatch is an attachment id stored in wp_termmeta on an attribute term. The default term-edit screen lets you set one swatch at a time, with no overview of which terms have images, which have placeholders, and which are missing. For a store with 60 colors and 20 materials, that's a long audit by hand.

SleekView reads attribute terms (pa_color, pa_material, or any global attribute) joined with wp_termmeta for the image-attachment key the swatch plugin uses. It also joins wp_posts on the attachment id so the actual image URL and file size are surfaced as columns. A variation-usage count joined via wp_term_relationships tells you which terms are actually in use.

Inline edits swap attachment ids through the WordPress term-meta API, so swatch caches refresh and the front end re-renders on the next page load. Audit views like "Terms with no swatch image", "Swatches using oversized attachments", or "Unused terms with swatch images" become saved filters instead of manual hunts.

Image swatches are stored as attachment ids in wp_termmeta, which is the right schema and the wrong UX for any audit beyond a handful of colors. A store with 80 colors and 30 materials has 110 swatch slots, each of which needs an actual attachment, a reasonable file size, and a real reason to exist. The default term-edit screen makes auditing that a click-through-each marathon.

SleekView turns the whole set into a sortable workspace: term + attachment + file size + usage count in one row, with saved filters for missing images, oversized files, and unused terms. Inline writes go through the term-meta API so cache invalidation and front-end re-rendering behave exactly as after a manual term edit. The audit becomes a saved view rather than a yearly project, and the same configuration works for any global attribute taxonomy.