Admin and Site Enhancements MCP for custom fields and content types

Building a new content type in ASE, in dependency order

A typical request is a small directory: a Venues post type, a Region taxonomy attached to it, and a field group with address, capacity and booking email shown only on venues. With Admin and Site Enhancements the agent should build it in that order. ase-create-post-type needs a slug of up to twenty characters, a plural title and labels.singular; ase-create-taxonomy takes the post types it attaches to; ase-create-field-group comes last, because its location rules point at the post type that now exists.

Each create is idempotent. Re-sending an identical definition returns created false instead of a duplicate, which makes a retry after a dropped connection harmless. Sending the same key or slug with different data is refused with ase_field_group_exists, ase_post_type_slug_conflict or ase_taxonomy_slug_conflict, so an agent cannot overwrite an existing definition by accident while thinking it is creating one. Duplicate field names inside one fields array are caught as ase_field_name_collision before anything is saved.

Finish by checking the result as an editor would see it: the post type in the admin menu, the taxonomy box on a venue, and the field group on the venue edit screen and nowhere else. If the menu item is missing, go back to ase-check-setup before suspecting the definition.

Renaming labels without regenerating them

When a client decides Venues should be called Locations, two different changes hide in that sentence. The visible names are labels, and changing labels.singular or labels.plural through ase-edit-post-type does not regenerate the auto-built cpt_label_* keys; screens such as Add New Location keep the old wording until each string is overridden through labels_full. Read the current set first with ase-get-post-type and include labels_full, then send only the strings that should change.

The slug is the second change, and it cannot be edited at all. Renaming it means deleting the definition and creating a new one. Deleting keeps the existing posts in wp_posts unless force_delete_content is true, but those posts still carry the old post type name, and a new definition with a new slug does not adopt them. Moving them across is a database change in its own right, so for most clients the honest advice is to change the labels and leave the slug alone.

Repairing older field groups and reading values for an audit

Field groups created by hand, by an import or by an earlier tool sometimes lack keys ASE's canonical shape expects. ase-edit-field-group repairs them as a side effect: passing the fields array normalises every field to ASE's full key set, and touching show_in_rest_api fills the complete extras block. Re-saving a group through the ability with its own current fields is therefore a deliberate fix, not a no-op, and worth doing on staging first.

For content audits, remember what ase-read-values hides by default. only_with_values is true, so empty fields are dropped from the answer. That keeps context small on a full post, but when the question is which venues have no booking email, set it to false or the gaps will not appear. The format option matters too: api returns ASE-processed values for display, input returns what the edit form expects, and raw returns the database string, which is the one to compare when two values look the same on screen but differ in storage.