Folders for custom WordPress sites
Custom sites rarely stop at Posts and Pages. Case studies, team members, locations and resources each get a post type, and each one becomes another long admin list.
Any custom post type with a standard WordPress list can get its own folder tree: one switch in Settings, no code. Folders live only in wp-admin, so nothing changes on the front end.
You built the types. The lists still grow.
Custom post types solve the data model. They do not organize the admin: each one arrives as a flat list sorted by date, just like Posts.
A taxonomy for sorting becomes part of the site unless every argument is set with care, and custom filters are more code to maintain.
Content Folders gives each type a tree that lives only in wp-admin, and it switches on from Settings.
What you get for each post type
One switch per type
Settings → General → Enabled Sections lists the content types that have a standard WordPress list. Tick one and its list gets the folder panel and a Folder column.
Private by design
Folders have no URLs, no archive pages, no menu entries and are not part of the WordPress REST responses of your types.
Permissions follow the type
Users who can publish a type manage its folder tree. Users who can edit an item can file it. PRO role levels add Full, Upload, View and None.
A REST API for folders
Plathix PRO has its own REST routes for folders with a post type parameter, so trees and filing can come from a script or another system.
Clean removal
Deleting the PRO data removes the folder trees of every type. Posts, their fields and their meta stay.
Works with the tools you register types with
What matters is the list screen, not the tool: a type registered with a standard WordPress list can get folders.
Type and field builders
In code
Types that replace the WordPress list with their own screen or store their data in custom tables need separate support.
Your types and URLs stay as you built them
| What you do | What changes | What stays as it is |
|---|---|---|
| Turn on folders for a type | A private folder tree for that type | Rewrite rules, URLs, REST output of the type |
| File an item | Its folder assignment | Post data, fields, meta, templates |
| Deactivate PRO | The folder UI disappears | Folder data stays and returns with PRO |
| Delete PRO data | Folder trees of every type are removed | Posts, fields and meta |
One item sits in one folder at a time, and every type has its own tree.
How we test Content Folders for developers
We run each check on a live site with Plathix PRO, on the real list screens of registered post types.
Status 4 of 5 passed
Passed checks link to their results in Plathix Lab. The others are in progress.
| Check | What we verify | Status |
|---|---|---|
| Enable a type | Turn on Posts, Pages, Products, Events or Courses: the folder panel appears on each list. | Passed |
| Core Posts and Pages | Create folders, file content, switch folders, and confirm the list changes correctly. | Passed |
| Quick Edit | Change a folder from Quick Edit and confirm the assignment saves. | Passed |
| PRO off and on | Deactivate PRO, then reactivate it. Folder structure and assignments return. | Passed |
| Your own post type | A post type registered in code gets its panel and Folder column after one switch. | In progress |
Content Folders for developers FAQ
Do I need to write code?
Which post types qualify?
Do folders change rewrite rules or the REST output of my types?
What stays after the PRO data is removed?
Is this in Plathix Free?
Related pages
Model the data your way. Give the admin a tree for every type.
Folders for every custom post type with a standard list, one switch per type.