# CPalius CMF 2.2.18

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

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

2.2.11 through 2.2.16 chased a crash caused by the compiled container being cleared and rebuilt unsafely, all inside `CoreUpdater`/`CacheRebuildManager`'s update pipeline. This release fixes the same class of bug in a place none of those releases ever touched: deleting or deactivating a module from AACP's own module-management screen.

## What was actually wrong

`ModuleActivator::clearCache()` never used `CacheRebuildManager`. It hand-rolled its own synchronous `bin/console cache:clear --no-warmup` subprocess and deliberately left the container unbuilt afterward, on the reasoning that "the next real request warms it lazily, off the critical path." That next request was never a random visitor — activating, deactivating, and deleting a module all redirect straight back into AACP, so it was always this same admin's own next click that was guaranteed to pay for an inline container compile squeezed into one HTTP request's time and memory budget, the exact failure mode `CacheRebuildManager` exists to prevent.

Deleting a module made it worse in its own way: the module's files were removed from disk immediately, synchronously, before any cache clearing happened at all. The container still being served at that moment — compiled while the module's files still existed — has that module's template directory baked into its Twig loader as a literal path string. Twig validates that a path exists every time its loader is built, not only at compile time, so every single request in the gap between "files gone" and "container rebuilt" threw `Twig\Error\LoaderError`, not just an unlucky one that happened to land mid-race.

## What's fixed

`ModuleActivator::clearCache()` now calls `CacheRebuildManager::clearSymfonyCache()`, the same deferred, background-rebuilding path every other cache-clearing action in the app already uses. Module deletion no longer removes a module's files until after that rebuild has actually finished — the removal is scheduled as a second deferred step, so the container being served never has a template path in it that doesn't exist on disk anymore.

## Upgrade notes

No schema changes. No manual steps.