Magento - 2.2.6 Problèmes possibles?

Magento est sorti en version Magento-2.2.6 le 18 septembre 2018.

Cette version comprend:

1. 25 améliorations essentielles à la sécurité du produit, plus de 150 correctifs et améliorations du code de base et plus de 350 demandes d'extraction soumises par la communauté.
2. Bien que cette version inclue ces améliorations de sécurité, aucune attaque confirmée liée à ces problèmes ne s'est produite à ce jour.
3. Cependant, certaines vulnérabilités peuvent potentiellement être exploitées pour accéder aux informations client ou reprendre des sessions administrateur, nous vous recommandons donc de mettre à jour votre logiciel Magento vers la dernière version dès que possible.

Le Magento recommande de mettre à niveau notre logiciel Magento vers la dernière version dès que possible.

Quels sont les problèmes possibles avec cette version de Magento-2.2.6?

Si vous utilisez des attributs personnalisés et utilisez ces attributs pour créer des règles de widget, la plupart des widgets que j'ai utilisés ont causé des erreurs et ont dû être supprimés.

Dans mon cas, il semblait que certains des attributs appelés avaient des erreurs avec des `` back-ticks '' remplaçant les guillemets simples `` avec des back-ticks lors du rendu de la page.

J'ai supprimé les widgets en utilisant ces attributs et la page se charge sans problème.

Je dois également réécrire certaines des règles de panier et de catalogue, encore une fois, en raison du problème de retour en arrière.

1 problème majeur que je rencontre,

" Supprimer pub / media / catalog / product / cache. (La suppression de ce dossier libère de l'espace.) & Exécutez bin / magento catalog: image: redimensionner pour générer un nouveau cache d'image. (Cette étape est nécessaire car nous avons changé le chemin aux images mises en cache et doit supprimer les images précédemment mises en cache.) "

Supprimer le «pub / média / catalogue / produit / cache» n'est pas un problème, mais le «catalogue bin / magento: image: resize» crée simplement de nouvelles images à l'intérieur du dossier que je viens de supprimer. Il a dit qu'il y aurait une nouvelle voie, mais cela ne semble pas être le cas jusqu'à présent, à moins que je manque quelque chose. Mais prévoyez de redimensionner l'image pour prendre LONGTEMPS. 22 minutes à ce jour et moins de 500 images traitées.

J'ai rencontré 2 problèmes concernant la réindexation des prix. Un problème est que l'indexeur de prix configurable (et probablement d'autres produits complexes aussi mais je n'ai pas de projet de production qui utilise beaucoup de bundles et de produits groupés) dépend de son index de produit enfant pour être correctement exécuté. L'indexeur de prix configurable fonctionne en 2 étapes:

• construire des données d'index basées sur le prix du produit configurable qui est nul car magento ne vous permet pas de fixer le prix sur le niveau de prix configurable
• mettre à jour les colonnes min et max dans le catalog_product_index_pricetableau en fonction des données enfants de la même table

Le premier bogue que j'ai trouvé était cette reindexListméthode qui est déclenchée par une réindexation planifiée qui a réindexé la liste donnée par type de produit qui a été triée en fonction des identifiants fournis. Si l'ID le plus bas de la liste était simple, tous les simples ont été réindexés avant les configurables, s'il était configurable, puis configurables avant les simples.

Le deuxième bogue reposait sur le fait que dans la première étape de la table de processus de réindexation des prix configurable, la catalog_product_index_pricemise à jour était basée sur une requête qui créait une wherepartie en tant que where e.entity_id BEETWEEN ? and ?et les valeurs où les identifiants min et max de la liste fournie. Cela a entraîné la mise à jour de la table d'index pour tous les éléments configurables de la plage en fonction de ses données et dans la plupart des cas, toutes les colonnes de prix ont été définies sur 0. Dans la deuxième étape, où l'indexeur doit mettre à jour les prix minimum et maximum en fonction des enfants, la requête a été exécutée avec une wherepartie comme where le.entity_id IN (?), donc uniquement pour les configurables fournis à la reindexListméthode faisant tous les autres à l'état de base.