CPalius CMF 2.2.14

Released: 2026-09-25 · Channel: stable · Critical: yes

2.2.12 and 2.2.13 fixed the container-warmup gap in two specific places — an update's automatic follow-up step, and AACP's manual cache-clear button — and the same crash kept coming back from somewhere else, because it was never really two places. It was eight.

What's fixed#

Every place in this codebase that clears the compiled container now rebuilds it, guaranteed, because the guarantee lives in the one shared method they all already go through — not bolted onto each caller separately. clearSymfonyCache() is called from eight places: an update's file-install step, its automatic follow-up step, AACP's manual cache-clear button, theme activation, theme upload, the interrupted-update recovery handler, and more. 2.2.12 and 2.2.13 each fixed one of these by adding an explicit rebuild call after that specific caller's clear — which is exactly why the same failure kept resurfacing somewhere new: fixing call site N does nothing for call site N+1.

The rebuild now happens inside purgeCacheDirectoryNow() itself — the one low-level method every clear, deferred or immediate, already funnels through before this fix and after it. Emptying the compiled container and rebuilding it are no longer two steps a caller can perform one of; they are one operation. This closes the entire class of failure at its actual root instead of at each place it was observed, including places nobody had noticed failing yet.

As a side effect, this is also simpler: the separate "warm the container" step added in 2.2.12 and 2.2.13 has been removed, because it's no longer needed anywhere as a distinct action.

If you are still seeing a stale-container error after this update#

That would mean the rebuild subprocess itself is failing on your host, not that it isn't running — and the answer is no longer to look in application logs. Open AACP → Updates: a failed rebuild is now recorded there with the actual command output, which previously only appeared in the application log as an unrelated-looking crash somewhere downstream. Please report that output; it's the fastest way for a hosting-specific cause (for example, a shared host that restricts spawning PHP subprocesses) to actually get diagnosed instead of guessed at again.

Upgrade notes#

No schema changes. No manual steps.