Notes de mise à jour d’Adobe Commerce 2.4.0

Mise en oeuvre de 2FA pour les comptes d’administrateur, les comptes d’utilisateur magento.com et l’accès SSH cloud

• Sécurisation de votre compte administrateur. L’authentification à deux facteurs (2FA) est désormais requise pour l’administrateur. Les utilisateurs administrateurs doivent d’abord configurer leur compte 2FA avant de se connecter à l’administrateur par le biais de l’interface utilisateur ou d’une API web. 2FA est activé par défaut. Il est vivement déconseillé de désactiver le module 2FA. Cette étape supplémentaire d’authentification rend plus difficile pour les utilisateurs malveillants de se connecter à l’administrateur sans autorisation. Voir Authentification à deux facteurs (2FA).

• Sécurisation de votre compte. L’authentification à deux facteurs (2FA) offre une couche de sécurité supplémentaire facultative afin de mieux protéger votre compte magento.com contre les utilisateurs non autorisés qui souhaitent utiliser votre compte d’une manière que vous ne souhaitez pas. Voir Sécurisation de votre compte.

• Sécurisation de l’accès SSH Cloud. L’Adobe sur l’infrastructure cloud permet l’application de l’authentification multifactorielle (MFA) pour gérer les exigences d’authentification pour l’accès SSH aux environnements cloud. L’authentification multifactorielle pour 2FA n’est pas activée par défaut sur un projet. Adobe recommande vivement d’activer cette fonctionnalité. Contactez l’assistance technique pour obtenir de l’aide. Voir Activation de l’authentification multifactorielle pour l’accès SSH.

Le mode strict du filtre de modèle est désormais activé par défaut. Les composants (y compris les pages et les blocs CMS) qui utilisent le filtre de modèle en mode hérité peuvent être vulnérables à l’exécution de code distant (RCE). L’activation du mode strict par défaut garantit que les attaques RCE ne peuvent pas être délibérément activées.

Le rendu des données pour les fournisseurs de données de l’interface utilisateur est désormais désactivé par défaut. Cela supprime l’opportunité pour les utilisateurs malveillants d’exécuter des JavaScript arbitraires.

Nouvelle classe \Magento\Framework\Escaper. Cette classe est fournie pour les modèles .phtml et les classes PHP responsables de la génération de l’HTML. Cette classe contient des méthodes d’assainissement d’HTML adaptées à plusieurs contextes. La variable locale $escaper est disponible dans les modèles .phtml et doit être utilisée à la place de la variable $block->escape{method} obsolète. Utilisez $escaper plutôt que $block, car l’utilisation de $block->escape{method} a été abandonnée.

Prise en charge du fichier security.txt. Ce fichier est un fichier standard du secteur sur le serveur qui aide les chercheurs en sécurité à signaler les problèmes de sécurité potentiels aux administrateurs du site.

Améliorations de la prise en charge des stratégies de sécurité du contenu (CSP). SecureHtmlRenderer a été ajouté à la structure et est disponible dans les modèles .phtml pour whitelister les balises intégrées style et script. Les scripts et les styles intégrés ne sont pas autorisés avec la configuration CSP par défaut, qui peut être remplacée par des fichiers XML.

Prise en charge de PHP 7.4 introduite et de PHP 7.1 et 7.2 obsolète. 2.4.0 introduit la prise en charge de PHP 7.4.

Prise en charge de PHPUnit 9.x et abandon de PHPUnit 6.5. PHP 7.4 nécessite l’utilisation de la dernière structure de test PHPUnit, qui est PHPUnit 9.x. Les fournisseurs d’extensions Commerce Marketplace doivent confirmer que toutes les nouvelles versions d’extension sont compatibles avec PHP 7.4 et que tous les tests d’unité et d’intégration ont été configurés pour être exécutés avec PHPUnit 9.

Prise en charge d’Elasticsearch 7.6.x. Elasticsearch 7.6.x est désormais le moteur de recherche de catalogue par défaut pour Adobe Commerce et Adobe Commerce. Vous ne pouvez pas installer ni mettre à niveau vers la version 2.4.0 sans installer également Elasticsearch 7.6.x. Le code de la version 2.x de l’Elasticsearch a été supprimé. Les versions 5.x et 6.x des Elasticsearch ont été abandonnées et ne sont plus prises en charge. Voir Conditions préalables pour le moteur de recherche.

