Tagsurcharge

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

[Change cross commerce] Exploiter de manière sélective les ressources CSS du core dans un thème personnalisé

Attention : doc en cours de rédaction …

Si vous souhaitez conserver dans votre thème personnalisé l’affichage homogène et minimaliste fondé sur le framework Bootstrap et l’ensemble de petites fonctionnalités (modals, zoom produit) liées au core de Change Cross Commerce, il est nécessaire de ré-exploiter certaines feuilles de style présentes dans le thème Rbs_Base.

Change Cross Commerce, bien qu’embarquant un nombre assez conséquent de dépendances CSS (le framework Bootstrap est éclaté en autant de feuilles LESS que de composants et plug-ins qui le constituent), est pensé de manière à pouvoir écraser uniquement les composants qui demanderaient une ré-écriture et à exploiter les versions core pour tout le reste.

Arborescence standard : où trouve-t’on les feuilles de style ?

Le thème par défaut de Change Cross Commerce embarque (selon moi) deux types de feuilles de styles :

  1. les composants natifs Bootstrap accessibles à tous depuis la page Customize and Download du site officiel,
  2. les fichiers ajoutés par l’équipe en charge du développement du produit pour des fonctionnalités non couvertes par Bootstrap (redimensionnement des médias, helpers, quelques fixes, …).

Arborescence d’un thème personnalisé : où consigner les feuilles de styles, les surcharges et les ré-écritures ?

assets.json : déclarer les dépendances JS, CSS et les locales de traduction de votre thème.

Pour l’inclusion de start.less :

Surcharger ou écraser ?

Nous avons vu plus haut que le thème par défaut de Change Cross Commerce embarquait deux types de feuilles de styles. Avec le recul que j’ai actuellement sur le développement avec la solution, j’ai fait le choix :

  • d’écraser les composants natifs Bootstrap que je souhaitais modifier.

    Dans le cadre d’une surcharge, il faudrait d’abord ré-écrire des styles reset pour annuler la portée du code standard sur l’affichage pour, ensuite seulement, poser son code spécifique.
    Ici, on copie/colle et on modifie directement le code du composant natif à sa convenance.

    (Si on maîtrise un minimum la logique d’articulation Bootstrap) on évite une certaine lourdeur, on gagne en temps de maintenance et on conserve la flexibilité du framework. Une mise à jour mineure du core Bootstrap ne rendra pas la migration des fichiers natifs partiellement ré-écrits plus ardue car ils demeurent, pour la plupart, très légers. Et une mise à jour majeure du core Bootstrap (passage à une version supérieure) forcerait de toute manière le développeur à un travail de migration plus approfondi.

  • de surcharger les fichiers ajoutés par l’équipe en charge du développement du produit pour des fonctionnalités non couvertes par Bootstrap.

    On importe d’abord le fichier standard, puis sa surcharge contenant uniquement les propriétés redéfinies. La nature des déclarations CSS contenues dans ces fichiers et leur impact sur l’affichage front fait qu’aucun exercice d’écriture de code reset ne serait de toute manière nécessaire.

start.less : le point de départ pour vos imports de feuilles de styles

Il existe deux manières d’importer des dépendances CSS dans Change Cross Commerce :

  1. Renseigner le fichier assets.json.

    Avantages/Inconvénients : vous pouvez appeler de manière sélective vos dépendances en fonction des différents gabarits de pages qu’embarque votre thème. Si vous avez beaucoup de feuilles de styles, la lisibilité de votre code en prendra un coup…

  2. Créer un fichier start.less

    Avantages/Inconvénients : les imports de feuilles de styles se font pour l’ensemble des gabarits de pages. Cette méthode se révèle moins sélective à moins de créer et d’appeler dans un fichier start-[libellé_de_mon_template].less différent pour chaque gabarit de page.

Exemple d’un fichier surchargé : image-formats.less

On ne ré-écrit que les lignes qu’on souhaite changer pour les besoins de son thème Custom :

bootstrap.less : le point de départ pour vos ré-écritures de composants Bootstrap

On appelle les composants qui ne nécessitent pas d’écrasement depuis le thème Base et les ré-écritures depuis le thème Custom :

variables.less : le point de départ pour définir l’aspect général des éléments de frontoffice.

Ce fichier définit un nombre important de variables garantes de l’homogénéité d’affichage des éléments typographiques, des éléments de formulaire et des divers composants Bootstrap (grille et mediaqueries, menus, fil d’ariane, pagination, modal, …). Il constitue les fondements de l’affichage de toute interface embarquant le framework Bootstrap et, donc, par extension de tout thème Change Cross Commerce.

  • Exploitez-le au maximum pour préserver un agencement et un affichage homogène des contenus dans vos pages.
  • Prenez bien connaissance des variables existantes avant de déclarer des doublons ou de redéfinir à-la-sauvage des déclarations CSS supplémentaires qui concerneraient l’aspect de composants embarqués.

© 2020 FrontEndDeveloper

Theme by Anders NorénUp ↑