WP Content Copy Protection blocks right-click, drag, and keyboard copy on the front-end. It carries a global default in wp_options, with a metabox in the page editor that writes per-post overrides into wp_postmeta. The combination of one global toggle plus a postmeta override per page is exactly the kind of configuration that gets out of sync quickly.

The plugin's default admin is a settings screen with checkboxes and a colour picker for the warning message. There is no list view that answers the question every content lead actually asks, which is which pages are currently protected and which have been opted out. Walking the page list and opening each metabox is the only way to see the state today.

SleekView reads the global option, joins it to the per-post override in wp_postmeta, and renders one row per page or post. Each row carries the title, the post type, the resolved protection state, the override source, and the last-modified date. Edits write back through the plugin's own metabox API, so the change is the same one a content lead would make from the page editor.

WP Content Copy Protection does a small thing well, it blocks the right-click and the selection script on the front-end based on a global toggle and a per-page override. The trouble is that the global toggle in wp_options and the override in wp_postmeta never appear together on one screen. Content leads need to know which pages are protected and which are deliberately allowed, like the press kit.

Editorial teams need to know whether a new post inherited the global rule or carries its own. Site admins need to spot a change that landed during a busy week. SleekView reads both stores and renders one grid where every post or page sits next to its resolved protection state and the source of that state.

Edits route back through the plugin's metabox API, so the change is the same one the editor would make. The integration keeps owning the front-end behaviour, and the team finally gets the audit workspace the plugin never tried to ship.