Étiquette : erreur

[Magento 2] Modifier le positionnement des messages d’erreur lors de la validation d’un formulaire

27/01/2021 /

Testé fonctionnel Magento 2.4 CE. Source: form-validation-with-custom-error-placement-magento-2.

The function errorPlacement is a function of the mage.validation widget in Magento 2 and can be found under vendor/magento/magento2-base/lib/web/mage/validation.js

Je suis parti, pour mon exemple ci-dessous, d’une surcharge du template PHTML subscribe.phtml issu du module Newsletter.

J’ai ajouté un élément <div id="custom-newsletter-validate-detail-error-message-container"></div> avec un ID à l’endroit où je souhaitais voir se positionner mon message d’erreur. Puis j’ai rajouté le contenu sous la seconde balise <script> dans mon exemple ci-dessous (utilisation de la fonction errorPlacement de validation.js.

[Magento 2] Erreur Import failed: Invalid Base URL au app:config:import ou au setup:upgrade

04/11/2020 /

Si en tapant la commande: bin/magento app:config:import ou bin/magento setup:upgrade, vous rencontrez l’erreur suivante:

… c’est que vous avez quelque part dans un fichier de conf (app/etc/config.php ou app/etc/env.php) ou en base de données (dans la table core_config_data en général) une URL qui ne se termine pas par un caractère slash /.

En effet, les URLs dans les confs et la base de données Magento 2 doivent toutes obligatoirement se terminer par un slash!

Erreur documentée ici sur le site d’Alan Storm: Invalid Base URL. Value must be a URL or one of placeholders: {{base_url}} mais aussi dans certains fils de discussion comme celui-ci sur magento.stackexchange.com.

Note: ça ne me paraît pas logique, mais j’ai eu à nouveau le message d’erreur Import failed: Invalid Base URL. Value must be a URL or one of placeholders: {{base_url}} même après avoir modifié la valeur de la clé base_url dans la table core_config_data pour ajouter un caractère slash à la fin de l’URL et après avoir réussi à accéder à mon front-office une première fois.
J’ai alors fait un dump de ma config via la commande bin/magento app:config:dump (ATTENTION: cette commande écrase le fichier app/etc/config.php existant sans en faire une copie de sauvegarde au préalable!), puis rafraîchi immédiatement mon front. Il s’est affiché.

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

[jQuery] Conflits, message d’erreur « $ is not a function » et corrections possibles

11/02/2015 /

En jQuery, l’appel d’une fonction se fait en général de la manière suivante :

L’objet $ est utilisé par jQuery en tant que récupérateur de fonctions, et le script sait quelle librairie appeler. Problème : si vous utilisez d’autres librairies qui utilisent aussi le dollar comme objet par défaut (Prototype, Scriptaculous dans Magento par exemple…), vous obtiendrez potentiellement des conflits et un message d’erreur de type $ is not a function !

Solution 1 :

Utiliser la fonction jQuery.noConflict(); et créer une fonction anonyme. Source : jquery – is not a function error.

Solution 2 :

Remplacer tous les $ par un alias jQuery afin de réassigner toutes les variables de l’objet $ à ce dernier. Source : « $ is not a function » dans JQuery – La solution.