Validate builder or template markup before writing

Structured content — POM builder shortcodes and theme template markup — fails in ways plain text does not. A missing closing tag or an invented merge tag produces a page that renders wrongly rather than an error.

The authoring tools exist to catch that before the write.

The validators

Both are read-only. They cost nothing, change nothing, and can be called as often as needed.

The schema tools that come first

Validation catches mistakes; the schema tools prevent them.

An assistant that reads the shortcode schema writes valid markup. One that guesses writes markup that looks plausible and uses parameters that do not exist.

The sequence

For builder content:

1. pom_get_authoring_context for the target page.
2. pom_get_available_shortcodes.
3. pom_get_shortcode_schema for each shortcode it intends to use.
4. Compose the content.
5. pom_validate_builder_content.
6. Fix anything reported, and validate again.
7. Write with wp_update_page or wp_update_post.
8. Read the page back.

For templates, substitute pom_get_template_schema and pom_get_available_mergetags at steps 2 and 3, and pom_validate_template_markup at step 5.

Ask for it explicitly

Read the authoring context for this page and the available shortcode schemas before writing any content.

Validate the builder content and show me any errors before saving.

Validate the template markup and its merge tags, then wait for my confirmation.

Without being asked, an assistant will often compose and write in one step.

Why merge tags deserve particular care

An invalid merge tag does not throw an error. It renders as literal text, or as nothing, on every page using that template.

Because templates apply across many pages, a bad tag is both more visible and harder to trace than a broken single page. Validate them every time.

Validation is not verification

The validators check that markup is structurally valid and that the shortcodes and tags exist. They do not check that the result looks right, that the copy is accurate, or that the layout works on mobile.

After writing, look at the rendered page. See Build POM builder content.

Dry runs are the other half

Many write tools accept a dry_run argument. Where supported, it reports what the tool would do without doing it — for an update, typically a before-and-after comparison.

Use both: the validator checks the content is well-formed, the dry run checks the write would land where you expect.

Use a dry run first and show me the before and after.

Support is per tool, not universal. Check the tool's own page in chapters 11 to 21.

Preserving structure on an existing page

Rewriting a builder page wholesale is the fastest way to lose its structure. The server publishes a prompt specifically for this — update_pom_builder_page_preserving_structure — and it is more reliable than describing the constraint yourself.

Where a published prompt covers your job, start from it. See Prompt recipes.

When validation fails repeatedly

If the same content fails validation two or three times, the assistant is probably working from an assumed shortcode vocabulary rather than the site's real one. Send it back to pom_get_available_shortcodes and the specific schemas rather than iterating on the markup.

Related

• Inspect content before changing it
• Build POM builder content
• Work with POM Theme templates
• Authoring tools for the tools in detail