Hwaro::Content::Hooks::ImageHooks

Max number of concurrent image processing fibers

The encode settings a width variant set depends on (besides the source): the JPEG quality and the LQIP knobs. Each stamp is per file, so the output format is already in the name it is kept under.

The chosen variant as {actual_width, url}.

The width matters to the caller, not just the URL: no variant is ever upscaled, so a 900px source asked for 1024 resolves to the 900px file. resize_image() reported the REQUESTED width, which is what a template writes into <img width=…> — a number the browser then uses to lay out an image that is a different size.

The format variants by original URL, read-only like resize_map_readonly; nil when none were generated.

Intrinsic {width, height} of source, read from its header once per version of the file.

The fill/crop variant of url (backed by source) as {variant_url, width, height}, written into the output directory on first use and reused while it is newer than the source. The name carries size, op and anchor (photo_400x300_fill_center.jpg), so no two requests share a file. The file is claimed for the build and, when page_path names the rendering page, recorded as that page's derived output so a warm --cache build that skips the page keeps it. nil when ops are off for this build or the variant can't be made.

Source file behind url as of the last image:resize run, or nil when no image job covered it.

Did any of paths (project-relative) back a size or a variant a render printed? The serve watcher escalates such a change to a rebuild, like a load_data() source.

The image:resize hook only runs on full builds, so modified image BYTES under serve's :static / :content_files change paths left the resized variants (and LQIP data) stale — the watcher only re-copied the original. Re-runs the resize pipeline for exactly the changed images and folds the results into the class-level maps.

pages (when given) also covers page-bundle assets: an image inside a page bundle publishes its variants under the owning page's URL, not its content-relative path.

Returns the number of variant sets regenerated.

Read-only access to the resize map for the render phase. The map is populated once by the BeforeRender image:resize hook and is never mutated during rendering, so render workers can read it directly instead of paying a full .dup of the (potentially large, site-wide) map per image-bearing page and serializing on the mutex. Concurrent reads of the unmutated Hash under -Dpreview_mt are safe.

Source file published at the site-absolute, decoded url (no base_path), or nil: a page-bundle asset, a [content.files] copy, then a static/ file — the order the resize jobs claim URLs in. config defaults to the running build's.

Returns a width => filename map when every expected destination file already exists on disk with an mtime at least as new as the source (i.e. decoding/resizing would produce bit-identical output). Returns nil when any destination is missing, stale, or empty — caller then processes the image normally. Empty is checked so a killed serve mid-write doesn't leave a zero-byte file that would pass an mtime check and get served as a broken image.

Caller must also verify LQIP cache separately; LQIP can't be reconstructed from disk bytes.

Verify destination directory is within output (dest may not exist yet)

Verify that a source path resolves within the expected base directory. Uses File.realpath to resolve symlinks before the boundary check.

The file behind a site-absolute url that a render just printed image-derived data from (a srcset, an LQIP, a dominant colour): the resize job's source, else the static/ location an image that does not exist yet would appear at. Also registers it with the serve watcher (see render_image_source_changed?). Yields every path the caller records as a --cache render input: the source, then the files that would publish under one of its variant names (authored_variant_paths).