AutoUpgrade module remove modules without my consent - tested from 9.0.3 to 9.1.0

[Maofree]

Prerequisites

• I understand and accept the project's code of conduct.
• I have already searched in existing issues and found no previous report of this bug.

Describe the bug and add attachments

Hi @Quetzacoalt91
I'm testing how to upgrade other sites to 9, as I've almost finished redoing all my modules. Now I see that the 1-Click module is uninstalling modules from sites because it deems them incompatible with PrestaShop 9.1. Even if the basic versions don't have this, I can fix them myself and get them to work. However, I'd like to be able to decide certain actions; an option needs to be added to allow users to choose whether or not to uninstall incompatible modules, as perhaps existed in the past. I tried upgrading that site again from 9.0.3 to 9.1.0, and it removed two without warning.

removed the menu and the cookiebanner, but they are basic versions that I modified myself and will stop using them once I have made my own versions. However, I would like to be the one to have control over what happens

Steps to reproduce

Update from 9.0.3 to 9.1.0 with outdated modules purchased on prestashop addons in the past but fixed

Expected behavior

No response

Actual Result

I would like a choice to be added to decide this type of behavior and to show the list of no longer compatible modules, I would like it to be my choice

PrestaShop versions where the bug happens

9.1.0

Module version where the bug happens

7.6.1

PHP version(s) where the bug happened

8.4

Your company or customer's name goes here (if applicable).

No response

[Maofree]

I just upgraded a site from version 8.2.0 to 8.2.5 with the 1-click upgrade 7.6.1 and had no problems. Then I was able to disable the option that would have disabled the modules; none of the modules were removed.
Why can't a button like this be used for PrestaShop 9 to enable or disable the removal of incompatible modules?

[SerenaButler]

I had the same problem with 3 Shops upgrading from 8.2.3 to 8.2.5 uninstalling modules and removing modules settings from the database. I now will upgrade manually, wish there where upgrade packs.

[Maofree]

Hi @Quetzacoalt91
I'll list two errors I encountered while updating a very large site to help you improve this module.

The update was from 8.2.0 to 8.2.5 with version 7.6.1.

1. On the first attempt, it gave me an error 500 about the "cache/prod" folder being removed. This has happened to me in the past on other sites, too, and I thought it was fixed. It can be resolved by setting the permissions to 777 recursively and deleting that folder before proceeding with the update.
2. Subsequently, it gave me an error about the ps_distributionapiclient module, saying it wasn't compatible. I see on other sites that some have version 1.1.1 and others 1.2.1.

However, this time I went ahead without restoring the backup and trying again, as I had already reached the final stage.

after I removed ps_distributionapiclient from the site

no modules have been removed from the site, at least it doesn't seem to me

I do the update by setting everything to NO in the photo I showed above

[Quetzacoalt91]

Many topics are being discussed here.

• The issue about the cache folder is already discussed there: Issue with Upgrade from 9.0.2 to 9.0.3 - Failed to remove directory: Directory not empty #1682. No definitive solution at this time.
• The option to disable modules is removed when updating to PrestaShop 9 and above, because a disabled module on these versions is still called from Symfony. Any incompatible module will still crash the store after an update. We can't keep them as-is and we can't disable them either, so we must go a step forward by removing them.
• The module displays the module that WILL BE uninstalled during the process:

• You can have a look at this list, and if you're sure they will be compatible, you can temporarily rename their module folder, and move them from modules/ for the time of the update. If they are absent, they won't be checked with the marketplace data and in consequence will be left untouched.
• In a later time, we could expect a more detailed page "Requirement check" in which we customize the action applied on each module. But this is only an idea at the moment.

[Maofree]

Hi
I saw that I can comment out a line called $module->uninstall();
The important thing is that I can always manage all my modules, which I keep up-to-date and compatible with the various PrestaShop versions, now converted with Symfony 6.4.

[nico-leb]

Hi,

Joining the conversion about this issue. I'm trying to apply a "simple patch" from 8.2.3 to 8.2.5 and some modules are disabled although should not (for example Chronopost is only 1 version behind and listed as incompatible, the only update regard PS9 compatibility, not 8.2.5. I've also manually update PayPal and it's still listed incompatible, so this is strange).

How the compatibility is checked?

