pom_theme_get_template_assignments: inspect assignments
Reports which template renders each part of the site.
Arguments
None.
Permissions
mcp:read and pom_theme:read, plus edit_theme_options.
What it returns
| Field | Covers |
|---|---|
post_archive |
The blog archive layout |
post_archive_feed |
The result item template on the blog archive |
post_single |
The layout for single posts |
cpt_archive |
The raw archive settings for custom post types |
custom_post_types |
One entry per custom post type |
Each custom post type entry gives its slug, archive_layout, feed_template and single_layout.
Values are either a built-in layout or a template identifier
The same field holds both, which is the thing to understand before reading the response.
| Type | Built-in values |
|---|---|
| Archive | left, right, full-width, contained-width, both |
| Single | simple, vc |
| Feed | default |
Anything else is a custom template identifier. So right means the theme's built-in right-sidebar layout; an opaque string means a custom template.
Cross-reference the identifiers against pom_theme_list_html_templates to turn them into names:
Read the assignments and the template list, and tell me which named template renders each thing.
An empty value is the theme default
A field returning an empty string means nothing has been assigned and the theme's own default applies. That is normal on a site that has never customised templates — not a fault.
This is the tool for "which templates are unused"
The listing shows what exists; this shows what renders. Together they answer the question that matters before any deletion:
List the templates and the assignments, and tell me which templates nothing points at.
Unused templates are safe to delete. Assigned ones are not — see pom_theme_delete_html_template.
Stale identifiers are shown as if valid
If a template was deleted while assigned, the assignment still names it. This tool reports that identifier without checking it still exists.
So an identifier here is not proof of a working template. The cross-reference against the listing is what catches it, and a dangling assignment is worth fixing when you find one.
cpt_archive is raw, custom_post_types is readable
cpt_archive returns the underlying settings, keyed by internal field names. custom_post_types presents the same information per post type, already resolved.
Use custom_post_types for anything you are reporting to a person. Use cpt_archive only if you need a field the resolved view does not surface.
Note that single-post-type layouts live with the post type definition rather than in cpt_archive, which is why they appear in the resolved view and not the raw one.
Read it before assigning
pom_theme_assign_template overwrites without reporting what was there. This response is the record of the previous assignment — the thing you would need to undo a change.
Read the assignments, then change only the blog archive.
Using it well
Auditing a site:
Show me every template assignment, with the template names rather than identifiers.
Diagnosing:
The products archive looks wrong. What is assigned to it?
Common problems
| Symptom | Cause |
|---|---|
| The tool is missing | POM Theme is not available |
pom_ai_mcp_forbidden |
Missing edit_theme_options |
| An empty value | Nothing assigned; the theme default applies |
A value like right or simple |
A built-in layout, not a template |
| An identifier that matches no template | The template was deleted while assigned |
| A post type is missing from the list | It is not a POM Theme custom post type |
Related
pom_theme_assign_templatepom_theme_list_html_templates— resolve the identifiers- Inspect a site