Nous rencontrons un blocage reproductible à 86 % pendant une installation neuve de PhenixSuite via l’auto-installeur officiel.

Environnement :

• Debian 12 ;
• Apache avec Fast-CGI/SuEXEC ;
• PHP 8.3.36 ;
• MariaDB 10.11.14 ;
• base vide et installation neuve.
  Toutes les étapes aboutissent correctement jusqu’aux modules :
• generateSettingsFile : HTTP 200 ;
• installDatabase : HTTP 200 ;
• installDefaultData : HTTP 200 ;
• populateDatabase : HTTP 200 ;
• configureShop : HTTP 200 ;
• installModules : HTTP 200 ;
• installTheme : HTTP 302 vers /install/index.php, puis erreur générique dans l’assistant.
  Le problème est identique en HTTP et HTTPS. Il ne semble donc pas lié au certificat ou à la configuration SSL.

Aucune requête installModulesAddons n’est exécutée entre installModules et installTheme. Or le contrôleur hérité de PrestaShop 1.6 n’autorise installTheme que si le marqueur de session suivant existe :

process_validated['installModulesAddons']

En son absence, la requête tombe dans le fallback Tools::redirect('index.php'), ce qui correspond exactement au 302 observé. L’interface affichée ne comporte d’ailleurs aucune étape « Installation des modules Addons ».

Pouvez-vous confirmer si l’étape Addons a été retirée de la séquence sans adaptation de cette précondition ? Le correctif attendu semble être soit :

• rétablir l’appel installModulesAddons ;
• soit autoriser installTheme après la validation de installModules.
  Nous souhaitons appliquer votre correctif officiel plutôt qu’une modification locale non confirmée.

Autre point de sécurité important : le contrôle de connexion à la base transmet actuellement le mot de passe SQL dans la query string d’une requête GET. Il est alors enregistré en clair dans le journal d’accès Apache. Le secret a été renouvelé, mais il serait préférable d’utiliser une requête POST et de ne jamais placer ce mot de passe dans l’URL.

Je peux fournir les lignes de journal anonymisées et la capture de l’erreur si nécessaire.

Cordialement.