Divi Supreme is a module pack for Divi, so its modules live inside the Divi builder shortcode stored in post_content on each page. Divi marks builder-enabled posts with _et_pb_use_builder=on in wp_postmeta. Supreme modules use shortcode tags like [dsm_business_hours], [dsm_image_carousel], or [dsm_pricing_table].

SleekView reads wp_posts with a contains-text filter on post_content for Supreme module tags, joined to wp_postmeta for builder metadata. Pin saved views per module. Filter by status, author, and last edited to surface drafts, stale layouts, and live Supreme-using pages.

Inline edits to post-level fields run through wp_update_post so Divi and other plugin hooks fire normally. The Divi shortcode content stays untouched; the Divi Builder remains the only path for module changes. CSV export of any audit slice gives the team a clean deliverable.

Divi Supreme ships dozens of modules, and any long-running Divi site that uses it tends to end up with hundreds of pages depending on a handful of those modules. None of that is a problem until a redesign, a builder migration, or a license review forces the question of which pages actually depend on Supreme. The default Divi admin shows Supreme-using pages as ordinary Divi pages because the data lives inside post_content as Divi shortcode.

A queryable inventory turns the audit into a saved view. Filter to Supreme-using pages, group by module shortcode tag, sort by last edited. The pages that need attention before retiring a module become obvious in minutes.

Agencies use the grid for client handover reports; in-house teams use it before retiring a module pack or moving to another builder. The cost of the audit drops to the cost of opening the table.