Post Types

Post types and taxonomies created in the admin, stored in the ACF 6 format.

kitloom/post-types · admins: kitloom/post-types-filament, kitloom/post-types-nova

Post types and taxonomies made in the admin, the way the ACF plugin makes them (ACF → Post Types and ACF → Taxonomies): "Books" with their "Genres", "Events", "Team members". Once a type is saved and active, it has its own section in the admin, its pages on the site, its settings pages and its capabilities — no code and no deploy.

The admin screens come with kitloom/post-types-filament or kitloom/post-types-nova.

Where to find it

Custom Fields → Post Types and Custom Fields → Taxonomies, next to the field groups, as in the ACF menu. The screens need the "Manage post types and taxonomies" permission (manage_post_types), which administrators have. The same people see How post types work near the end of that section — this page; How it works after it is the field groups' own.

The lists show every type, active or not, with how many posts or terms it has.

Making a type

The form asks for what the ACF form asks:

• Plural Label and Singular Label — "Books", "Book". The other labels ("All Books", "Add New Book"…) are filled from these two; a label written by hand on the Labels tab stays.
• Key — the name the records are stored under, book: lower case letters, digits, underscores and dashes, at most 20 characters for a post type and 32 for a taxonomy. Words WordPress keeps for itself (post, page, attachment, category, order…) and keys another type already uses are refused. Choose it with care: the posts and terms are stored under it, and a key changed later leaves them behind under the old one.
• Taxonomies of a post type, or Post Types of a taxonomy — either side may name the other.
• Public and Hierarchical (items have parents, like pages).
• Active — an inactive type keeps its definition and its records, but is not registered: no admin section, no pages on the site.

The tabs below hold the rest of the ACF settings:

Tab	What it decides
General	What the editor offers (Supports: title, editor, featured image…), a description. Taxonomies: term order, a default term.
Labels	Every label, for the admin.
Visibility	Whether the type has an admin section (Show In UI) and a menu item (Show In Admin Menu), whether it is offered in menus, whether search finds it.
URLs	The address: the key (/book/my-book/), a custom slug (/books/my-book/) or no address at all; whether the front part of the post permalink comes first; an archive and its slug; for a taxonomy, whether a term's address goes through its parents.
Permissions	For a post type, its own capabilities (Rename Capabilities: edit_books instead of edit_posts); for a taxonomy, the capability each action needs.
REST API	Whether the type is in the REST API, and its base URL.

Saved here, a type looks in the database exactly as one made in WordPress with ACF: it opens in ACF, and one made in ACF opens here.

What a type gets

• An admin section with its records, named after the type; in Filament after Comments, in the order the types are listed. A taxonomy sits in the section of its first post type (Posts or Pages for those). A type the site already edits with a resource of its own keeps that resource.
• Pages on the site, as WordPress would register them: single records, the archive when it is on, term pages, search results unless the type is excluded. A type that is not publicly queryable, or has no address, has no pages. New addresses work from the next request.
• Settings pages for every type with pages on the site (SEO → Titles & Meta and the like), grouped under the type's menu name together with its taxonomies; a taxonomy of no ACF type goes under "Taxonomies".
• Capabilities: a post type with renamed capabilities is guarded by its own, a taxonomy by the ones its definition names. The roles screen shows them.
• Fields: a field group of kitloom/custom-fields whose location names the type puts its fields on the type's form.
• Revisions: a new type supports them (title, editor, featured image, custom fields and revisions), so a change can be taken back from the record's Revisions; a type made before keeps the features it was saved with — tick Revisions under its features to add them.

Records are read with the site's plain post model. A theme may read a type with a model of its own (ContentTypes::MODELS_TAG, as kitloom/game-reviews-theme does), and the application can change how a type is addressed in kitloom-site.types.

Where the data lives

A definition is a row of wp_posts, as ACF 6 keeps it: post type acf-post-type or acf-taxonomy, the definition key (post_type_…, taxonomy_…) in post_name, the plural label in post_title, the list order in menu_order, every setting in post_content. An active definition is publish, an inactive one acf-disabled. Settings are written as JSON; definitions ACF left serialized are read as they are and become JSON when saved here.

The package has no tables or migrations of its own. The admin screens are switched off with kitloom-post-types.filament.register / kitloom-post-types.nova.register.

AI agents

With kitloom/ai installed, an agent whose user has manage_post_types works with the post types and taxonomies made here, as the two screens do: post_types_list and post_types_get read them, post_types_create makes a post type or a taxonomy from a key and two labels (the rest from WordPress's defaults), post_types_update changes only the fields it sends — a disabled type keeps its records — and post_types_trash / post_types_restore move a definition to the trash and back. Nothing is deleted for good; keys are checked as on the form. Records of the types are written with kitloom/ai's own content tools. kitloom-post-types.ai.register false (php artisan vendor:publish --tag=kitloom-post-types-config) — no post type tools.

For developers

Definitions (scoped, one query per request) lists the active definitions; Support\DefinitionWriter saves one as the ACF form does — a new one from the plugin's defaults, then only the settings the form shows, lists replaced, the labels filled — and Support\DefinitionKeys checks a key. The definitions reach the rest of the platform through tags:

Tag	Class	For
PostTypeRegistry::PROVIDER_TAG, TaxonomyRegistry::PROVIDER_TAG	Providers\AcfPostTypeProvider, Providers\AcfTaxonomyProvider	kitloom/wp-schema's registries
SettingsPagesRegistry::PROVIDER_TAG	Providers\AcfSettingsPagesProvider	settings pages per type
Capabilities::PROVIDER_TAG	Providers\AcfCapabilities	capabilities of renamed types
ContentTypes::TAG	Site\AcfContentTypes	addresses on the site, the content model