Zola Processor

Purpose

Builds a zola site with the official zola binary, and gives every file zola writes a product of its own: its own cache entry, its own dependency edges, its own place in the graph for downstream processors.

Zola has no plan mode, so this processor computes the list of files zola will write itself, by reading config.toml and the content front matter the way zola 0.23.3 does. It is the mass generator contract, with the plan computed natively instead of by a predict_command.

How It Works

1. Plan. At graph-build time the processor reads the site and lists every output: pages (slug, slug/path overrides, dates in file names, language suffixes), sections, pagination, taxonomy lists and terms (with their pagination and feeds), site and section feeds, aliases, colocated and section assets, 404.html, sitemap.xml, robots.txt, the search index, highlighting stylesheets, compiled Sass, and the static tree. Each becomes a product.
2. Build. The first product that needs building runs zola build --output-dir <staging> --force into a private directory under .rsconstruct/; the others find it done. rsconstruct compares what zola wrote with the plan — exactly, both ways — and moves the planned files into the output directory.
3. Restore. When every product is clean, nothing runs; after rsconstruct clean outputs, every file is restored from cache without zola.

zola builds into staging rather than into the output directory because zola build deletes its output directory first: building into _site/ directly would delete the files other processors put there.

What a rendered file depends on

A zola template can read any page or section (get_page, get_section, sibling links, taxonomy listings, the paginator), so a rendered file’s content can change when another file changes. Every rendered output therefore lists as its sources the whole content/ tree, every template, the config file, and every data file a template or content file loads with a literal load_data(path = "..."). A file loaded through a computed path is invisible to the planner; list it in dep_inputs.

Static files and compiled Sass keep precise sources (the file itself, the sass/ tree), so editing a static file rebuilds one product.

zola runs once per build whenever anything it reads changed, regardless of how many products are dirty.

What is not supported

The planner refuses, by name, what it cannot predict, instead of guessing:

• a zola other than 0.23.3 (zola --version is checked on every plan; a zola upgrade means re-verifying the planner, which the fixture test does);
• theme, ignored_content, ignored_static, a [languages] table for the default language;
• resize_image in a template or content file (processed images are only known by rendering);
• sites rendering 30,000 or more HTML files (zola then splits the sitemap).

A disagreement that slips through anyway — a rule the planner gets wrong — fails the build with the exact list of missing and unexpected files, and leaves the staging directory in place for inspection.

Source Files

• Input: the zola site (config.toml/zola.toml, content/, templates/, sass/, static/)
• Output: every file zola build writes, under the output directory

Configuration

[processor.mass_generator.zola]
output_dir = "_site"       # Default: the site config's output_dir ("public")
# root = "site"            # The site directory, if not the project root
# dep_inputs = ["data/computed.toml"]
# loose_manifest = false   # true: report plan/build mismatches as warnings

Batch support

zola runs once per build, for all products together.

Clean behavior

This processor is a mass generator — rsconstruct clean outputs removes each planned output file individually with no directory recursion. After all per-product cleans complete, the orchestrator removes any parent directories that are now empty. Pass --no-empty-dirs to keep them. See Clean behavior and rsconstruct clean.

A file zola stops writing (a deleted page) has no product and is neither rebuilt nor cleaned; delete it by hand.

See also

• Mass Generator — the generic, predict_command-driven form of the same contract
• zola plan patch — the alternative: a plan mode inside zola itself, not used by this processor