Skip to content
delta

Content types

A content type is a kind of entry with its own listing page and detail page: projects, team members, courses, properties. WordPress calls it a custom post type. We chose not to build a post type registry into Delta. WordPress already has mature plugins for this work, and we would rather drive them than compete with them. So Delta drives one of the content plugins listed under Supported integrations, and Advanced Custom Fields is the usual proposal. The agent asks before it installs a plugin.

What one request creates

“Add a Courses content type with a level, a badge image, and a topics taxonomy.”

From that one sentence the agent creates four things:

  • The post type, with its labels, its archive, and its permalink base.
  • Each taxonomy you named, attached to the type.
  • A field group with the fields you named, attached to the type.
  • A field map for each field and each taxonomy, so the design can show the values as placeholders.

This documentation site is one example. Its docs, its recipes, and its release notes are three content types made this way, and they share one product taxonomy.

Delta has no screen that lists content types. Delta → Integrations shows which plugin is active. To see a definition, ask the agent, or open the plugin’s own screens.

Fields

The agent creates eleven kinds of field directly. They cover what a design can show without extra logic.

TypeHolds
textOne line of text
textareaSeveral lines of plain text
htmlFormatted content
urlA link
imageAn image from the Media Library
numberA number, with an optional minimum, maximum, and step
booleanYes or no
selectOne choice from a list you provide. Each choice can have a value and a label
dateA date
taxonomyTerms from one taxonomy
postsOther entries

A field can also carry instructions for the editor, a placeholder text, and, for a textarea, a row count. All eleven types are available with Advanced Custom Fields, Secure Custom Fields, Meta Box, and Pods; JetEngine has ten of them, without the link field. Custom Post Type UI creates types and taxonomies only, so for fields the agent pairs it with one of the others.

Richer fields, such as a repeater, a gallery, a group or flexible content, are made through the plugin’s own tools, which Delta runs for the agent. Delta maps them too, so the design can show them. See Field maps.

Advanced Custom Fields is the plugin we use most, including on this site. The other plugins follow the same contract in code, and we have spent less time with them. If one of them behaves differently from what this page says, we would like to know.

Permalinks

A type has a permalink base, which is the first part of its URL: /courses/{course}/. A taxonomy has one too: /courses/level/{term}/. Both accept slashes, so a taxonomy can sit under its type.

“Put course levels under /courses/level/.”

The two bases must be different. When a taxonomy base is the same as the type base, term archives and single entries compete for the same URL. We ran into this ourselves while building this site, and that is why Delta now warns the agent when a taxonomy base overlaps a type base. The save still goes through, so if a term page opens the wrong thing, ask for a distinct base.

A hierarchical taxonomy has parent and child terms in wp-admin. Its URLs stay flat by default. Nested term URLs, such as /topics/design/typography/, are a separate setting. Ask for it when you need it.

Changing a type later

A later request changes only what you name. A new label keeps the fields. A new taxonomy keeps the existing ones. Settings you made in the plugin’s own screens, such as labels, menu position, permalink settings and instructions written by hand, stay as they are, unless the field changes type.

Two things to know:

  • When the agent sends a list of fields, the fields it made are replaced by that list. Fields you added in the plugin’s own editor stay. To remove those too, ask the agent to replace the whole group.
  • A taxonomy or a field group is removed only by an explicit request. Leaving it out of a later request does not remove it.

A new type or taxonomy cannot take a name that WordPress or another plugin already uses, such as post, page, product or category. The agent tells you and proposes another name. With Custom Post Type UI, that plugin’s own checks apply too.

When you change a type, taxonomy or field group in the plugin’s own screens, Delta updates the matching field maps. This works with Advanced Custom Fields, Secure Custom Fields, Custom Post Type UI and JetEngine.

Removing a content type removes its definition from the plugin. The entries stay in the database, and WordPress hides them until a type with the same name exists again.

JetEngine

JetEngine is a content plugin too. One request creates the post type, its taxonomies and its meta box, as with the others. JetEngine also has relations, Query Builder queries, Custom Content Types, options pages and glossaries, and the agent creates and changes those through JetEngine itself. A new type, relation or query is registered on the next request, so the agent fills it in a second step. JetEngine is a paid plugin; you install it.

More than one plugin

When two content plugins are active, each type stays with the plugin that created it. A new type goes to the plugin that already holds the most types, and Advanced Custom Fields wins a tie. That rule comes from the code. We have not run a site with two content plugins for long, so treat it as designed behaviour rather than something we have observed at scale. To choose a plugin, say so: “Create the type in Meta Box.” A type’s fields are always written to the plugin that holds the type.

Advanced Custom Fields and Secure Custom Fields cannot both be active. Each one deactivates the other.

For developers

The abilities are delta/list-content-types, delta/get-content-type, delta/upsert-content-type, and delta/delete-content-type, the same four for content taxonomies and for field groups, and delta/sync-content-type-field-maps. They register only while a supported plugin is active.

delta/upsert-content-type is a partial update: omitted keys keep stored values. supports[] and objectTypes[] replace their list whole. A non-empty fields[] replaces the Delta-type fields of the {slug}_fields group; other fields stay and are reported as fields_retained. replaceAll: true removes them too (also on upsert-field-group and update-contact-form). Meta Box Builder removes Delta-type fields that are not resent even without it. syncFieldMaps: false holds the field-map sync for one call. A slug that post_type_exists() or taxonomy_exists() already knows is refused; type slugs are limited to 20 characters, taxonomy slugs to 32. Unknown field config keys return the warning config_keys_ignored. An empty rewriteSlug resets the base to the type or taxonomy key. A taxonomy base that shares a prefix with its type base returns warnings[] with code rewrite_prefix_collision, and the save proceeds. Synced field maps carry origin: synced; manual maps are not touched.

Related