CPalius CMF 2.2.12

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

A full-release update could 500 right as it finished, and the automatic follow-up step it depends on to avoid a manual second click could fail the same way — leaving the operator doing by hand exactly what the update was supposed to finish on its own. Both came from the same gap: nothing guaranteed the compiled container was actually rebuilt before the next thing that needed it ran.

What's fixed#

A container left empty after file replacement was compiled inline by whatever request got to it first, instead of being rebuilt in a controlled step. Applying an update clears the compiled container as its last action before redirecting. The very next request — the update's own automatic follow-up (hooks, module upgrades, config import), or simply a visitor — was the one left to compile a fresh container from scratch, live, under whatever time and memory budget that single request happened to have. Symfony writes a compiled container's files incrementally, not atomically, so a slow or interrupted compile there doesn't mean a slow page: it means a container missing some of its files, and every request after it failing with "required a file that does not exist" until something manages to finish the job. This is why an update could leave "pending work" needing a second, manual click even after 2.2.9 made that step auto-submit — the automatic attempt was itself the request gambling on finishing that compile in time.

The container is now rebuilt explicitly, in its own dedicated process with a generous timeout, immediately after the old one is cleared — the same technique this codebase already used for compiling front-end assets after an update, applied to the step that actually needed it. By the time an update's automatic follow-up step (or the first real visitor) runs, the container is already complete.

Upgrade notes#

No schema changes. No manual steps. If an earlier update on your installation is currently stuck showing "bekleyen işler" / pending work, this release should let the next automatic attempt finish cleanly — if it still shows a stale container error after updating, clear cp-core/var/cache/prod/ once by hand as a one-time recovery step.

Known limitations#

This does not add zero-downtime, fully atomic container swapping (building into a temporary directory and renaming it into place in one step); it closes the specific window that was causing repeated failures. A future release may go further.