The official Cloudflare for WordPress plugin keeps its configuration in wp_options under keys like cloudflare_api_email, cloudflare_api_key, cloudflare_cached_domain_name, and a serialized cloudflare_config array that includes APO state, image resizing toggles, and security level overrides. When APO (Automatic Platform Optimization) is enabled, the cache configuration covers the whole site through Cloudflare workers, with bypass rules stored alongside.

The default admin presents these as a settings tab inside the plugin. There is no list view of every cache rule, no count of how many URLs each bypass matched, and no log of recent purges. Operators see a status banner and a few toggles; reviewing the full configuration means reading the serialized option directly or trusting that the toggles match the dashboard at Cloudflare.

SleekView reads cloudflare_config and the surrounding option keys, unpacks them into rows, and presents them as a queryable surface. One row per setting can show its key, current value, scope, and last update time. Inline edits route through the plugin's own settings update path so the runtime stays consistent. Saved views like APO state or Bypass rules can be scoped per role for delegating cache tuning without exposing API tokens.

Cloudflare sits in front of an enormous slice of the WordPress web, and the official Cloudflare for WordPress plugin is the most common way that integration is configured. APO especially changes how the whole site is cached, because the entire HTML response goes through Cloudflare workers rather than being served by WordPress on every request. That power demands visibility.

The plugin's tab inside WP Admin presents a few toggles and a status banner, which is fine for the initial setup, but offers no surface for audits or for delegating ongoing tuning. Bypass rules and security overrides drift over time, and there is no row level view to confirm what is currently active. SleekView reads cloudflare_config and the surrounding options, unpacks them into rows, and lets the right roles edit the right subset without exposing API credentials.

The plugin keeps owning the runtime; SleekView just makes the state legible to the humans responsible for it.