Prise en charge de MySQL 8.0. La version 2.4.x prend en charge MySQL 8.x. (La version 2.4.0 a été testée avec MySQL 8.0.20.) Les commerçants sont encouragés à migrer leurs déploiements vers MySQL 8.x afin de tirer parti de ses performances, sécurité et fiabilité améliorées. Bien que MySQL 5.7 soit toujours pris en charge pour Magento 2.4.x, MySQL 5.6 ne l’est plus. Vous ne pouvez pas héberger la version 2.4.x avec une base de données MySQL 5.6. Voir MySQL.

Prise en charge de MariaDB 10.4. La prise en charge de MySQL 8.0 permet aux commerçants de déployer MariaDB 10.4 avec Adobe Commerce. Bien que les commerçants puissent encore utiliser MariaDB 10.2 avec la version 2.4.0, nous vous recommandons de passer à MariaDB 10.4 pour améliorer les performances et la fiabilité. MariaDB 10.0 et 10.1 ne sont plus prises en charge (en raison de la suppression de la prise en charge de MySQL 5.6 dans cette version).

Suppression du moteur de recherche de catalogue MySQL. Le moteur de recherche MySQL a été supprimé de la version 2.4.0 et remplacé en tant que moteur de recherche par défaut par Elasticsearch. Elasticsearch offre des fonctionnalités de recherche supérieures ainsi que des optimisations des performances du catalogue. Tous les commerçants doivent disposer d’un Elasticsearch pour installer et déployer la version 2.4.0. Voir Vérifiez que l’Elasticsearch est installé.

Migration des dépendances sur Zend Framework vers le projet Laminas pour refléter la transition de Zend Framework vers le projet Laminas de la Fondation Linux. Zend Framework est obsolète. Voir la publication DevBlog Migration de Zend Framework vers le projet Laminas .

La décomposition des contrôleurs permet aux développeurs d’extensions de mettre en oeuvre ActionInterface directement sans classes "supertype de couche". Voir la publication Décomposition des contrôleurs DevBlog . Amélioration lancée par Vinai Kopp dans la requête de tirage 16268 et finalisée par Lukasz Bajsarowicz dans la requête de tirage 26778. GitHub-9582

Suppression de l’intégration principale du code de protection de fraude Signifyd. Cette fonctionnalité principale n’est plus prise en charge. Les commerçants doivent migrer vers l’extension Signifyd Fraud & Chargeback Protection disponible sur le Commerce Marketplace.

Le module de Braintree principal a été supprimé de la base de code. Le module Paiements du Braintree fournit désormais le même ensemble de fonctionnalités. Voir Paiements de Braintree.

Le navigateur Internet Explorer 11.x n’est plus pris en charge.

Suppression de l’intégration principale des méthodes de paiement tierces. Avec cette version, l’intégration du mode de paiement Authorize.Net a été supprimée du code principal. Les commerçants doivent migrer vers l’extension officielle disponible sur le Commerce Marketplace. Voir l’article de devblog Abandon des intégrations de paiement .

Prise en charge de la recherche de mots partiels pour Elasticsearch (nouveau moteur de recherche par défaut). Elasticsearch prend désormais en charge l’utilisation de mots partiels dans les termes de recherche pour les noms de produits et les SKU lors de l’utilisation de la recherche rapide. Cette fonctionnalité a été prise en charge par le moteur de recherche MySQL, qui a été abandonné et remplacé par Elasticsearch dans cette version.

Mise à niveau du SDK PayPal JavaScript. Nous avons migré l’intégration du paiement express PayPal vers le dernier SDK JavaScript PayPal, un SDK qui collecte et transmet automatiquement les paramètres de risque nécessaires à PayPal. Le comportement du mode de paiement PayPal Express Checkout reste inchangé. Cependant, la mise à niveau de ce SDK vers la dernière version permet aux commerçants d’accéder aux dernières fonctionnalités et améliorations de sécurité.

Abandon et suppression de l’assistant de configuration web. Vous devez utiliser la ligne de commande pour installer ou mettre à niveau la version 2.4.0. Voir Installation du Magento.

