Tagsurcharge

[Magento 2] Utiliser action method= »setTemplate » pour surcharger un fichier PHTML dans app/code/Vendor/Module plutôt que dans un thème

Je veux surcharger app/code/Magento/LayeredNavigation/view/frontend/templates/layer/view.phtml dans app/code/NakedUi/LayeredNavigation/view/frontend/layer/view.phtml. Source: How to Override a phtml File Using a Custom Module in Magento 2.

Créer un module NakedUi_LayeredNavigation qui contient au minimum les fichiers suivants:

./registration.php

./etc/module.xml

Puis dans ./view/frontend/layout, créer les deux fichiers suivants:

catalog_category_view_type_layered.xml et catalogsearch_result_index.xml

Ne pas oublier de surcharger ./view/frontend/templates/layer/view.phtml

[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] Surcharger override un layout ou un page layout XML

Ressources utiles:

Pour surcharger app/design/frontend/Mgs/supro/Magento_Catalog/layout/catalog_category_view.xml (qui est déjà une surcharge) dans un thème, il faut créer l’arborescence et le fichier suivants: app/design/frontend/Sodifrance/pdv/Magento_Catalog/layout/override/theme/Mgs/supro/catalog_category_view.xml.

Surcharger un page_layout

Un page_layout est un gabarit de mise en page. Exemple: 2columns-left, 2columns-right, .... On trouve ces gabarits par défaut dans vendor/magento/module-theme/view/frontend/page_layout/.

Si je veux surcharger le page_layout 2columns-left.xml

Je dois créer le fichier suivant: app/design/frontent/MyVendor/mytheme/Magento_Theme/page_layout/override/base/2columns-left.xml (attention à la partie override/base/).

[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.

[Change 3.6.x] Surcharger proprement un fichier .class.php

Dans un projet, j’utilise le module Survey qui sert à générer des formulaires d’enquêtes de satisfaction depuis le backoffice de Change 3.6.x.

Les différents champs de formulaire sont générés via un fichier modules/website/lib/helpers/FormHelper.class.php. Ce fichier ne se surcharge pas comme un template de bloc via override/modules/website/lib/helpers/FormHelper.class.php, mais dans le module du projet.

Convention: Pour ce tutoriel, notre projet s’appelle toto. Voici la liste des fichiers à modifier et des commandes à exécuter pour que les modifications prennent effet:

config/aop.xml

modules/toto/lib/aop/FormHelper.class.php

Copier le fichier source modules/website/lib/helpers/FormHelper.class.php et le coller à l’identique dans modules/toto/lib/aop/FormHelper.class.php, puis modifier la 2ème ligne comme suit:

Vous pourrez ensuite modifier comme bon vous semble ce fichier pour les affichages spécifiques à votre projet.

Les commandes à exécuter

  • cconf ou compile-config
  • ua ou update-autoload

[Foundation 6] Réinitialiser les styles par défaut pour l’élément HTML de formulaire Input

Source: Cleanest way to customize input[type=’text’] styles, codewise.

Depuis quelques semaines (et deux projets en cours de production), je décortique avec grand intérêt le framework front-end responsive Foundation 6 for sites créé et maintenu par Zurb. J’utilise Bootstrap 3 depuis sa première release stable (et Bootstrap 2 avant ça). Mais Bootstrap 4 étant encore en version Alpha j’ai décidé, pour voir, de me tourner vers une solution que je considère comme étant son principal challenger (la première version stable de Foundation 6 ayant vu le jour il y a plus d’un an).

Les possibilités offertes par Foundation 6 en terme d’habillage des champs de formulaire

Dans Foundation 6, les styles de l’ensemble des champs de saisie textuelle des formulaires (text, password, date, datetime, datetime-local, month, week, email, number, search, tel, time, url, color mais aussi l’élément HTML textarea) sont générés à partir d’une fonction text-inputs.

Cette fonction est déclarée dans le fichier /scss/util/_selector.scss du framework et se présente comme ceci:

C’est ensuite à l’aide d’un mixin foundation-form-text déclaré dans le fichier /scss/forms/_text.scss du framework que toute la batterie de styles par défaut pour l’élément input, l’ensemble de ses itérations
et l’élément textarea sont générés. Ce mixin se présente comme ceci (extrait) :

Le code CSS qui en résulte ressemble à ceci (extrait) :

Annuler les styles par défaut sur une sélection d’éléments

A ce stade, nous pourrions avoir besoin d’annuler les styles par défaut sur une sélection d’éléments pour repartir from-scratch (le bon vieux concept de reset CSS) et habiller un ou plusieurs champs de notre charte qui se démarquent visuellement des standards (un champ « Recherche » dans le bandeau de votre site ou un champ d’inscription à la « Newsletter » en pied de page par exemple; cette contrainte se présente quasi systématiquement).

Pour annuler les styles standards pour l’élément de formulaire input, nul besoin d’écrire un reset. Il faut surcharger le mixin foundation-form-text en passant en paramètre $modifier une pseudo-classe :not() à laquelle on attribuerait une classe générique, mais au libellé suffisamment parlant (par exemple, .is-unstyled (extrait):

La sortie CSS sera alors la suivante (extrait):

Désormais, un <input type="text" class="is-unstyled" /> ne sera plus affecté par les styles standard de Foundation 6. Pas besoin d’alourdir son code CSS avec quantité de styles reset pour annuler les déclarations par défaut. On peut se concentrer sur notre habillage custom.

Petit conseil: n’utilisez cette classe .is-unstyled que pour signifier, dans votre code HTML, quels éléments input ne doivent pas hériter des styles standards de Foundation 6. Pour les styler différemment, ajoutez une classe supplémentaire. Exemple:

Pour finir, sachez que vous pouvez faire appel à la fonction text-inputs à (quasiment) n’importe quel endroit dans votre code SCSS pour déclarer des styles spécifiques pour un élément donné ou toute une batterie d’éléments à la fois.

Quid des possibilités offertes par Bootstrap 4 en terme d’habillage des champs de formulaire?

De prime abord, on peut trouver ça déroutant que les styles soient appliqués à des attributs d’éléments plutôt que sur les éléments eux-mêmes via des classes, surtout si on est habitué à la logique Bootstrap 3 ou 4 et à ses classes .form-group et .form-control à appliquer sur des <div> englobantes ou sur les éléments eux-mêmes. Les styles Foundation 6 habillent d’office l’ensemble des champs de formulaires et c’est embêtant quand on veut s’affranchir de la patte graphique « Foundation » pour afficher certains formulaires.

Mais dans la pratique et avec les contraintes du terrain, la décision s’avère extrêmement pertinente (surcharge de toute la batterie de champs de formulaires d’un coup !).

Il faut le reconnaître, les formulaires sont c$%!§£s à habiller. J’ai voulu faire un test très simple: j’ai récupéré le code HTML d’un formulaire sur un site réalisé avec Drupal 7 (donc n’intégrant ni Bootstrap, ni Foundation pour que la structure HTML reste totalement neutre) et le module Webform. J’ai ensuite appliqué tour à tour la CSS sortie-de-la-boite de Bootstrap 4 et de Foundation 6 sans modifier de code ni HTML, ni CSS.

N’hésitez pas à agrandir/réduire la fenêtre en largeur pour tester l’aspect Responsive.

Avec Foundation 6, la mise en page est propre. Les champs sont habillés de manière minimaliste et le tout est parfaitement Responsive. Si votre client ne souhaite pas investir trop d’argent dans les formulaires, vous n’avez quasiment aucun travail à faire (minus peut-être les boutons à habiller) sur ce point pour obtenir un affichage convenable.

Avec Bootstrap 4, rien n’est habillé. Rien n’est Responsive. Et pour cause, les classes .form-group et autre .form-control doivent être rajoutées dans le code HTML pour obtenir un résultat (on peut aussi passer par SASS pour faire pointer les styles des classes Bootstrap sur les classes déjà en place). Au travail les développeurs front-end!!

Conclusion

A partir du moment où on décide d’aborder Foundation 6, on ne peut échapper à la comparaison avec Bootstrap 4. Chaque fois que j’en parle autour de moi, mes interlocuteurs veulent savoir si c’est mieux.

Comme je le disais en introduction, j’ai utilisé Bootstrap pendant des années. J’en connais ses points forts et ses points faibles et force est de constater que ces derniers n’ont pas été gommés avec l’arrivée de la version 4. Et l’habillage des formulaires ne reste qu’un tout petit exemple. Essayez de passer d’un menu accordéon en vue Mobile à un menu horizontal déroulant en vue Desktop… Le markup HTML est toujours (passage de la version 3 à la 4) différent d’un composant à l’autre, toujours pas de prise en charge des mediaqueries via JS, toujours pas de méthode .destroy() selon les cas.

En revanche, on sent dans la logique de fonctionnement et d’articulation du code de Foundation 6 que ses concepteurs sont des développeurs front-end chevronnés. Le framework est conçu pour être facile à utiliser et à étendre. Ses composants sont étudiés pour répondre aux contraintes quotidiennes du développeur. Avec les composants de navigation Responsive inclus, passer d’un menu accordéon en vue Mobile à un menu horizontal déroulant en vue Desktop se fait avec des classes et des data-attributes à ajouter au bon endroit dans le code HTML. Même pas besoin d’écrire de JS! Et on voit avec l’exemple donné dans ce billet que le code natif est pensé pour s’adapter immédiatement à l’environnement dans lequel il est parachuté.

Je ne peux que vous motiver à tenter de produire un site avec Foundation 6. Vous m’en direz des nouvelles 😉



Hello,
this is not an issue, but more of a concern about how to make the best out of Foundation 6 out-of-the-box SCSS components for custom website design.
So, I hope some skilled Foundation users will read this and share their opinions. 🙂

I’ve found some of the mixins to either:

  • include too much CSS properties for custom needs (core and skin properties are often merged within a same mixin),
  • prevent developer to custom-skin HTML elements (with skin values being forced rather than being included as mixin parameters).

As an example, here’s the dropdown-container mixin that includes both core and skin CSS properties :

Let’s assume I have 10 elements on my website that would use the dropdown component. 9 of them would have the same design. I can set the $dropdown- variables in the _dropdown.scss file to my regular needs.

But what if I want to take profit of the dropdown component for 1 specific element, but don’t want to show a border or need custom padding compared to the regular dropdown ?
Solutions I came up with include:

1. Make use of the regular mixin and override skin properties

(I guess I could use a Gulp plugin to remove duplicated properties within the same declaration… => Gulp clean-css with removeDuplicateRules option. Or CSS nano with discardDuplicates option).

Edit: even with a good Gulp CSS cleaning plugin, I can see a couple of issues doing that way :

  • You’ll still need to reset each and every property included in the mixin and that you don’t want to use :

2. (heavier and not so good idea IMO) Split standard mixin in 2.

3. Creating an SCSS placeholder that includes mixin core properties.

Third solution is the one I prefer so far. I might dig for a Gulp plugin that removes duplicate properties and first solution might become my favourite in the end.
What would you do?

Thanks.

[Drupal 7.x] Créer des surcharges de templates pour un type de node/noeud spécifique

Ce qu’on veut faire: avoir 2 différents fichiers node.tpl.php pour avoir 2 HTMLs différents (1 pour les articles, l’autre pour les pages basiques).

Documentation officielle sur les possibilités de surcharge: Template (theme hook) suggestions – A theme hook suggestion is an alternate template (.tpl.php) file that you have created to override the base or original template file.

Comment nommer un fichier de surcharge afin que Drupal fasse le lien avec le contexte (types de contenu/content types) dans lequel il doit être utilisé ?

Un fichier node se nomme selon cette règle : node--[type|nodeid].tpl.php.

Pour un node de type article, notre fichier se nommera donc node--article.tpl.php, alors que pour un node de type page, notre fichier se nommera node--page.tpl.php. Le mot clé à utiliser dans le libellé du fichier est le Machine name du content type qu’on cherche à cibler.

Pour connaître la liste des content types disponibles, se rendre en backoffice dans Structure > Content types. Par défaut, il n’y a que Article et Page.

Ordre de priorité pour l’affichage des surcharges de nodes.tpl

Fallback:

  1. node–nodeid.tpl.php
  2. node–type.tpl.php
  3. node.tpl.php

[CSS] Les règles d’héritage

Demo JSFiddle.net

A part !important, est-ce qu’il existe des trucs propres pour qu’un style prenne le dessus sur un autre avec lequel il est en concurrence?

La surcharge par ordre de déclaration dans la CSS :

Pour prendre la main, t’as la surcharge : tu déclares .box { padding: 12px; } puis plus loin, tu re-déclares .box { padding: 22px; }.

C’est toujours la dernière déclaration rencontrée pour un élément donné qui est prise en compte et qui écrase toutes les précédentes.

Le ciblage par précision dans le chemin (dans le DOM) qui permet d’atteindre l’élément :

Code HTML :

Dans l’ordre de priorité tu as :

  1. .riri .fifi .loulou{ font-size: 12px } (le + important)
  2. .fifi .loulou { font-size: 22px; }
  3. .loulou { font-size: 42px; } (le – important)

Et là, plus tu seras précis dans la manière (le chemin) de cibler ton élément, plus tes styles prendront le dessus peu importe l’ordre dans lequel ils sont déclarés dans ta/tes CSS.

Il y a encore un cas supplémentaire dans la demo JSFiddle.net, donc à voir et à utiliser pour manipuler d’autres cas à l’avenir.

[Change cross commerce] Surcharger un template issu d’un module standard dans un thème personnalisé

Attention : doc en cours de rédaction …

Surcharger le template qui affiche la liste de produits

Arborescence standard : où trouve-t’on les templates standards ?

Deux types de fichiers concernés : les directives Angular JS et les blocs

Arborescence d’un thème personnalisé : où consigner nos surcharges des templates standards ?

blocks-templates.json : déclarer l’existence d’une surcharge de template pour la rendre exploitable en backoffice.

Le fichier json permet également de passer un certain nombre de paramètres.

admin.json : créer une locale pour identifier votre nouveau template en backoffice.

Nomenclature

La surcharge d’un template se trouvant nativement dans le répertoire Plugins/Modules/[nom_du_vendor]/[nom_du_module]/Assets/Twig/Blocks/ se fera obligatoirement dans le répertoire App/Themes/[nom_du_vendor]/[nom_de_votre_plugin]/Assets/Twig/[nom_du_vendor]_[nom_de_votre_plugin]/Blocks/.

Ainsi, pour notre exemple de liste produits, le template product-list.twig se trouvant nativement dans le répertoire Plugins/Modules/Rbs/Catalog/Assets/Twig/Blocks/ se fera obligatoirement dans le répertoire App/Themes/Project/[nom_de_votre_plugin]/Assets/Twig/Project_[nom_de_votre_plugin]/Blocks/.

Attention : l’unique emplacement censé regrouper les surcharges de l’ensemble des templates des répertoires Twig/Blocks/ de tous les modules de Change Cross Commerce pouvant se retrouver rapidement saturé de fichiers, il est conseillé pour optimiser la lisibilité de préfixer les libellés de vos fichiers surchargés.

Ainsi, la surcharge du fichier standard product-list.twig pourrait se nommer rbs-catalog-product-list.twig pour [nom_du_vendor]-[nom_du_plugin]-[nom_du_template_standard].twig.

Utilisation de {% extends %} : rbs-catalog-product-list.twig

Utilisation de {% use %} : product-list-directives.twig

rbs-order-order-detail.twig

On n’utilise ni {% extends %}, ni {% use %} dans ce cas là :

Remarque : Les surcharges de fichiers issus des répertoires Blocks/ peuvent contenir des directives Angular issues des fichiers [libellé]-directives.twig. Ceci évite de surcharger un fichier supplémentaire.

© 2020 devfrontend.info

Theme by Anders NorénUp ↑