Describe the bug
After a CLI update to PrestaShop 9.0+, the freshly updated shop's back office redirects to the front office: opening /<admin>/ (e.g. /admin-dev/) returns a 302 to / → /<lang>/ instead of the login page. The shop stays in that state (it does not self-heal), until a Symfony cache rebuild is triggered.
In PrestaShop 9.0 the BO login is a Symfony route (admin_login → /login); when the Symfony prod cache is missing, the admin entry point can't boot and falls back to the front office.
Root cause
During the update, UpdateDatabase warms up the core cache (CoreUpgrader::warmupCoreCache(), gated by shouldWarmupCoreCache() = destination ≥ 9.0.0 && CLI), which builds var/cache/prod. But the later UpdateComplete task calls CacheCleaner::cleanFolders() (which clears var/cache/) after that warm-up, wiping the just-built prod container. The update finishes with an empty var/cache/prod (only a leftover <version><lang>.xml), so the 9.0 Symfony back office cannot start.
How I reproduced it (locally, mirrors the CI Upgrade CLI job)
docker compose PrestaShop 8.1.7-8.1, then autoupgrade CLI local update to 9.0.0.
- Right after the update,
curl -s -o /dev/null -w '%{redirect_url}' http://localhost/admin-dev/ → http://localhost/ (front office), 30/30 times.
var/cache/prod/ contains only 9.0.0en.xml (no container).
php bin/console cache:clear --env=prod → BO immediately works again (/admin-dev/ → /admin-dev/login).
Impact
- Merchants updating to 9.0+ can land on a broken back office until the cache is rebuilt.
- CI: this is what makes the
Upgrade CLI (and Upgrade UI) sanity should login in BO step flaky on 9.x destinations — the post-update sanity test lands on the front office and times out waiting for #email. Whether it passes depends on whether the first web hit manages to rebuild the container, hence the intermittent ~50% failures on the dev nightly and on PRs targeting 7.6.x.
Expected behavior
After the update completes, the shop should boot straight into the back office without any manual cache clear.
Fix
Warm up the core cache again after the final cleanFolders() in UpdateComplete (PR to follow).
Versions
- autoupgrade:
7.6.x / dev
- Destination: PrestaShop
9.0.0 (also affects 9.x in general)
Describe the bug
After a CLI update to PrestaShop 9.0+, the freshly updated shop's back office redirects to the front office: opening
/<admin>/(e.g./admin-dev/) returns a302to/→/<lang>/instead of the login page. The shop stays in that state (it does not self-heal), until a Symfony cache rebuild is triggered.In PrestaShop 9.0 the BO login is a Symfony route (
admin_login→/login); when the Symfonyprodcache is missing, the admin entry point can't boot and falls back to the front office.Root cause
During the update,
UpdateDatabasewarms up the core cache (CoreUpgrader::warmupCoreCache(), gated byshouldWarmupCoreCache()= destination ≥ 9.0.0 && CLI), which buildsvar/cache/prod. But the laterUpdateCompletetask callsCacheCleaner::cleanFolders()(which clearsvar/cache/) after that warm-up, wiping the just-built prod container. The update finishes with an emptyvar/cache/prod(only a leftover<version><lang>.xml), so the 9.0 Symfony back office cannot start.How I reproduced it (locally, mirrors the CI
Upgrade CLIjob)docker composePrestaShop8.1.7-8.1, then autoupgrade CLI local update to9.0.0.curl -s -o /dev/null -w '%{redirect_url}' http://localhost/admin-dev/→http://localhost/(front office), 30/30 times.var/cache/prod/contains only9.0.0en.xml(no container).php bin/console cache:clear --env=prod→ BO immediately works again (/admin-dev/→/admin-dev/login).Impact
Upgrade CLI(and Upgrade UI) sanityshould login in BOstep flaky on 9.x destinations — the post-update sanity test lands on the front office and times out waiting for#email. Whether it passes depends on whether the first web hit manages to rebuild the container, hence the intermittent ~50% failures on thedevnightly and on PRs targeting7.6.x.Expected behavior
After the update completes, the shop should boot straight into the back office without any manual cache clear.
Fix
Warm up the core cache again after the final
cleanFolders()inUpdateComplete(PR to follow).Versions
7.6.x/dev9.0.0(also affects 9.x in general)