pom_get_available_shortcodes: list POM shortcodes
Which shortcodes exist on this site. Not a generic POM vocabulary — the actual catalogue, reflecting which theme modules are present and enabled.
Arguments
| Argument | Required | Meaning |
|---|---|---|
scope |
No | available (default), layout or theme |
post_type |
No | Only shortcodes usable with that post type |
include_inactive |
No | Include disabled theme modules |
Permissions
mcp:read and wp:content:read, with the edit_posts capability.
The three scopes
available — everything usable. The default, and the right choice for composing a page.
layout — only the layout shortcodes: rows, columns and their inner variants. Useful when the question is purely about structure.
theme — only the POM theme modules, the web_* family that produces visible elements.
The layout-versus-theme distinction mirrors how a POM page is built: layout shortcodes make the grid, theme modules fill it.
What it returns
An items list, a total, and a short rules list. Each item carries:
| Field | Meaning |
|---|---|
shortcode |
The tag, such as web_button |
label |
Human name |
description |
What it does |
source |
Where it comes from — layout shortcode, theme module, nested module |
module |
The owning module |
category |
Its grouping |
is_container |
Whether it wraps other shortcodes |
enabled |
Whether it is active |
Items are sorted by tag.
is_container is the field to read
A container shortcode wraps others; a non-container does not. Getting this wrong produces markup that parses but nests illegally — a module placed inside something that cannot hold it, or a container left empty.
vc_row, vc_column and their inner variants are containers. Most web_* modules are not.
Filtering by post type
Passing post_type removes shortcodes that declare themselves unusable there. On a site with custom post types and modules restricted to some of them, this is the difference between offering a client a usable palette and offering one that fails on write.
include_inactive
By default, disabled theme modules are excluded — a client should not compose with something the site has switched off.
Set include_inactive to true only when the question is "what could this site offer if enabled?", which is an audit question rather than an authoring one. Composing with an inactive module produces a shortcode that renders as nothing.
Using it well
List the available shortcodes and show me the containers separately from the modules.
Which layout shortcodes are available on this site?
For composing:
List the available shortcodes, then read the schema for each one you intend to use before writing anything.
That second clause is the point of this tool. Listing tells the client the vocabulary; only the schema tells it the grammar. See pom_get_shortcode_schema.
What it does not tell you
- Which attributes each takes. That is the schema tool, one shortcode at a time.
- How they nest. Broad rules come from the authoring context; specific parent-child constraints are enforced by the validator.
- Whether your composition is valid. That is
pom_validate_builder_content.
The list is a vocabulary, not a grammar and not a proof.
Reading a surprising result
| What you see | Means |
|---|---|
| Very few items | The POM theme is probably not active |
No web_* modules |
Theme modules are not registered here |
| An expected module missing | It is disabled; check with include_inactive |
| Items you do not recognise | Another plugin registers builder shortcodes too |
Related
pom_get_authoring_context— call this firstpom_get_shortcode_schema— the next callpom_validate_builder_content
On POM Theme sites, discovery includes only registered callbacks owned by the active POM parent or child theme. Historical shortcode names remain valid. Entries report registered and schema_status; registered_only means registration was found without a complete attribute contract. Default discovery excludes disabled modules.