From the rollback events WP Rollback emits via the WordPress action hook system and the activity log entries any installed logging plugin records. The chart cards run live queries against those rows, so the dashboard reflects the real downgrade history rather than a stale export.

If WP Rollback's own audit option is enabled the chart cards have a primary data source. Pairing it with an activity log plugin such as WP Activity Log enriches the events with the user role, IP address, and request context, so the same cards gain extra group-by fields without extra configuration.

Yes. WP Rollback supports both, and the events carry an asset_type field of plugin or theme. Filter the chart card by asset type or split a pie across the two to see whether plugin rollbacks dominate, which they typically do.

Yes. SleekView queries only the columns the active cards need and pushes grouping to the database engine, so an audit log with tens of thousands of rows still renders a horizontal bar chart in well under a second. View-level caching keeps the response stable.

Yes. Each event records the source and target version, so a chart card grouped by target version surfaces whether the team consistently downgrades to the same known-good release or whether the choice varies across rollback events.

Yes. View-level filters for plugin slug, user role, or date range apply to every chart card on the dashboard. One saved configuration drives both the editing table and the reporting view, so investigation and summary stay in sync.

Yes. SleekView views gate by WordPress capability, so a custom client role with read-only access to a single view sees just the rollback dashboard. The plugin's own settings and rollback buttons stay restricted to administrators.

No. The Rollback action on the Plugins and Themes screens stays where it is, and the version picker keeps working. SleekView Charts adds a reporting surface on top of the events the plugin already records, so downgrades remain one click and the dashboard owns the audit story.