Module externe de mise à jour du compositeur. Le module externe Composer simplifie le processus de mise à niveau en résolvant les modifications qui doivent être apportées au fichier racine du projet composer.json avant la mise à jour vers une nouvelle version. Ce plug-in protège contre le remplacement des personnalisations. Voir Mise à niveau à l’aide du module externe racine du compositeur.

Achat assisté par le vendeur. Cette fonctionnalité permet aux marchands de voir le storefront pour le compte de leurs clients. Les clients choisissent d’autoriser le storefront à accéder à leurs comptes. Cette fonctionnalité développée par la communauté comprend une extension d’origine développée par MAGEFAN. Voir Seller Assisted Shopping. Les fonctionnalités incluent :

• Liste de contrôle d’accès pour contrôler quels administrateurs peuvent se connecter aux comptes clients sur une base de site web
• Compatibilité avec plusieurs sites web et portées de compte client
• Les commandes passées pour le compte des clients sont enregistrées dans le storefront et dans l’administrateur.
• Toutes les sessions sont détruites suite à la déconnexion de l’administrateur et les administrateurs ne peuvent pas accéder aux mots de passe des clients.

Améliorations de la logique d’invalidation de la section de données client. Cette version introduit une nouvelle méthode d’invalidation de toutes les données des sections client, qui permet d’éviter un problème connu avec le stockage local lorsque des invalidations sections.xml personnalisées sont actives. (Auparavant, le contenu privé (stockage local) n’était pas correctement renseigné lorsque vous aviez un etc/frontend/sections.xml personnalisé avec des invalidations d’action.) Voir Contenu privé.

Optimisations multiples pour redéfinir les performances. Les améliorations ont permis de réduire le nombre de requêtes envoyées à Redis qui sont effectuées sur chaque requête. Ces optimisations incluent :

• Diminution de la taille des transferts de données réseau entre Redis et Magento

• Réduction de la consommation des cycles du processeur par Redis en améliorant la capacité de l’adaptateur à déterminer automatiquement ce qui doit être chargé.

• Réduction des conditions de concurrence sur les opérations d’écriture Redis

Voir Utiliser des Redis pour la page et le cache par défaut et Configurer la mise en cache.

Amélioration de la mise en cache des résultats des requêtes SQL dans les tables d’inventaire. Ces améliorations incluent :

• Mise en cache des requêtes SQL vers la table inventory_stock_sales_channel (1 requête au lieu de 16)

• Mise en cache des résultats des requêtes dans la table inventory_stock (1 requête au lieu de 16)

Amélioration de 25 à 30 % des performances du module complémentaire de panier de commande rapide.

Les vendeurs peuvent désormais utiliser le chargement différé pour charger les images.

L’application affiche désormais les comportements suivants lorsque votre connexion à Redis est interrompue. Auparavant, l’application ne rechargeait pas la page active et affichait cette erreur : An error has happened during application run. See exception log for details.

• Les sessions d’administration et de storefront expirent
• Les administrateurs et les utilisateurs de storefront doivent se reconnecter.
• Les données de session sont enregistrées dans var/session/
• Aucune erreur ou exception n’est consignée.

php bin/magento cron:run ne traite plus les éléments de la table du journal des modifications plusieurs fois. Auparavant, lorsque vous aviez plus de 100000 nouvelles versions dans la table du journal des modifications, les actions pouvaient être appelées plusieurs fois pour le même entity id.

La commande php bin/magento setup:cron:run a maintenant été supprimée. Supprimez également les références à ce fichier dans les onglets lors de la mise à niveau.

Le fichier update/cron.php a été supprimé dans la version 2.4.0. S’il existe dans votre installation, il peut être supprimé en toute sécurité. Supprimez également les références à ce fichier dans les onglets lors de la mise à niveau.

Correction d’un problème dans GraphQL en raison duquel l’application ne renvoyait pas toutes les informations requises lors de l’utilisation de fragments sur la requête de produits. Correctif soumis par Riccardo Tempesta dans la demande d’extraction 26218. GitHub-26217

