PrestaShop Update Problems — Rollback & Recovery [2026]

PrestaShop problems after an update are a classic: the store worked, then after updating the core or a module it stopped accepting orders, the theme "fell apart" or 500 errors appeared. The most common causes are incompatible modules, overrides colliding with core changes and stale cache. The good news: an update can be safely rolled back if a backup and a rollback plan were made before the start. Below is the recovery checklist and the rules that make updates safe. Fixing a failed update: 200–600 PLN net, diagnostics with a report 500–1,500 PLN net.

Key takeaway: After a failed PrestaShop update, act in this order: 1) do not panic and do not "update again right away", 2) check the logs (var/logs/, PHP logs) — they will point to the guilty module, 3) disable the most recently updated module, 4) clear the cache (var/cache, Smarty cache, OPcache), 5) if the core is at fault — restore the pre-update backup (rollback), 6) update again on staging, in batches, with a purchase path test. A safe update = backup + staging + tests + a rollback plan.

• ## Step 1: Establish exactly what stopped working

Before fixing, gather facts

• - what stopped working: the whole store, the panel, the checkout, a single page?
• - when: right after the update or hours later (cache)?
• - what was updated: PrestaShop core, a module, the theme, PHP?
• what exact message do you see (500, white screen, "Oops! An error occurred")?

The exact scope of the failure narrows the suspects. An error only in the checkout after a payment module update is a different problem than a blank store after a core update.

• ## Step 2: Logs — the first lead

The logs will point to the culprit in most cases

• var/logs/prod.log and dev.log — PrestaShop and module errors,
• PHP logs (error_log) — memory exhaustion, parse errors,
• server logs — hosting-level errors.

Look for entries from the time after the update: Call to undefined method (module incompatible with the new version), Cannot redeclare (override conflict), Allowed memory size (the new version needs more memory), SQLSTATE (unrun database migrations). How to read logs: PrestaShop logs.

• ## Step 3: Disable the most recently updated module

• The most common scenario: the core was updated, but the modules were not. An older module calls a method that the new core no longer has.

1. disable the module indicated in the logs (or the most recently updated one),
2. when the panel works — via the panel; when it does not — via the database: UPDATE ps_module SET active = 0 WHERE name = 'name';,
3. check the store after each disable.

If the store recovers after disabling the module, check its changelog for a version compatible with your PrestaShop and update it — or report the issue to its author. Full isolation procedure: module conflicts.

• ## Step 4: Clear the cache — all layers

Stale cache after an update is the second most common cause of "ghost errors"

• - PrestaShop cache: panel → Advanced Parameters → Performance → Clear cache (or delete the contents of var/cache keeping the structure),

• - Smarty cache: panel → Performance → Templates → clear compilation,

• - PHP OPcache: restart PHP-FPM on your hosting (or opcache_reset()),

• CDN cache, if the store sits behind Cloudflare — purge,

• - browser cache: test in incognito so you are not diagnosing your own cache.

After a PrestaShop update all cache layers must be cleared — refreshing the page is not enough.

• ## Step 5: Rollback when the core is at fault

If the logs point to the core, or the error returns with all modules disabled — restore the pre-update backup

1. restore the files from the backup (the whole directory),
2. restore the database from the pre-update dump (crucial — the update changes the schema),
3. clear the cache and OPcache,
4. check the store: home page, product, cart, checkout, panel,
5. only then plan the update again — on staging.

Warning: A rollback without restoring the database leaves the store in an inconsistent state: old code + new database schema. If you have no database backup, do not improvise with manually reverting migrations — that is a straight path to data loss.

• ## Step 6: Plan a safe update

So it does not happen again

• staging — a store copy on a separate hosting/subdomain with indexing disabled,
• backup — files and database, with a restore test before starting,
• changelogs — check that all modules are compatible with the new core version,
• in batches — core first, then modules one by one, then the theme,
• purchase path test — home → product → cart → checkout → payment → email,
• rollback plan — an exact recovery procedure, tested on staging,
• day and time — never on Friday afternoon; update during low traffic, with time available to react.

A printed update checklist is worth having for every update — I run such processes as part of PrestaShop technical help.

What breaks most often — symptom table

When to call a specialist

You can handle a rollback and single-module diagnostics yourself with a backup and the logs. Help is worth it when

• there is no pre-update backup (data recovery),
• the error is in the core or the database,
• the store has been down for over an hour — every minute of sales counts,
• the update was major (1.6 → 8/9) and requires a migration plan.

Planned migrations are covered in PrestaShop implementation.

Frequently asked questions

PrestaShop stopped working after an update — how do I roll it back?

Restore the files and database from the pre-update backup (rollback), clear the cache and OPcache, test the full purchase path. Without a database backup, do not revert changes manually — get help, because inconsistent code and database schema risks data loss.

Can I update PrestaShop without a backup?

Technically yes, but it is a gamble. An update changes the database schema and core files — without a backup there is no way back if something goes wrong. A files and database backup is a condition for starting any update, not an option.

After a module update the payment methods disappeared — what to do?

Disable the payment module and check whether the other methods return; then enable it on staging with debug mode and read the error. Most often the module needs an update to a version compatible with the new core — check the vendor's changelog.

How often should PrestaShop be updated?

• Core: security releases immediately, feature releases on a quarterly cycle. Modules: after checking changelogs, in batches. Every update through staging. A regular update cycle is covered in PrestaShop support.

Sources and tools

• PrestaShop Build — releases and updates
• PrestaShop DevDocs — updating
• PrestaShop — documentation

👉 An update took the store down? We will help with the rollback and a safe retry — contact form or kontakt@informatix.com.pl. See also PrestaShop technical help.

📖 See also: module conflicts, checkout not working and PrestaShop implementation.