More importantly regarding UX, a simple warning saying 'some modules require your attention' when we're talking about a complete uninstallation feels far too understated.

In the screenshot below, we're talking about the only two payment methods and the main carrier — essentially rendering the shop unusable. I believe a red alert would be much more appropriate here; otherwise, merchants are in for some nasty surprises. Not to mention that uninstalling means redoing the entire configuration from scratch, which can represent a significant amount of work.

[Quetzacoalt91]

An update has been applied on the Marketplace API route that should allow the proper data to be returned. For instance, the chronopost and paypal should not returned as incompatible anymore. If this still the case for you, wait a bit little longer as some cache may remain.

More importantly regarding UX, a simple warning saying 'some modules require your attention' when we're talking about a complete uninstallation feels far too understated.

The wording can definitely be improved. However it is and will remain a warning because this check does not block the update, a red flag would disable the button "continue".
We don't want users to reach dead ends. So yeah, we show a warning and the details in a modal. The user has the choice to proceed anyway or wait for a potential update of the situation, and if anyone discovers other modules have been uninstalled without knowning, they can restore the backup they've made. Anyway, keeping a module that is not compatible, won't be updated and will break the store after the process does not make sense, something had to be done for them.

[SerenaButler]

Uninstalling is worst UX I know about, also settings are getting lost which might not documented anywhere.

Deactivation is the only reasonable way to go as the user later can decide IF he wanna activate again maybe he can "fix" the module on his own. I btw did not even get the warning just got a unusable shop later as modules and settings where deleted (which I am 100% certain would have no problem running with 8.2.5 also) .

IS there a documented way of manually updating a shop? Just updating change files and change database settings if needed.

[nicohery]

We’re facing the same issue across multiple shops with several modules: dpdfrance, payline, systempay, storecommander.

Could you clarify what criteria the API uses to deprecate modules so aggressively?

Many marketplace modules are still not compatible, even months after the release of PrestaShop 9. This makes “frictionless upgrades” unrealistic.

In practice, we patch modules to make them compatible, but these fixes are lost on each update — which is even more frustrating when those updates are performed automatically and without control by autoupgrade.

It would be helpful to allow isolating or excluding incompatible modules during the upgrade process, in order to preserve their configuration.

[Quetzacoalt91]

As I previously said, deactivation is not enough anymore on PrestaShop 9 because of all the services and controllers loaded by Symfony on each cache initialization. We encountered a lot of issues regarding method signature mismatch, non existing services since PrestaShop 9 is out. We had to go a step forward to keep users safe from issues, and uninstalling was the option that could be applied for all kind of environments.

So yes, modules are uninstalled and they are shown before starting the update. Either with the "Modules require your attention" or either with the command update:check-modules. If a module appears in this list, it means it is not compatible (yet?). You have the choice to continue or wait for them to be updated, the information displayed BEFORE allows you to take this decision.
@SerenaButler Please provide screenshots and videos, module names, and logs if you encounter an update that uninstalled modules without telling you first.

As a workaround: If you know what you're doing, you can always temporarily remove the concerned modules from your modules/ folder and move them back inside once the update is done.

---

Could you clarify what criteria the API uses to deprecate modules so aggressively?

• A module that exists on the marketplace and that DOES NOT have a version for the specific version of PrestaShop will be declared as incompatible.
• A module that does not exist on the marketplace will be declared as uncertain. Same if the marketplace is temporarily unable to answer.

[nicohery]

Thanks for the clarification on why modules are uninstalled rather than deactivated. The proposed workaround of temporarily moving the module out of the /modules/ folder during an upgrade is helpful, and we are already using it.

As developers, we can apply workarounds, but merchants who installed modules via one-click cannot, and uninstalling them during an upgrade causes settings to be lost. This is particularly frustrating for non-technical shop owners.

[Maofree]

Hi @nicohery
before to upgrade a website go here
autoupgrade/classes/Task/Update/UninstallModules.php
and comment the line:
$module->uninstall();

or set this code

`public function run(): int
{
$this->stepDone = true;
$this->status = 'ok';
$this->next = TaskName::TASK_UPDATE_FILES;
$this->logger->info($this->translator->trans('Skipping module compatibility and uninstallation step.'));

return ExitCode::SUCCESS;`

then complete the steps to upgrade the website

bye