pom_validate_builder_content: validate builder content
The last check before page content is written. It parses the proposed content, resolves every shortcode against this site's catalogue, and reports what is wrong.
Arguments
| Argument | Required | Meaning |
|---|---|---|
content |
Yes | The full proposed page or post content |
target_type |
No | The kind of target |
target_id |
No | A post or page ID, used for the capability check |
Passing target_id tightens the permission to edit_post on that specific item.
Permissions
mcp:read and wp:content:read, with edit_posts or edit_post.
Read-only. It validates the content you pass; it never touches the page. Block documents delegate to block validation, whose result additionally reports its server-only scope and the remaining browser save check.
What it returns
| Field | Meaning |
|---|---|
valid |
False when any error was found |
issues |
Every problem, each with severity, path, message and suggestion |
summary |
Counts of shortcodes found, errors and warnings |
next_steps |
What to do about them |
Each issue carries a path locating it in the content, which is what lets an assistant fix the right element rather than rewriting everything.
Errors versus warnings
Errors make valid false. Do not write content with errors.
Warnings do not block the write. They identify a limitation or a decision to inspect; they do not prove that an attribute or module works.
Warnings are worth reading. They are how the tool tells you a page is reaching for a discouraged element or leaning on inline styles instead of the attributes that exist for the job.
What produces an error
PHP tags. Not permitted in page content, at all.
Script tags. Not permitted.
Empty content.
Illegal nesting, which is where most real errors come from:
vc_columnnot directly insidevc_row;vc_row_innernot inside a column;vc_column_innernot directly insidevc_row_inner.
Attribute and parent-child violations from the individual shortcode schemas.
What produces a warning
An unknown shortcode on a non-POM site, with the suggestion to call pom_get_available_shortcodes first. On POM sites an unknown, disabled or unrelated shortcode is an error because it falls outside the available POM palette.
A discouraged element, naming the replacement. vc_btn should be web_button, vc_single_image should be web_image, vc_empty_space should be web_gap, and so on.
Inline style blocks, and content using more than two inline style attributes.
Nested vc_row, with the suggestion to use vc_row_inner.
No builder shortcodes detected in content that looks like it should have them.
No top-level vc_row in content that otherwise uses the classic builder.
Using it well
Validate this content and show me the issues, grouped by severity. Do not write anything yet.
The final clause matters — an assistant will otherwise validate and write in the same turn.
When it fails:
Fix only the errors, then validate again and show me the result.
The failure pattern worth recognising
If the same content fails validation two or three times with unknown-shortcode or attribute warnings, the assistant is composing from an assumed vocabulary rather than this site's.
Iterating on the markup will not fix that. Send it back to pom_get_available_shortcodes and the specific schemas.
Validation is not verification
Passing means no server validation error was found. Unknown attribute warnings still require the actual module or editor contract. It says nothing about whether:
- the page looks right;
- the copy is accurate;
- it works at mobile width;
- the content the modules reference actually exists.
After writing, open the rendered page. See Build POM builder content.
It is also used on templates
pom_validate_template_markup runs this validator over template markup as part of its own checks, and folds in any errors it finds. Template markup can contain shortcodes, so the same rules apply — which is why PHP in a template is an error from two directions.