Étiquette : template

[Magento 2] Depuis un template PHTML, détecter si la page sur laquelle nous nous trouvons est la homepage, une page produit, une page catégorie

Source: How to check IsHomePage in Magento 2? Are we on the homepage?

[Magento 2] Ajouter des blocs enfants via les layouts XML et la fonction getChildHtml dans un template PHTML

Note: voir ici pour les méthodes communément disponibles pour la variable $block. Elles vous permettront de récupérer pas mal d’infos disponibles dans n’importe quel template PHTML.

Fonctionnel Magento 2.4. Sources:

app/code/Magento/Sales/view/frontend/layout/sales_order_view.xml

Dans le DOM, les block imbriqués seront inclus à l’endroit où se trouve déclarée la fonction dans le PHTML du referenceContainer:

Comment afficher un child block en particulier?

[Magento 2] Appeler un template PHTML depuis une page CMS

Source: How to call a PHTML file within a CMS page Magento 2?

Formule générique:

Bloc par défaut:

[Magento 2] Afficher une liste produits par sous-catégories sur la page principale d’une catégorie

Par défaut, Magento 2 utilise un template PHTML unique pour afficher les listes produits d’une catégorie et de ses sous-catégories. Il s’agit du fichier vendor/magento/module-catalog/view/frontend/templates/product/list.phtml.

L’un des problèmes posé par ce mode de fonctionnement réside dans le fait qu’on se retrouve avec une page catégorie principale/main qui affiche, dans une liste unique, tous les produits contenus dans cette catégorie ainsi que ses sous-catégories et ceux sans aucun distingo. Ce qui nous donne, de manière très schématisée:

Le code décrit dans ce billet va permettre d’obtenir ceci:

Création d’un Helper: app/code/Pdv/Catalog/Helper/Data.php

Note: j’avais déjà créé ce Helper pour récupérer les Simple Products associés à un Configurable Product. Consulter le billet en question pour de plus amples infos si vous ne souhaitez pas exploiter tout le code ci-dessous. Ce Helper étend vendor/magento/module-catalog/Helper/Data.php.

Rajouts par rapport au Helper existant:

Sous la ligne namespace Pdv\Catalog\Helper;:

Sous la ligne protected $typeConfigurableResourceModel; // 1. Du nom du model dont je veux injecter la propriété de la classe:

Dans le constructeur, sous la ligne \Magento\ConfigurableProduct\Model\ResourceModel\Product\Type\Configurable $typeConfigurableResourceModel // 2. Demande à Magento une instance de mon configurable ressource model (EN RAJOUTANT UNE VIRGULE en fin de la ligne existante):

Sous la ligne $this->typeConfigurableResourceModel = $typeConfigurableResourceModel; // 3. ...et mappe le paramètre du constructeur avec la propriété de la classe:

Le commentaire:

…est enrichi comme suit:

Et la fonction getCurrentCategory() qui suit…

…est remaniée en:

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

Ce template PHTML se contente de boucler, autant de fois qu’il y a de sous-catégories, sur le template Magento_Catalog::product/list_abonnements_subcategory.phtml qui est une version custom du template vendor/magento/module-catalog/view/frontend/templates/product/list.phtml.

L’équivalent de ce fichier list_abonnements_subcategory.phtml DOIT exister dans votre projet. Si vous n’avez pas besoin d’en créer un spécifique, vous pouvez boucler sur le template par défaut fourni par Magento 2. Dans le code ci-dessus: ->setTemplate("Magento_Catalog::product/list.phtml"). Edit: il faut en créer un spécifique pour exploiter notre Helper.

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

Ce template PHTML doit partir de vendor/magento/module-catalog/view/frontend/templates/product/list.phtml. Il est impératif de rajouter les lignes suivantes en haut de fichier, sous la ligne $hoverChange = $themeSettingConfig->getStoreConfig('themesettings/catalog/hover_change');:

app/design/frontend/Sodifrance/pdv/Magento_Theme/page_layout/abonnements_category.xml

Reportez-vous à ce billet pour voir comment afficher un layout différent selon une catégorie spécifique. Cette étape est indispensable pour faire pointer notre catégorie vers notre template PHTML spécifique app/design/frontend/Sodifrance/pdv/Magento_Catalog/templates/product/list_abonnements_category.phtml. Un exemple de code pour ce fichier ci-dessous:

Vous voudrez aussi créer le layout XML app/design/frontend/Sodifrance/pdv/Magento_Theme/page_layout/abonnements_subcategory.xml

…pour fairez pointer les sous-catégories vers le template PHTML .

Externaliser le code JS

Afin que le code JS initialement présent au bas du fichier list.phtml ne soit pas exécuté autant de fois qu’il existe de sous-catégories, il a été externalisé dans un fichier app/design/frontend/Sodifrance/pdv/Magento_Catalog/templates/product/list_abonnements_js.phtml et déclaré de la sorte dans nos layouts XML spécifiques:

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

Le code de ce fichier, sorti de list.phtml:

[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

[Drupal 7.x] Ajouter des régions à un template de page

Deux fichiers impliqués :

  • <mon_projet>\sites\all\themes\<mon_theme>\<mon_theme>.info dans lequel nous allons initialiser des régions
  • <mon_projet>\sites\all\themes\<mon_theme>\page.tpl.php (qui est une surcharge de <mon_projet>\modules\system\page.tpl.php) dans lequel nous allons déclarer les régions précédemment initialisées afin qu’elles affichent du contenu

.info

\page.tpl.php

<?php if ($page['sidebar_first']): ?> : si il n’y a pas de contenu à afficher…

En backoffice

Structure > Blocks: on assigne chaque Block à une Region.

La fonction dpm() du module Devel

Le module Devel fournit une fonction dpm() qui permet d’afficher en front des informations sur les régions disponibles.

Dans un fichier *.tpl.php :

[Magento 1.9] Customizer les templates d’emails

Via le BO

Source : Customizing Magento email templates par Srikanth AD.

A creuser : via le BO et de le mettre dans un setup update pour en conserver une trace dans Git.

Via le code source

Avec l’extension Yreo Email Override.

  • Override email templates per theme
  • Also override CSV language files
  • Must-have tool for Magento devs

The EmailOverride extension allows Magento developers to create overrides of the email templates stored in app/locale/en_US/template/email in your own Magento custom theme.

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