Why a list goes stale

Everything on a MightyBuilder page is written out. That is usually the right answer, and there is one shape where it is not.

The problem, before the tool

Say you have a blog index listing nine articles. Each card is a heading, a picture, a date and a line of text, written into the page.

Then you publish a tenth article.

The index does not know. It still lists nine, and it will list nine for ever, because the only thing that can change it is another conversation with the AI — which costs credits, has to be remembered, and has forty other pages in reach while it is in there.

Nothing about the page looks wrong. It renders perfectly. It is just out of date, and it went out of date silently.

Where this bites

Any list that is derived from something else in the site:

• a blog, news or case-study index
• a services grid that should match the service pages
• a team page
• “more like this” at the foot of an article
• a footer sitemap
• a navigation menu that knows which item you are on

Every one of those has the same shape: the content already exists elsewhere in the site, and the list is a second copy of it.

The fix

A page can ask the site what pages it has, and build the list when it renders. Add the tenth article and the index has ten, without anybody touching it.

That is what this section is about. It is one loop and one set of fields, and the next page builds a real one end to end.

The judgement

This is worth knowing before you start: most lists on most sites should stay written out. Three feature columns are three blocks of markup. A loop over three things that will never change is harder to read, harder to edit, and buys nothing.

The test is whether the list is derived. If adding a page somewhere else in the site should change this list, loop it. If not, write it.

There is a page on exactly that judgement at the end of this section: When not to use a loop.