In what order to update PrestaShop, PHP, theme and modules without breaking your store

A PrestaShop store has four parts that age at different rates: the core, the server's PHP version, the theme and the modules. Each has its own versions and each requires something from the others. If you update them in any old order, sooner or later you hit a combination that does not work: a module that will not start on the new PHP, a theme that calls a function the core no longer has, or a core that will not install because PHP is too old.

The good news is that the right order can almost always be worked out from a single rule. Here it is, followed by the full procedure.

The rule: never pass through an unsupported combination

Each PrestaShop version supports a range of PHP versions. Each module and each theme states (or should state) which PrestaShop and PHP versions it works with. Updating properly means taking steps so that, after every step, all the parts are still within what they support.

That has a practical consequence: you can almost never jump straight to the end. If your store runs an old version on an old PHP, and the target version requires a newer PHP that the current version does not support, you need an intermediate step. Sometimes that is an intermediate core version; sometimes it is an intermediate PHP version that both accept.

Before touching anything: take an inventory

Draw up a table with everything the store has. Without it, the order is guesswork.

• Exact core version and the PHP version the website uses (which may differ from the one on the server's command line).
• Theme: whether it is the default one, a purchased one or a custom one, whether it has a child theme and who maintains it.
• Installed modules, with version, author and where they were downloaded from. Mark the ones you no longer use: they do not need updating, they need removing.
• Overrides in the override/ folder. They are the first to break when the core changes, because they replace entire classes or methods whose signatures may have changed.
• External integrations: ERP, payment gateways, marketplaces, carriers. Each one is a module or script that also depends on versions.

For each module, note the latest version compatible with your current core and with the target one. Those with no version for the target are the real work of the project: you need to find a replacement, ask the author for one or adapt them.

The order that works in most cases

1. Full backup of files and database, and check that it can be restored.
2. Remove what you do not need. Uninstalled modules still on disk, installed modules nobody uses, orphaned overrides. Every part you remove is one less part to update and test.
3. Update the modules within your current version to the latest release that supports it. Often that same release already works on the target core too, so the big jump is made with up-to-date modules.
4. Update the theme to the latest version compatible with your current core, if the vendor offers one. If it is a custom theme, first review the templates that change most between versions: checkout, cart and product page.
5. Update the core, first to the latest patch release of your branch and then, if needed, to the next branch.
6. Change the PHP version to the newest one supported by the new core and accepted by all your modules.
7. Review modules and theme again: some have a specific version for the new branch that can only be installed once the core has been updated.

Why on a copy and not in production

All of the above is first rehearsed on a copy of the store, with the same files, the same database and, ideally, the same PHP and server configuration. On the copy you can make mistakes, roll back and try again. In production, every failed attempt is seen by your customers.

During the rehearsal, record each step in enough detail to repeat it: which module was updated, in what order, which setting had to be changed by hand, which theme file was fixed. On the day of the change nothing is improvised: you follow the list.

What to test after each step

• Home page, a category with filters, a product page with combinations and the search.
• Customer registration, login and password recovery.
• A complete order with each payment method, in each gateway's test mode, until you see the order in the correct status.
• The emails sent to the customer (without them reaching anyone real: on the copy, email must be captured).
• Back office: order list, an order's detail page, PDF invoice, editing a product.
• The PHP error log and the PrestaShop log: what does not break the page also counts.

What usually breaks

• Overrides that redefine core methods that have changed. The symptom is a fatal error right after updating, sometimes only on one specific page.
• Payment modules in old versions that use withdrawn hooks or classes. They are the most delicate, because the failure may be in the return from the gateway: the customer pays and the order is not created.
• Theme templates that expect variables the core no longer sends or that are now named differently.
• Removed PHP functions or behaviours that go from warning to error when you upgrade. A module that worked with silenced warnings may stop working altogether.
• Caches that keep compiled classes from the previous version. Clearing them is part of the procedure, not a last-minute trick.

The change window

Once the rehearsal is done, choose when to apply it in production:

• A low-traffic period that you can see in your own statistics, not the one everyone assumes.
• Well away from campaigns and heavy shipping days. Do not update the day before the sales or on a Friday afternoon if nobody will be around to check on Monday.
• With the people available: whoever makes the change, whoever tests the payments and whoever can call the hosting provider if needed.
• With a written rollback plan: which backup is restored, how long it takes, and which symptom triggers the decision to roll back. If the store has received orders between the backup and the rollback, you need to know how to recover them.

Put the store in maintenance mode during the change, leaving your IP with access for testing, and do not reopen it until you have completed the same test list as in the rehearsal.

After the change

The first few days are for monitoring. Check the error log, compare orders with the gateway's payments and ask the customer service team whether odd queries are coming in. Many update failures do not show up in the first hour, but when someone uses an uncommon feature for the first time: a particular coupon, a carrier that only appears for certain provinces or a corrective invoice.

And record the final state in the inventory. The next update starts there, and it will be much shorter if you do not let years go by between one and the next.

How to solve it in PrestaShop

At Rekire we do this work every day, from a patch update within the same branch to a migration between major versions. With a support hours package (20 or 50 hours, depending on the size of the store) we prepare the inventory of core, PHP, theme and modules, set up the test copy, rehearse the update order with its test list and apply the change in production in the window you choose. Hours are used according to the actual work, so you can start with the inventory and decide later how far to go.