# When something is wrong

> What publishing refuses and why, in the validator's own words — the three messages you are most likely to meet, and what each one is telling you.
>
> From the MightyBuilder documentation: https://docs.mightybuilder.ai/dynamic/when-something-is-wrong

Publishing checks every template before anything goes live. If it refuses, the
message names the page, the expression and the fix — they are written to be read
rather than logged.

## Nothing broken reaches the live site

The check runs against your drafts, and a failure leaves the live site exactly
as it was. You have not half-published anything.

## The ones you are most likely to see

### Filters in a `{% for %}` are ignored

> filters in a {% for %} are IGNORED — the loop runs over everything. Assign the
> list first

The one real trap in the language, and the reason it blocks rather than warns:
the page renders fine and lists the wrong things. Move the filters to an
`assign` — see [Sorting and filtering](/dynamic/sorting-and-filtering).

### A field that does not exist

> a page has no "summary" — it has postId, title, url, path, date, lastmod,
> excerpt, tags, image, parent, parentId, order

Usually a near-miss: `summary` for `excerpt`, `slug` for `path`, `name` for
`title`. The message lists the real fields, so the fix is in the error.

This is also what you get when a field is renamed underneath you — which is why
the check exists rather than trusting that a template that worked still does.

### A `where` with nothing to match

> "where" needs a value to match — where: "tags", "recipes"

`where` takes a field **and** the value that field has to have. One argument
alone reads as "keep the items that have this", and it does not do that — so it
is refused rather than left to return nothing quietly. Test the field inside the
loop instead. See [Sorting and filtering](/dynamic/sorting-and-filtering).

### A Liquid tag that is not in the vocabulary

> its markup does not parse: tag "include" not found

Liquid exists in several products with different tag sets. Things like
`include`, `section` and `paginate` belong to other ones. The tags here are the
ordinary Liquid ones plus `render`, the `guard` every form carries, and
`item_body`, which only a collection's layout uses.

Nothing after a parse error renders, which is why this one stops the check
rather than adding to a list.

## Warnings are not refusals

Some things are reported without blocking — they might be exactly what you
meant. A publish with warnings goes out, and the warnings are there to be read
afterwards.

The one worth reading every time:

> no page or article has the tag "recipies", so this list is empty. This site
> uses "bread", "news", "recipes"

A tag you have not used yet is a perfectly good empty list, which is why this
does not refuse. But it is also what a **retag** leaves behind: change the last
`sourdough` article to `bread` and the sourdough page still renders, still looks
right, and lists nothing. See [Tags](/dynamic/tags).

The line is: **structurally broken blocks, anything that might be deliberate
warns.** A check that blocked on taste would become a thing people learn to
fight.

## If the message does not help

Say what you were trying to do in the AI panel and paste the message. It reads
the same error, and it wrote the markup in the first place.