Custom Fields Suite is the long-standing free alternative to ACF, known for storing field values in its own dedicated tables rather than in postmeta. That design is good for query performance and for keeping postmeta clean, but it also means the data sits in a place the standard WordPress admin does not surface at all. Editors see the field UI on the post screen; the list table never sees the values.

SleekView reads the cfs_values table CFS writes to, joins it with wp_posts and renders the result as a real list table per field group. Loop field row counts, relationship targets, select values and text inputs each become their own column. Sort by a number field, filter by a select, find every post missing a required field. Inline edits go through CFS's documented save path so registered save hooks continue to apply.

Because CFS uses its own tables, the queries are fast even on large content models. The same dataset that powers the table can be switched to a kanban or feedback view, useful when one of the fields drives a workflow.

Custom Fields Suite has stayed a quietly popular alternative to ACF largely because of two design choices: it stores values in its own tables and it keeps the field UI tight. Both choices pay off for performance and for postmeta hygiene, and both choices also make the data harder to see and edit in aggregate from the standard WordPress admin. Editors interact with one record at a time; nobody on the team has a list view until somebody writes a SQL query.

SleekView pulls the cfs_values table into the same dataset family as wp_posts and wp_postmeta, so the editing surface reaches into CFS's own storage rather than ignoring it. Field group coverage becomes a list, loop usage becomes a sortable column, audit work becomes a saved view. The build that already runs CFS keeps every advantage of its design choice and gains the missing editing layer for free.