SiteGuarding Security keeps its operational state in a mix of places. Scan summaries and configuration live in wp_options under sg_ prefixed keys. Blocked IPs, attempted logins, and firewall hits land in plugin tables like wp_sg_blocked_ips and wp_sg_login_attempts. The default screens render each list with a few canned filters but do not expose the rows as a queryable grid that a reviewer can pivot.

SleekView reads each table directly and treats the option entries as their own source. Scan findings become rows with type, file, severity, and first-seen columns. Blocked IPs expose the address, the reason, the action, and the expiry. Login attempts show the user, the IP, the result, and the time on a single grid that filters and sorts like any other SleekView.

Edits route through SiteGuarding's own actions, so unblocking an IP or clearing a finding triggers the same hooks the plugin's UI does. The outcome is a workflow most site owners would design themselves if they had time: filter what matters, save the view for the next review, annotate the rows, and stop rebuilding the same investigation every week.

Security plugins like SiteGuarding earn their value by writing a lot of data: every blocked IP, every login attempt, every scan finding. The default screens are fine for a quick look, but the questions that actually drive decisions tend to cross tables and timeframes. Which IPs hit this site this week, which user names did they try, which rule fired, what scan finding correlates with that pattern.

Compliance reviews and incident postmortems want repeatable evidence with the same columns each time, not a one-off filter rebuilt from memory. Local scan tracking needs state that survives the next run so triage decisions are not lost when SiteGuarding refreshes the option entry. Treating wp_sg_blocked_ips, wp_sg_login_attempts, and the sg_ options as proper grids removes that friction.

The plugin keeps doing the heavy lifting; the operator finally gets a view that matches how investigations actually work.