# CPalius CMF 2.2.15

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

Turkish: [2.2.15-tr.md](2.2.15-tr.md)

2.2.11 through 2.2.14 fixed real problems, but not the one causing the crash reported against this specific sequence: applying an update, then immediately running migrations, in the same request. This release fixes that one directly, and it required admitting the previous four releases were solving adjacent problems instead of this one.

## What was actually wrong

Applying a full-release update writes new files, then — in the same request, immediately after — runs database migrations, using services (the Doctrine migrations factory, and anything it resolves on demand) that were already loaded into memory when the request started, from the container that existed *before* the update touched anything. That old container was assumed safe to keep using for exactly this reason.

The update's own file-installation step was clearing that same container as its last action, before migrations ever ran. Not leaving it for later — clearing it immediately, in this request, because a different step (compiling front-end assets right after) needed fresh files to compile against. The container being cleared isn't the same as it becoming unusable later: PHP had already loaded services from it, and some of those services load *more* of themselves lazily, on first use, by reading a file from that same directory. Migrations were the first thing to ask for one of those after the directory was gone.

2.2.12 through 2.2.14 each made the container get rebuilt faster and more reliably after being cleared — which helps everyone except the one request already depending on the copy that just got cleared out from under it. Rebuilding a replacement doesn't un-clear the original for a process still holding a reference into it.

## What's fixed

Clearing the compiled container during a full-release update now happens **after** migrations run, not before — a straightforward reordering once the actual dependency was traced instead of assumed. The container an update starts with now survives long enough for every step of that same request that still needs it, including the two rarer recovery actions (resuming an interrupted update, rolling one back) that had the identical ordering problem for the same reason.

## Upgrade notes

No schema changes. No manual steps. If your installation is currently stuck mid-update from a previous failed attempt, AACP's Updates screen will offer resume or rollback as usual — both now apply this fix too.