Code Snippets keeps its data in a single dedicated table called wp_snippets. Each row stores the snippet body, scope (admin, front-end, single use, snippet-content), priority, active flag, modified timestamp, and a comma-separated tags column. The default admin list paginates 20 rows at a time and lets you filter by basic scope, but it does not surface tags as filterable, does not let you bulk reorder by priority, and does not show which snippets have errored on activation.

SleekView reads wp_snippets directly and exposes each column as first-class data. The scope, tags, priority, last modified, and active state all become sortable filters. Tags are tokenised so filtering by a tag like cleanup or customer-feature works as a stacked filter instead of a free-text search. The view also surfaces the plugin's last error message column when a snippet was deactivated because of a fatal during activation.

Inline edits to the active flag, scope, priority, and tags route through Code Snippets' own update API so the cache of compiled snippets is invalidated correctly and the activation lifecycle (with the safety net) still runs. Bulk changes (deactivate a whole tag, reassign priority across a scope) batch through the same API so nothing skips the plugin's own validation.

Code Snippets is the closest thing WordPress has to a built-in scripting console, and it ends up running mission-critical glue on the sites that lean on it. Twenty snippets is a maintenance afterthought; two hundred is an operations problem. The default admin handles the simple case beautifully: write a snippet, save it, activate it.

It does not help when you need to know which snippets touch checkout, which were last edited by the contractor who left in February, or which were silently deactivated because a fatal fired during activation. The data is in wp_snippets, but the interface is a flat list. SleekView pivots that table into a workable view: tags become filters, priorities sort cleanly, errored activations show up as a one-click filter, and inline edits route through the plugin's own API so nothing breaks the compiled cache.

Snippet libraries already behave like a small, custom plugin system. They deserve a table that treats them that way.