Slider Revolution (Revolution Slider) keeps modules and slides in dedicated revslider tables: a sliders table for the module row (id, title, alias, type, params blob with version and dimensions), a slides table for slide rows (id, slider_id, slide_order, params, layers), and a static slides table for the global static slides. The Slider Revolution admin presents a card per module with limited cross-filtering.

SleekView Charts reads modules, slides, and static slides together. Number cards count total modules and total slides. Pie cards split modules by type (Standard, Carousel, Hero, One-Page Scroller) or by template origin. Bar cards rank modules by slide count, by layer count per slide, or by post placement. Area cards trace creation cadence across modules.

Every card reads through the same revslider tables Slider Revolution already maintains, so module rendering on the front end is unchanged. The dashboard sits alongside the SleekView table view of the same dataset.

Slider Revolution has been bundled with thousands of WordPress themes for over a decade, and the revslider tables it ships are detailed: module type, alias, slide layers, and creation date are all queryable. The cost is that the Slider Revolution admin presents modules as cards in a grid, so cross-cutting questions about type mix, layer coverage, and placement go unasked. SleekView Charts reads the same tables and gives the catalog one reporting dashboard.

A donut of module types confirms which patterns the team relies on. A horizontal bar of slide counts exposes modules that outgrew their scope. An area chart of creation dates shows whether Slider Revolution is still part of the editorial mix or a legacy presence.

A single number KPI for total modules gives owners catalog scale before any redesign conversation begins. The revslider data has been there all along, the dashboard just renders it.