WP Social Share keeps its plugin-level configuration in wp_options (button networks, placement, post-type targeting) and writes per-post overrides as postmeta when a post deviates from the default. The default Settings page exposes the global config; per-post differences hide inside individual metaboxes.

SleekView reads both layers together and presents one row per post with columns for buttons enabled, placement, override source, and post-type. The Source column flags whether each post inherits the global config or overrides it, which is the audit surface relaunches and content reviews need.

Bulk actions on per-post overrides write the same postmeta keys the plugin's metabox writes, so a bulk 'reset to global' on a hundred selected rows behaves exactly as if an editor had clicked through one by one. The front-end share-button path picks up the change immediately.

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

WP Social Share's settings page shows the global; the post 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 configuration 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.