AddToAny stores its placement settings in wp_options under addtoany_options (and historically A2A_SHARE_SAVE_options), with per-post overrides written as postmeta keys on individual wp_posts rows. The default Settings page shows the global config but offers no admin view of which posts override which buttons, or which post types have AddToAny enabled and which don't.

SleekView reads the option blob and the per-post override meta together, presenting one row per post with columns for buttons enabled, placement (above, below, floating), and override source (global vs per-post). Filter chips on post type and override source let editorial audit AddToAny coverage across the site without opening a single post.

For Pro features that log share events to a custom table or remote service, SleekView includes a row-level events view when the data sits in the local database. The plugin's settings stay the source of truth; SleekView is the audit and inventory surface alongside them.

Share-button placement is the kind of configuration that quietly drifts over years. A post gets an override because someone wanted Pinterest disabled on it; another post gets one because the floating sidebar overlapped a unique block layout; a category gets an exclusion that nobody remembers granting. Years later, the global config in addtoany_options says one thing and the actual per-post behaviour says something else, and nobody has the surface to audit the gap.

AddToAny's settings page shows the global; AddToAny's metabox shows one post at a time; nothing shows the gap. SleekView builds the coverage grid by joining the global option blob with every per-post override meta in the database, presenting one row per post with effective buttons, placement, and source. Editors audit relaunches in an afternoon, governance answers cookie-policy questions from a CSV, and maintenance teams bulk-normalise overrides that no longer match policy.

The plugin keeps owning configuration; the grid is where the inventory lives.