LessCompiler  

Recompile this asset and record its revision. Files are only written when the compiled output actually differs from what the revision manifest says is on disk (or the file has gone missing) — so routine rebuilds of unchanged assets are complete no-ops with zero writes.

Produce the exact bytes to write to the primary asset file, or null when there is nothing to write (empty sources). This is what the revision is hashed from, so it must be identical to what gets committed — subclasses that transform or add to the output (e.g. JsCompiler's sourcemap handling) override this and queue any sidecar files (like the `.map`) on {$pendingSidecars} rather than writing them, so sidecars are only written when the bundle itself is.

The directory holding the webfonts that get published to `assets/fonts`.

Used to revision the font URLs emitted into the compiled CSS.

Read a cached parse result for less.php. Returns the cached rules, or null to signal a miss so less.php reparses the file.

A corrupt or unreadable cache file (e.g. a partial write from a raced compile) is treated as a miss rather than allowed to fatal on unserialize()'s "Extra data" warning, which Flarum's error handler would otherwise escalate to an uncaught exception.

Persist a parse result for less.php, writing atomically so a concurrent reader never observes a half-written cache file: serialize to a temporary file in the same directory, then rename() it into place (atomic on the same filesystem).

Prune expired cache files at most once per request. less.php's own GC (Less_Cache::CleanCache) only runs from its high-level Less_Cache::Get() API, which Flarum doesn't use — the direct Less_Parser path GC'd inline on every serialize write instead. In callback mode neither fires, so without this the directory would grow unbounded.

We prune here rather than call CleanCache() because that method is deprecated-internal, and hand-rolling the sweep lets us tolerate the scandir/unlink race (a concurrent sweep removing the same aged file) by simply suppressing the "No such file" and moving on. Files are removed by mtime, matching less.php's own policy; a cache hit re-reads and is not touched, so anything past the lifetime is genuinely stale.

Point font URLs at the published `assets/fonts` directory, and stamp each with a revision derived from the font file itself.

The stylesheet is already cache-busted (`forum.css?v=<rev>`), but the font URLs inside it were not. On a FontAwesome major upgrade every browser therefore picked up the new CSS immediately while continuing to serve the *previous* font file from cache — same filename, same URL, long max-age. The new CSS asks for codepoints the old font doesn't contain, so every icon rendered as a placeholder box until that cache entry happened to expire. Revisioning the URL means a changed font is always a new URL, for browser and CDN caches alike. Because the asset revision is a hash of this compiled output, a font change also moves the stylesheet's own revision — so connected clients get the usual "reload for the new version" prompt without any extra wiring.

A short hash of a webfont's contents, or null when it can't be read — fonts are published separately, so a compile must never fail just because the directory isn't there yet.