La mutation GraphQL setShippingMethodsOnCart ne récupère plus les mauvaises données dans l’attribut available_shipping_methods. Correctif soumis par Vadim Malesh dans la demande d'extraction 27004. GitHub-26742

L’application n’affiche plus de page vierge au lieu d’afficher tous les opérateurs de livraison dans la liste déroulante ou la zone à sélection multiple. Auparavant, une erreur se produisait dans la fonction toOptionArray de vendor/magento/module-shipping/Model/Config/Source/Allmethods.php. Correctif soumis par Marc Rodriguez dans la demande d'extraction 25315. GitHub-13136

L’application n’applique plus de remise à montant fixe plusieurs fois lorsqu’un client crée une commande qui sera envoyée à plusieurs adresses. Correctif soumis par Mahesh Singh dans la demande d'extraction 26419. GitHub-25834

Chaque groupe d’actions d’un test a été déplacé dans un fichier distinct afin de suivre les bonnes pratiques MFTF et les noms de fichiers incohérents ont été modifiés. Les tests pour les modules suivants ont été affectés :

• permission-catalogue-module
• module-shared-catalog
• module-catalog-event
• module-banner
• module-admin-gws
• module-advanced-checkout
• livraison-module
• module-ui
• livraison-module
• module-checkout-address-search
• module-sales
• module-catalog
• module-catalogue-règle-staging
• module-visuel-merchandiser
• module-customer

Correctif soumis par Lukasz Bajsarowicz dans les demandes d'extraction 25800, 26323, 26321, 26320, 26319, 26322, 25828, 26329 (et demandes d’extraction 104, 105, 106, 107, 108, 109 , 111, 119, 120, 121 dans le référentiel privé (partenaires-magento2ee). GitHub-22853

Problème : les méthodes de paiement sont manquantes dans le workflow de passage en caisse lorsqu’un client clique sur Revenir à la caisse standard lors de l’extraction avec paiement Amazon. Solution : actualisez la page de passage en caisse pour afficher les méthodes manquantes.

Problème : l’application affiche deux méthodes de paiement Amazon identiques dans la liste déroulante Mode de paiement disponible lors de la création d’une règle de prix du panier.

Problème : l’application affiche une erreur lorsqu’un administrateur tente d’accéder à la page Rapport de règlement du Braintree (Admin > Rapports ). Actuellement, l’application affiche ce message : An error has happened during application run. See exception log for details. Voir l’article Échec du chargement du rapport de règlement du Braintree de la base de connaissances. Le correctif BUNDLE-2683_AgreementReport.patch pour ce problème est désormais disponible à partir des versions.

Problème : les marchands ne peuvent pas créer de factures partielles pour les commandes dans les déploiements où Venmo est activé et le paramètre Activer Vault pour les paiements par carte est désactivé. Actuellement, l’application affiche cette erreur : The "vault_capture" command doesn't exist. Verify the command and try again.

Problème : l’application affiche deux méthodes PayPal identiques dans la liste déroulante Mode de paiement disponible lors de la création d’une règle de prix du panier.

Problème : l’application peut être une erreur lors de l’ouverture de Sales > Braintree Virtual Terminal. Bien que le formulaire contienne des éléments d’IU corrompus, il accepte toujours les paiements. Solution : enregistrez les informations d’identification du Braintree correctes, ce qui corrige les champs d’entrée réduits. Voir l’article La page Braintree Virtual Terminal est corrompue de la base de connaissances. Le correctif BUNDLE-2670_VirtualTerminal.patch pour ce problème est désormais disponible à partir des versions.

Problème : l’application affiche un message d’erreur dans les pays suivants lorsqu’un client sélectionne un mode de paiement local lors du passage en caisse : Belgique, Pays-Bas, Italie, Espagne et Pologne. Solution : ignorez le message d’erreur et continuez le paiement.

Si un membre de la communauté a fourni un correctif pour cette version, nous identifions le correctif dans la section Problème résolu de ces notes avec l’expression "Correctif fourni par le membre de la communauté".

L’équipe d’ingénierie de communauté contributeurs Magento conserve une liste des principaux contributeurs et partenaires par mois, trimestre et année. Sur cette page Contributeurs, vous pouvez suivre les liens vers leurs relations publiques fusionnées sur GitHub.