[Help] Prestashop 1.6.1.24 : migration forcée de MySql 5.7 vers MySql 8

[french50]

Bonjour,

Cette semaine, notre hébergeur va migrer notre presta 1.6.1.24 vers un nouveau serveur qui ne disposera plus de MySql 5.7 mais bien d’une version 8.X

J’ai entamé des tests en local ainsi qu’effectué des recherches via ce forum notamment, mais sans trouver un récapitulatif des modifications/vérifications à faire pour s’assurer que tout tourne bien. J’en appelle donc à votre expérience.

Voici ce que j’ai trouvé pour l’instant.

Mode d’authentification de Mysql

J’ai lu que MySql8 passait pour l’authentification à la DB par le plugin caching_sha2_password au lieu du plugin employé précédemment, mysql_native_password

J’ai lu qu’il fallait modifier le user utilisé pour la connexion à la DB de sorte à forcer l’usage de la méthode d’authentification classique :

alter user ‘nomduuser’@localhost’ identified with mysql_native_password by 'motdepassedeouf';

Mais en dehors de ça, est-ce qu’il y a une quelconque modification à faire au sein du presta ?

MySql Engine

Dans un message du forum quelqu’un parle de modifier, dans setting.inc.php :
define('_MYSQL_ENGINE_', 'InnoDB');
par define('_MYSQL_ENGINE_', 'My Sql 8');

Cela me parait assez étrange, d’autant que même changer cette constante par n’importe quelle valeur passe (peut-être parce qu’il y a un fallback par défaut quelque part). Du coup est-ce que ça a le moindre sens ?

Dysfonctionnement dans les déclinaisons

Le plus gros problème de fonctionnement semble lié aux déclinaisons, dont les quantités indiquées diffèrent selon que l’on est en front et en back office. C’est abordé régulièrement, un utilisateur du forum parle d’une modification à faire dans la classe product, mais sans préciser la solution. Est-ce que cela pourrait être ceci : https://github.com/PrestaShop/PrestaShop/issues/13833 ?

My.cnf

Enfin, j’ai cru comprendre que certains problèmes pouvaient être liés à la configuration de MySql, et qu’il fallait peut-être éditer dans le my.cnf la variable sql-mode.

Je pense qu’actuellement j’en ai déjà dans la 5.7 une version modifiée pour accepter les dates au format 0000 car c’est employé dans les anciennes versions de presta, est-ce que la définition suivante pourrait toujours être valide ?

sql-mode="NO_ENGINE_SUBSTITUTION,ERROR_FOR_DIVISION_BY_ZERO,ALLOW_INVALID_DATES"

D’avance merci !

[Eolia]

Vous devriez tester PhenixSuite qui vous permet de rester en version 1.6 mais avec la prise en charge des dernières mises à jour (PHP8.2 si vos modules le supportent, MySQL8, etc...)

https://eoliashop.com/phenixsuite/prestashop-new

[french50]

Le 16/01/2024 à 4:31 PM, Eolia a dit :

Vous devriez tester PhenixSuite qui vous permet de rester en version 1.6 mais avec la prise en charge des dernières mises à jour (PHP8.2 si vos modules le supportent, MySQL8, etc...)

https://eoliashop.com/phenixsuite/prestashop-new

Je vais faire des tests aujourd'hui en ce sens, le travail réalisé est vraiment fantastique. 

C'est H.S. par rapport au sujet de base de cette discussion, mais par contre de + en + de modules vitaux dont nous sommes dépendants abandonnent malheureusement cette branche et je pense ne plus pouvoir retarder longtemps une migration à la 1.7+. 

[Eolia]

Vous avez une liste de ces modules "vitaux" qui vous manquent ?

Si vous décidez de migrer vers les versions 1.8 ou 9 soyez bien conscient que vous allez devenir de plus en plus prisonniers du système.

Depuis que Prestashop a été racheté par une entreprise de logistique italienne il y a 1 an 1/2 le projet a complètement changé et ils font tout pour pousser les utilisateurs à passer à la solution payante (aka Shopify en % du chiffre d'affaire) et en concentrant les modules tout-en-1 (comme ps_checkout) liés à ps_account qui transmettent TOUTES les données de votre shop à Prestashop (clients, ventes, catalogue, etc...).

Il y a encore 150 000 boutiques en version 1.6 et il est hors de question de les laisser tomber par choix stratégique.

[french50]

Ne serait-ce qu'en terme de module de paiement, Ingenico (y compris le module de chez SellXed) & Mollie ne sont plus maintenus (ce dernier ne fonctionnant tout simplement plus). Même tarif visiblement pour les modules de BPost & DPD Benelux, même si là je sors les pincettes de rigueur car c'était peut-être un question d'interlocuteur. 

Dans tous les cas, je trouve ça très regrettable car il me semble que le créneau qu'occupait prestashop - une espère de solution intermédiaire en terme de complexité entre un shopify-like et magento - semble destiné à devenir vacant. 

[Eolia]

Mollie est toujours dispo en version 4.54 (pas très compatible PHP 8 mais pas sûr que la version 1.7 le soit).

Il y a 4 heures, french50 a dit :

Dans tous les cas, je trouve ça très regrettable car il me semble que le créneau qu'occupait prestashop - une espère de solution intermédiaire en terme de complexité entre un shopify-like et magento - semble destiné à devenir vacant. 

D'où l'intérêt de PhenixSuite justement pour ne pas laisser cet espace vacant

[dydy59]

Bonjour, vous avez eu des problème particulier ? Nous c'est pareil notre hébergeur va forcer la migration de nos sites Prestashop 1.7.8.7 de la version MySQL 5.7 vers 8.X à date du 17 Avril. J'ai déjà effectuer des test et pour le moment j'ai l'impression que sur le papier, aucun bug important, voir zéro bug visible, je voulais savoir si vous avez rencontré des soucis, si oui lesquels ?

Edited March 22 by dydy59 (see edit history)

[DevilYann]

Mon client rencontre un problème depuis la migration vers  MySQL 8. Sur la fiche produit, dans l'onglet Quantités, les id des déclinaisons sont mélangés, ce qui fait que lorsque par exemple on met 1 en quantité pour un canapé couleur gris anthracite, c'est le canapé couleur gris clair qui est affecté.
Le problème se situe au niveau du nom des champs des quantités. Exemple qty_5532 alors que ça devrait être qty_5531.

[DevilYann]

Problème résolu !
Il faut ajouter dans la fonction getAttributesResume() de la classe Product.php un tri : ORDER BY pa.`id_product_attribute` ASC

Voici le code :

$combinations = Db::getInstance()->executeS('SELECT pa.*, product_attribute_shop.*
				FROM `'._DB_PREFIX_.'product_attribute` pa
				'.Shop::addSqlAssociation('product_attribute', 'pa').'
				WHERE pa.`id_product` = '.(int)$this->id.'
				GROUP BY pa.`id_product_attribute`
                ORDER BY pa.`id_product_attribute` ASC');

 

[Eolia]

Pour info MySQL8 ignore le tri par primary key alors que c'était implicite dans les versions inférieures.