Étiquette : thèmes

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

02/04/2020 /

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

01/04/2020 /

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: