Introduce a safe mode of PrestaShop to avoid loading modules

[Quetzacoalt91]

Questions	Answers
Description?	When updating shops from classic v8 to classic v9, we encounter many errors regarding the modules. When we update from PrestaShop v8 to v9, the gap is quite wide regarding the improvement we're brought on PrestaShop. We made a big step forward on the Symfony version, for instance we have PHP code with strict typing... and this leads to major changes in the modules as well. With this version 9, we encounter a lot of Fatal Error from the modules that don't match the updated core functions signature. And the more modules you have on the shop, higher is the risk of encountering it. In the Update process, it seems we now require a moment where we avoid loading modules until we try to update them. This covers from the end of files update, database, to the warm-up of modules update. I a perfect world, I should be able to ask the Core to not load modules. However until the feature in available, we have to find another even though it looks experimental.
Type?	New feature
BC breaks?	Nope
Deprecations?	Nope
Fixed ticket?	Problem installing Prestashop ver 9.0 #1560
Sponsor company	@PrestaShopCorp
How to test?	Stability is improved during updates between 2 classic versions.

[Hlavtox]

I like the idea where you are going, but I think that the things that make the store break are mostly not dependent on module being active or not. :-( It's usually PHP stuff - class definitions, services, tabs and other things like this, that just break if the module is installed.

[kpodemski]

@Hlavtox this change can lead to the module files not being loaded which should do the job, what I do is that sometimes I'm changing the directory name from somemodule to somemodule-disabled, thing is that the moment you bring it back, you will have an error anyway

so it's more like doing an update, and fixing later, I kinda like this idea, but it should probably be for advanced users only

When updating shops from classic v9 to classic v9, we encounter many errors regarding the modules.

You meant classic v8 to classic v9, right?

[Quetzacoalt91]

You meant classic v8 to classic v9, right?

Exactly Krystian, I've changed the description accordingly. Thanks.

---

I've not provided much details about this PR, sorry about that. I've opened it for anyone curious who would like to have a look on the issue we're now facing and trying to solve.

When we update from PrestaShop v8 to v9, the gap is quite wide regarding the improvement we're brought on PrestaShop. We made a big step forward on the Symfony version, for instance we have PHP code with strict typing... and this leads to major changes in the modules as well.
With this version 9, we encounter a lot of Fatal Error from the modules that don't match the updated core functions signature. And the more modules you have on the shop, higher is the risk of encountering it. In the Update process, it seems we now require a moment where we avoid loading modules until we try to update them. This covers from the end of files update, database, to the warm-up of modules update.

I a perfect world, I should be able to ask the Core to not load modules. However until the feature in available, we have to find another even though it looks experimental.

[kpodemski]

@Quetzacoalt91

This has been discussed in other places of the project, I'm pretty sure of that, so maybe I will search for some old discussions where we shared, @Hlavtox also, numerous ways to handle it

I remember we discussed forcing developers to provide a maximum version of the PrestaShop compatible, so instead of:

max_version => PS_VERSION, they'd do something relevant

I also recall some ideas about sandboxing updates, where the updater attempts to load modules. If any fail, they are moved to a temporary directory.

Anyway, as mentioned above, what I do is that I change the module's name :) This does the trick, as long as there are no hardcoded lines like:

require_once _PS_MODULE_DIR_ . 'mymodule/classes/SomeClass.php

But I'm not sure if it's even possible to handle all the scenarios of badly written code I can imagine.

I'm happy that you guys took on this challenge to handle incompatible modules better 👏🏻

[Quetzacoalt91]

Anyway, as mentioned above, what I do is that I change the module's name :) This does the trick, as long as there are no hardcoded lines like

That is what we're doing with this PR, but on the database side. :)

You're suggesting interesting ideas as well. Regarding the ps_version_compliancy property, which is only checked at the module installation, we could check if the module has module updates. If nothing's available, we could disable it.
But this is another topic that would be covered with a whole new step pre-update, where we ask the merchant what to do for each module.

[M0rgan01]

I think we can use DbWrapper class here. For better error handling, with exceptions

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Quetzacoalt91]

I'm removing this pull-request from the expected release of Update Assistant 7.5.

After a few tests, it appears this pull-request improves the stability of updates, BUT...
It basically moves the errors from the incompatible modules AFTER the update. It brings blank pages on FO and BO and may require the debug mode to be enabled.
Then, to fix the issue with incompatible modules, the only solution you have is to manually delete the module from the modules/ folder, preventing you to run the uninstall() method and cleaning everything from the module properly.

This PR must go with something that detects and warns upfront what module are incompatible and must be uninstalled.
#1528 is a first step.

[AureRita]

Hi @Quetzacoalt91

Thank you for your PR, I tested it and it seems to works as you can see :

Capture.video.du.2025-11-27.15-49-59.mp4

Currently, the stability is correctly improved, we only have to uninstall ps_edition_basic on v1.0.21 before updating and we have to uninstal module that show error with debug mode

Tested from 8.2.1 classic to 9.0.1

Because the PR seems to works as expected, It's QA ✔️

Thank you

[jolelievre]

Sorry very late review 😅
Of course not blocking anything, I just had a few questions

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud