Étiquette : model

[Magento 2] Récupérer les Simple Products associés à un Configurable Product

Création d’un Helper pas-à-pas

Nous allons créer un fichier app/code/Pdv/Catalog/Helper/Data.php.

Si le fichier en question existe déjà, vous pouvez sauter cette étape. Si le Module <Vendor>_Catalog n’existe pas, il faudra le créer au préalable. Le code pour encapsuler notre Helper est le suivant:

Du Namespace du Model dont je veux injecter la propriété de la classe:

Du Namespace du Model (fichier: vendor/magento/module-configurable-product/Model/ResourceModel/Product/Type/Configurable.php namespace: namespace Magento\ConfigurableProduct\Model\ResourceModel\Product\Type;) dont je veux injecter la propriété de la classe.

La fonction getParentIdsByChild() qui nous intéresse dans le Model que nous allons étendre:

Demande à Magento une instance de mon configurable ressource model…

…et mappe le paramètre du constructeur avec la propriété de la classe.

Donne accès à une nouvelle méthode getConfigurableParentIdsByChildId() dans le template PHTML:

Notre Helper app/code/Pdv/Catalog/Helper/Data.php finalisé:

Exploiter notre nouveau Helper dans un template PHTML

Déclarer notre Helper dans notre template PHTML

Créer (ou ajouter dans) un bloc de code PHP assez haut dans votre fichier PHTML et collez-y ceci:

Le chemin Pdv\Catalog\Helper\Data correspond ici au namespace déclaré dans le fichier Helper app/code/Pdv/Catalog/Helper/Data.php + au nom du ficher sans son extension *.php.

A l’endroit dans votre template PHTML où vous souhaitez récupérer l’ID du produit parent (le produit configurable duquel découlent tous les produits simples/toutes les variations), créez une variable $parentProductId

L’utilisation d'implode est obligatoire ici, même si nous allons récupérer une string plutôt qu’un array. C’est une bizarrerie de Magento 2.

Afficher la valeur de $parentProductId dans votre code HTML


Article en cours de rédaction… Je ne suis pas encore parvenu à faire quelque chose de propre à défaut de faire quelque chose qui fonctionne.

Sources:

[Magento 2] Créer un Helper pour récupérer sous forme d’objet dans un template PHTML des informations (ID, nom…) sur la catégorie produit en cours

Testé fonctionnel Magento 2.3!

ATTENTION: bien que cette méthode soit fonctionnelle, ce billet consigne mes notes sur la façon de créer un Helper pour récupérer sous forme d’objet dans un template PHTML des informations (ID, nom…) sur catégorie produit en cours. Les fichiers ne sont pas forcément placés aux bons endroits par rapport aux bonnes pratiques Magento 2.

Créer un module

Sodifrance_GetCurrentCategory

app/code/Sodifrance/GetCurrentCategory/etc/di.xml

app/code/Sodifrance/GetCurrentCategory/Model/Layer/Resolver.php

Hérité de vendor/magento/module-catalog/Model/Layer/Resolver.php.

Créer un module

Pdv_Catalog

app/code/Pdv/Catalog/Helper/Data.php

Hérité de vendor/magento/module-catalog/Helper/Data.php.

app/design/frontend/Sodifrance/pdv/Magento_Catalog/templates/product/list_abonnements.phtml

Hérité de vendor/magento/module-catalog/view/frontend/templates/product/list.phtml.

Dans le bloc de code suivant:

…mettre à la suite:

Pour récupérer le nom ou l’ID de la catégorie en cours

La majeure partie des informations récupérables est définie ici: vendor/magento/module-catalog/Model/Category.php. Mais précisément pour le nom et l’ID de la catégorie en cours:

Vous pouvez également utiliser les fonctionnalités d’auto-complétion de votre IDE pour avoir accès à toute la liste des informations contenues dans votre objet PHP $currentCategory en commençant à taper <?php echo $currentCategory->get.

[Magento 2] Surcharger un Block ou un Model natif

Testé fonctionnel Magento 2.3

Sources: www.magestore.com – Overriding Block, Model In Magento 2 – Magento 2.3, Surcharger une classe native magento2 (Model, Block, Helper, Action…).

(si ce n’est pas fait) Créer un nouveau Module

En ligne de commande:

…puis:

Surcharger un Block natif dans Magento 2

Convention: dans l’exemple ci-dessous, nous surchargeons le Block Magento\Catalog\Block\Product\ListProduct.php.

Créer le fichier di.xml dans app/code/[Name_Space]/[Your_Module]/etc:

Dans le fichier ci-dessus:

  • l’attribut for de la balise preference déclare le namespace + \ + le nom de la classe du Block initial avec, en dernier, le libellé du fichier sans l’extension *.php. Dans notre exemple, le chemin vers le fichier natif est vendor/magento/module-catalog/Block/Product/ListProduct.php.
  • l’attribut type de la balise preference déclare le chemin, à partir de la racine de votre projet et sans les deux premiers dossiers app/code/, vers le Block qui surcharge avec, en dernier, le libellé du fichier sans l’extension *.php

