pom_validate_template_markup: validate template markup

The last check before a template is saved. It validates the HTML, every merge tag, the conditional structure and any embedded shortcodes.

Templates apply to many pages at once, which makes this the most valuable validator in the set.

Arguments

The type decides which merge tag catalogue the markup is checked against, so passing the wrong one produces errors for tags that are perfectly valid elsewhere.

Permissions

mcp:read and pom_theme:read, with edit_theme_options.

Read-only. It validates what you pass; it never saves a template.

What it returns

Merge tag issues carry a path of the form merge_tag@offset, locating the token in the markup.

Errors

PHP tags. Never permitted in HTML templates.

Inline <script>. Select existing scripts with js_scripts from pom_theme_get_script_catalog; creating JavaScript is unavailable.

Empty markup.

An unknown merge tag, naming the context to check. This is an error rather than a warning, because an invalid tag renders as nothing on every page the template covers — silent and multiplied.

An empty merge tag token, meaning {{}}.

Broken conditionals:

• {{else}} outside an {{if}} block;
• {{/if}} closing a block that was never opened;
• an {{if}} left unclosed.

Any error from the builder validator, since template markup can contain shortcodes. Illegal nesting and script tags in embedded shortcode content surface here too.

Warnings

Inline <style>, with the suggestion to use the template's CSS asset field or shortcode attributes.

{{if}} without both meta and value, suggesting the form {{if meta="meta-key" value="not_empty"}}.

Archive templates without {{archive_results}}, which produces a listing page with no results.

Archive templates with more than one {{archive_results}}, unless duplicate loops are intentional.

The archive check is the useful one

An archive template missing its result loop renders a page that looks like a data problem — an empty listing — and is a template problem. It is easy to produce when composing markup section by section and never adding the loop.

Two loops is the opposite mistake, usually from copying a block, and it renders every result twice.

Conditionals are tracked properly

The validator maintains a stack as it reads the tokens, so it catches unbalanced blocks wherever they occur and reports the position of the offending token.

That means a template with several nested conditionals gets a precise answer rather than a general complaint, which is what makes fixing it quick.

Using it well

Validate this archive template and show me every issue with its position. Do not save anything.

When it fails:

Fix only the errors and validate again.

Before a template goes anywhere near assignment:

Validate the markup, then show me the current template assignments before changing them.

Validation is not verification

Passing means the markup is well-formed, the merge tags exist, the conditionals balance and the shortcodes are legal.

It does not mean the template renders well. After saving and assigning, check:

• a post with and without a featured image;
• a very long and a very short title;
• an archive with one result, and with none;
• the first page and a paginated one;
• mobile width.

See Create and assign POM Theme templates.

Feed templates

Validate template_html. The generated template_php and template_php_hash are artifacts, not editable source — see pom_get_template_schema.

Related

• pom_get_available_mergetags
• pom_validate_builder_content, which runs as part of this check
• Theme template tools