weDocs models documentation as a hierarchical custom post type called docs. A doc has sections as children, sections have articles, and each level is its own post with post_parent linking it to its container. The default admin list shows posts, but the hierarchy is collapsed into a single flat list with no easy way to see which articles belong to which doc, which sections are empty, or which articles haven't been touched in months.

SleekView reads the docs CPT and resolves post_parent into a readable parent-doc column and a section column. Editors get a flat editable table where every article shows its parent doc and section, the author, the last-updated date, and the status. Filters compose across those columns, so a saved view like 'articles updated more than nine months ago in the Getting Started doc, ordered by views' becomes one click instead of a multi-step taxonomy walk.

Inline edits cover status, parent assignment, and menu order. Edits go through standard WordPress APIs, so save_post fires and any search index or sitemap regenerator runs exactly as it would from the post-edit screen. CSV export of any saved view gives editorial leads a snapshot of coverage and staleness without writing a single SQL query against wp_posts.

Documentation rots quietly. The articles published in launch month answer questions that no longer apply, while customer queries shift to features that were documented two years ago in a now-buried child of a child of a parent doc. weDocs gets the storage model right, hierarchical posts are the cleanest way to express documentation structure in WordPress, but the default admin collapses that hierarchy into a flat list that hides the editorial signal.

Which doc has the most stale articles. Which author hasn't updated their assigned section in six months. Which section is empty because the original writer left before finishing it.

Those questions need a flat editable table that resolves the hierarchy into columns and lets editors filter across the whole library at once. SleekView delivers that without forking weDocs or asking it to change how it stores data. The same docs CPT, the same post_parent chain, the same postmeta, the same hooks, but now in a table that surfaces what an editorial lead actually needs to decide what to rewrite next.