Créer le fichier Block ListProduct.php dans app/code/[Name_Space]/[Your_Module]/Block/Rewrite/Product:

Dans le fichier ci-dessus:

  • le namespace déclare le chemin vers le Block qui surcharge, cette fois-ci sans le nom du fichier. Ici, on peut reprendre une partie de la valeur déclarée pour l’attribut type de la balise preference du fichier di.xml (sans le nom du fichier à la fin, donc…)
  • le libellé de la class déclarée reprend celui du fichier qui surcharge (le libellé du fichier qu’on est justement en-train de créer ou d’éditer) sans l’extension *.php
  • le chemin déclaré après extends est celui vers le Block initial avec, en dernier, le libellé du fichier sans l’extension *.php. Ici, on peut reprendre l’intégralité de la valeur déclarée pour l’attribut for de la balise preference du fichier di.xml, mais ATTENTION: il faut impérativement rajouter un anti-slash \ devant ce dernier!

Commandes Magerun à exécuter impérativement:

A la création de votre module (la première fois):

Puis à chaque modification dans le fichier di.xml:

Surcharger un Model natif dans Magento 2

Convention: dans l’exemple ci-dessous, nous surchargeons le Model Magento\Catalog\Model\Product.php.

Créer le fichier di.xml dans app/code/[Name_Space]/[Your_Module]/etc:

Dans le fichier ci-dessus:

  • l’attribut for de la balise preference déclare le namespace + \ + le nom de la classe du Model initial avec, en dernier, le libellé du fichier sans l’extension *.php. Dans notre exemple, le chemin vers le fichier natif est vendor/magento/module-catalog/Model/Product.php.
  • l’attribut type de la balise preference déclare le chemin, à partir de la racine de votre projet et sans les deux premiers dossiers app/code/, vers le Model qui surcharge avec, en dernier, le libellé du fichier sans l’extension *.php

Créer le fichier Model Product.php dans app/code/[Name_Space]/[Your_Module]/Model/Rewrite/Catalog:

Dans le fichier ci-dessus:

  • le namespace déclare le chemin vers le Model qui surcharge, cette fois-ci sans le nom du fichier. Ici, on peut reprendre une partie de la valeur déclarée pour l’attribut type de la balise preference du fichier di.xml (sans le nom du fichier à la fin, donc…)
  • le libellé de la class déclarée reprend celui du fichier qui surcharge (le libellé du fichier qu’on est justement en-train de créer ou d’éditer) sans l’extension *.php
  • le chemin déclaré après extends est celui vers le Model initial avec, en dernier, le libellé du fichier sans l’extension *.php. Ici, on peut reprendre l’intégralité de la valeur déclarée pour l’attribut for de la balise preference du fichier di.xml, mais ATTENTION: il faut impérativement rajouter un anti-slash \ devant ce dernier!

Commandes Magerun à exécuter impérativement:

A la création de votre module (la première fois):

Puis à chaque modification dans le fichier di.xml:

[Magento 2] Surcharge d’une classe PHP située dans app/code/Vendor/Module/Model/Config/Source via un namespace spécifique

La classe Width que nous souhaitons surcharger dans notre exemple définie dans le fichier app/code/MGS/ThemeSettings/Model/Config/Source/Width.php du thème payant Supro. Mais l’exemple est tout-à-fait adaptable à des classes du core code de Magento 2 ou d’autres thèmes open-source.

1. Création d’un nouveau module qui contiendra notre surcharge de classe:

2. Modification du fichier app/code/Sodifrance/Pdv/etc/module.xml comme ci-dessous.

Note: le tag sequence déclare que notre nouveau module dépend du module Supro_ThemeSettings.

3. Petit upgrade de setup en ligne de commande:

4. Modification du fichier app/code/Sodifrance/Pdv/etc/di.xml comme ci-dessous.

Ici, nous procédons à une injection de dépendances: on veut utiliser, à la place de la classe MGS\ThemeSettings\Model\Config\Source\Width, une nouvelle classe Sodifrance\Pdv\Model\Config\Source\Width.

5. Créer le dossier Model/Config/Source dans app/code/Sodifrance/Pdv.

6. Créer le fichier app/code/Sodifrance/Pdv/Model/Config/Source/Width.php sur les bases du parent app/code/MGS/ThemeSettings/Model/Config/Source/Width.php.

On va se contenter de ne rendre disponible que la valeur 1200px pour les choix de largeur de page depuis l’interface d’admin.

7. On vérifie que le nouveau module Sodifrance_Pdv est bien activé:

7b. On l’active si il est présent dans la liste des modules désactivés:

8. On compile le setup:

Résultat: depuis l’interface d’admin, dans MGS > [MGS Theme] Theme Setting v1.1.0, accodéron « Général », champ « Largeur ». Le seul choix disponible reste « 1200px ».

Il faut tout-de-même enregistrer la configuration pour que les changements soient pris en compte.