FluentSnippets Pro stores its snippet records in fluent_snippets with companion data in fluent_snippet_meta. Each row tracks the snippet name, type (PHP, JS, CSS), scope, priority, status, tags, error flag, last modified timestamp, and (in Pro) run counters. The default admin shows snippets in a card grid that paginates well for ten rows but stops scaling once a site has fifty or more snippets across multiple tags and scopes.

SleekView reads fluent_snippets and joins in the relevant fluent_snippet_meta entries to expose each field as a sortable column. The scope, tags, status, error flag, and run counter all become first-class filters. The Pro plugin's per-snippet run timing surfaces as a column so you can sort by average duration to find the snippet that's quietly slowing the request lifecycle.

Inline edits route through FluentSnippets' own update API so the compiled cache invalidates, fatal-protection logic still runs on activation, and the plugin's audit log records each change. Bulk operations (pause a whole tag, retire snippets in a deprecated scope) batch through the API so validation runs once per row.

FluentSnippets Pro is one of the rare snippet managers that records what its snippets actually do at runtime: how often each snippet fires, how long it takes, and whether it errored along the way. That data lives in fluent_snippet_meta, beside the snippet bodies themselves. The default admin surfaces a card grid for editing snippets and a separate analytics panel for the metrics.

The two never meet in one place. So when a snippet quietly costs 18 ms per request, you find out through Query Monitor or a slow-page complaint, not from the snippet UI. SleekView pulls the schema and the metrics into a single table.

Sort by average duration, find the snippet that needs attention, and pause it inline. The data was already there. The interface for working with it as data was missing.

SleekView fills that gap without changing how FluentSnippets stores anything underneath.