Even adding only 'custom-fields' to bricks_template's supports turned out
to break the Bricks builder ("Invalid post type" on Edit with Bricks for
all templates including pre-existing Header / Footer).
bricks_template is now left exactly as Bricks registers it natively :
supports : author, revisions, thumbnail, title
show_in_rest : false
The MCP server route to bricks_template was experimental and we don't use
it actively — direct PHP scripts (av-fix-template-meta, av-generate-*,
av-add-submenus) handle template management. Templates are exposed only
to the Bricks builder, not external REST clients.
case_study + scenario CPTs keep REST exposure (used for content type
generators later).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The REST bridge was rewriting the `supports` array on bricks_template (and
case_study, scenario) by force-adding ['title','editor','author','custom-fields'].
For bricks_template specifically, Bricks's own registration sets supports =
['author','revisions','thumbnail','title'] — deliberately WITHOUT 'editor',
because the post type is meant to be edited only via the Bricks builder, not
the WP block editor.
Adding 'editor' confused Bricks's builder : it would refuse to open the
template with "Invalid post type" because the post type now claimed to support
two incompatible editors.
Fix : keep the original supports list untouched, only append 'custom-fields'
(which IS required for /wp/v2/<type>/<id> to expose the `meta` field). All
templates (Header #25, Footer #46, Single Post #154) should now open in the
Bricks builder again.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
