Mois : avril 2020

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

[Docker] Faire un dump d’une table spécifique dans une base de données et récupérer le contenu dans un fichier txt hors container

Note: pour faire la même chose, mais via mysql: Dump a specific table or few rows (MySQL). $ mysqldump -u username -ppassword database_name table_name > single_table_dump.sql

Faire un dump d’une table spécifique via un container db Docker:

Log toi dans le container db

après : $ mysqldump  -uroot -proot magento core_config_data --tab="/tmp" --fields-enclosed-by='"' --fields-terminated-by=,

ce qui nous intéresse, c’est le fichier /tmp/core_config_data.txt qui sera généré. tu le copie via docker cp.

ça doit te donner un rendu qui ressemble à ça (sample):

Récupérer le contenu du dump dans un fichier TXT avec la commande docker cp:

Sortir du container db. On se retrouve à la racine de notre projet.

en décomposant : $ docker cp nom_du_container:path_dans_le_container path_local (. == l'endroit où tu es)

Le fichier core_config_data.txt devrait être disponible à la racine de notre projet (où à l’endroit depuis lequel la commande ci-dessus a été exécutée).

[Foundation 6] Exploiter le composant Drilldown et jQuery pour créer un product finder wizard

Un product finder wizard qui pose une série de questions pour aider l’utilisateur à trouver le bon produit en fonction de ses besoins. La fonctionnalité est constituée de:

  • le Drilldown de Foundation 6 pour la mise en place du wizard <ul class="vertical menu drilldown product-finder-tree">
  • des boutons de navigation Précédent, Réinitialiser et Suivant <div class="product-finder-actions">
  • un fil d’Ariane qui se constitue à la volée en fonction des choix précédents de l’utilisateur <div id="productFinderBreadcrumb" class="product-finder-breadcrumb"></div>

Partie PHTML

Le code HTML qui constitue le menu n’est autre qu’une liste non-ordonnée d’éléments imbriqués. Il est conforme au markup générique fourni par Zurb pour la démo du composant Drilldown aux exceptions près que:

  • les éléments <a> portent une classe .question
  • les éléments <li> ont un ID questionID_ (généré via PHP dans notre exemple)

Partie jQuery

Nous utilisons plusieurs méthodes natives du composant Drilldown de Foundation 6:

  • _hideAll pour réinitialiser le menu à son état initial.

    Attention: cette méthode semble bugguée. Je l’ai peut-être aussi mal exploitée, mais j’ai dû écrire un fix; voir ci-dessous:

  • _showMenu pour rediriger l’utilisateur vers un choix précédent dans le DOM du menu (lorsqu’il clique sur le bouton Précédent).

    Attention: il est important de pointer un élément UL (dans mon exemple, sur la classe .submenu) pour que cette méthode fonctionne!

  • _show pour rediriger l’utilisateur plus en avant dans ses choix dans le DOM du menu (lorsqu’il clique sur le bouton Suivant).

    Attention: il est important de pointer un élément LI (dans mon exemple, sur l’ID questionID_ se trouvant sur les LI) pour que cette méthode fonctionne!

[Foundation 6] Un lien parent cliquable qui renvoie vers une page dans le menu Drilldown

Source: Foundation 6 Drilldown clickable parent link with sub-menu

HTML

CSS

JS

[Magento 2] Erreur grunt exec « In SourceThemeDeployCommand.php line 179 » à la compilation des thèmes

J’ai un projet dans lequel j’utilise plusieurs thèmes qui héritent entre-eux. J’exécute la commande grunt exec pour compiler les assets front, mais l’erreur In SourceThemeDeployCommand.php line 179 apparaît également lorsque j’utilise la commande Magento setup:static-content:deploy:

Fil de discussion m’ayant aidé pour la résolution: Error when run command grunt:exec in Magento 2.2.0 #12271.

Les éléments à vérifier:

Vos thèmes ont tous le type égal à 0 dans la table theme en base de données

Source. Un theme avec un type de 1 a été automatiquement paramétré comme « virtuel » par Magento 2!

This error happens for multiple reasons, but probably the most annoying and most frequent relates to the fact that Magento2 attempts to validate themes.

Explanation

If a theme exists in the database, but is not physically available in the filesystem at the time the magento setup:install command is run, Magento2 will set it as a « virtual » theme. Once a theme is set as virtual, it is never unset by Magento2. It will forever be virtual until it is manually reset in the database. To reset the theme, go to the theme table, and set the type field to 0, and re-associate the theme with any parent_id. A theme with a type of 1 has been set to virtual.

This problem will provide a stack trace like the following:

This can all be traced through the _getPhysicalTheme method. It’s ridiculous that this even occurs. The physical presence of a theme should just break the site in a very expected way: that is, the frontend just doesn’t appear. Don’t try to be clever and modify the DB. Magento design decisions never cease to amaze me.

You can imagine what this means for anyone migrating their databases to a new host. For example, you import your DB dump to a new host. Once the DB is migrated, you then issue the standard magento setup:install command. Guess what? Now your theme will never build. Why? Because the theme itself did not physically exist on the filesystem at the time of the install. What is supposed to come first, Magento–the chicken or the egg?

Lorsque j’ai rencontré le problème, j’avais effectivement des thèmes dont le type était seté à 1 dans la table theme de ma base de données. J’ai dû, à la main:

  • les repasser à 0
  • vérifier (et reconfigurer si besoin) leur parenté

Avant modification:

Après modification:

Fichiers app/etc/config.php et app/etc/env.php

ATTENTION: vérifier également dans les fichiers app/etc/config.php et app/etc/env.php si le type n’est pas seté à 1 pour vos thèmes et corriger le cas échéant.

Vérifier votre version de node et l’upgrader/downgrader au besoin

La version de node qui fonctionne est la 8.12.0. Perso, mon Dockerfile était configuré sur latest.

Maintenant, tout dépend de la manière dont vous utilisez node. Voici comment mettre à jour Node et NPM proprement sous Ubuntu (ligne de commande) si la dépendance est installée en local sur votre machine.

Si vous utilisez Docker, il faut utiliser l’image node:8.12.0 au lieu de (pour moi) node:latest dans votre fichier Dockerfile.

Puis lancer un docker-compose build (pas besoin de down vos containers au préalable).

Puis docker-compose down et docker-compose up -d --force-recreate <nom_du_container> (exemple: docker-compose up -d --force-recreate node).

Si vous avez un script bash à sourcer (. ./docker/set-env.sh par exemple…) qui initialise un environnement de développement (avec des aliases pour accéder aux containers ou à certaines commandes, ou autre…), il faut également le ré-exécuter.

Attention: une fois la mise à jour de Node effectuée, il convient de repartir d’une installation fraîche du dossier node_modules (suppression du dossier et npm install.

Utiliser @magento_import à la place de @import dans vos sources LESS pour importer les fichiers que Grunt ne trouve pas

Le @magento_import est pour chercher tous les fichiers qui correspondent au path. par exemple:

va chercher tous les fichiers _module.less dans les sous dossier du thème.

Dans mon cas, les erreurs se trouvaient dans la section Theme Core des fichiers styles-m.less de vos thèmes parent et enfant, remplacer @import par @magento_import pour charger les fichiers que Grunt ne trouve pas.

ATTENTION: il est impératif de laisse les lignes @magento_import en commentaire //!

Exemple:

[Magento 2] Ajouter des paramètres de configuration des thèmes de la table core_config_data au fichier config.php

Dans le cas d’un site qui dispose de plusieurs store views (un Magento 2 multi-sites) la commande app:config:dump ne réalise pas un dump complet de la configuration faite en Admin de l’ensemble de vos sites. Le fichier config.php généré ne contient que les informations du scope Default Config (mon exemple ci-dessous):

La valeur de la clé theme_color est pourtant redéfinie pour chacun de mes store view!

Nous pouvons compléter ce fichier config.php à la main en allant récupérer les informations manquantes en base de données, dans la table core_config_data.

Dans l’illustration ci-dessus, j’ai par exemple effectué une recherche sur une valeur de la clé theme_color (qui représente un champ en BO) qui n’a pas été dumpée via la commande app:config:dump.

Pour répercuter ces informations dans le fichier app/etc/config.php, je me suis servi du scope (stores) et du path (themecore/general/primary_color/theme_color) stockés dans la table pour reconstituer le chemin au bon endroit: