WP Hide writes its configuration into wp_options with the wph_ prefix: rewrite slugs for wp-admin, wp-login, wp-content, and wp-includes, plus blocked-default rules and asset rewrites. The plugin's native UI is a long tabbed form, which is great for editing one tab at a time and slow when an auditor wants a single inventory of what is actually active.

SleekView reads wp_options directly and exposes the wph_ family as a dataset. Each row is one rule with the option name, current value, category (admin, login, asset, default), enabled flag, autoload flag, and the modified timestamp pulled from any change-history meta. Sort by category, filter by enabled status, search for a specific rewritten path, all from one workspace.

WP Hide keeps owning the rewrites themselves. SleekView only adds the audit surface, so saved views like Active admin rewrites or Default paths still stock cover the questions that the tabbed form was never built to answer.

WP Hide is effective when the configured rewrites actually match the intended posture. Without an inventory screen, that match is hard to verify, every audit means clicking through tabs and writing the active values into a spreadsheet. SleekView reads the same wp_options rows the plugin already maintains and renders them as one sortable, filterable table.

The plugin keeps owning the rewrites, SleekView just surfaces what is enabled and what changed. Saved views travel with the site, so the next maintainer inherits the audit table rather than rebuilding it from scratch. Filtered rows export as CSV for compliance evidence when an external review asks for it.