Cwicly builds on top of WordPress's block editor and Full Site Editing primitives, so its content lives mostly in the standard places: post_content with serialised block markup, wp_block for reusable patterns, wp_template and wp_template_part for FSE templates. The default Site Editor shows them through a graphical browser; the default admin Pages list shows title, author, date. SleekView reads the same post types directly so you build columns that show which patterns appear where, which templates target which post types, and which dynamic-data sources are referenced. Sort by usage or filter by pattern type without leaving the list.

Cwicly stores its custom CSS, design-system tokens, and dynamic-data references inside the block markup itself, with selected attributes mirrored to postmeta for indexing. SleekView decodes the parts useful for an audit — referenced global classes, used dynamic-data sources, custom-CSS length — so a content review can show every page using a deprecated global class or every template extending a removed dynamic source before you ship the change. On large installs it falls back gracefully when keys are missing, so the same view works across staging, prod, and freshly imported demos.

Inline edits go through wp_update_post and update_post_meta so Cwicly's caching invalidates and the next render picks up the change. Bulk-flip a batch of patterns from "synced" to "unsynced", or update template assignments across many rows by editing the relevant column directly. The same applies to ACF, Meta Box, or Pods fields used as dynamic-data sources — Cwicly reads them through the standard WordPress APIs and SleekView writes through the same.

Cwicly's biggest strength — that it builds on WordPress's native block, pattern, and FSE primitives rather than fighting them — is also why long-running Cwicly sites are hard to audit through the default admin. The Site Editor's pattern browser is a graphical tool, not a tabular one. Templates and template parts live on separate screens.

The dynamic-data references and global-class usage that drive Cwicly's design system are buried inside block markup. That works for a single brochure site. It does not work for an agency maintaining a Cwicly design system across a multi-brand portfolio, a SaaS company restructuring custom fields under hundreds of pattern references, or a content team trying to standardise pattern usage after years of ad-hoc choices.

SleekView turns the same data into the workspace each team needs: designers see patterns with usage counts and global-class references, editors see post-level views with the right templates assigned, ops bulk-update sync state before a release. Same database, same hooks, dramatically less clicking through the Site Editor.