Indexation URL’s Magento : An error occurred while saving the URL rewrite

Une fois n’est pas coutume, j’ai été confronté aujourd’hui à un souci bête et méchant qui m’a fait perdre quelques dizaines de minutes. je vais vous faire part ici de la solution que j’ai finalement réussi à trouver.

Le contexte

En ouvrant mon BO : petit message concernant la « Réécriture d’URL du catalogue » qui demandait une réindexation suite à la mise en place de redirections 301 custom.  J’avais mis 3-4 jours auparavant en place ces redirections pour des produits définitivement hors stock et dont je en voulais pas perdre le jus de lien.

Vous me direz : « rien de plus simple, ya ka cliquer sur réindexer ! »

Que nenni ! Indexation impossible pour une raison inconnue.

Même en SSH , toujour la même réponse à la commande :

php shell/indexer.php –reindex catalog_url

à savoir :

An error occurred while saving the URL rewrite

La solution

Impossible de trouver une solution qui convienne parmi les dizaines trouvées jusqu’à ce que je tombe sur un post qui évoque le fichier exception.log dont j’avais oui dire mais que je n’avais jamais utilisé.

Ce fichier se trouve dans le dossier /var/log à la racine de votre Magento mais n’est pas généré sans une activation préalable dans le BO :

système/configuration/développeur/paramètres de log

Après avoir re-généré mon erreur d’indexation, ce fichier a vu le jour et j’ai pu trouver à l’intérieur la raison de mes tracas :

exception ‘PDOException’ with message ‘SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘product/64-1-1‘ for key ‘UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID » in /var/www/vhosts/xxxxxx.fr/httpdocs/lib/Zend/Db/Statement/Pdo.php:228

En fait, la fameuse réécriture de l’URL du product/64 générait un doublon interdit par MySql sur une clé primaire de l’index des réécritures d’URL’s.

Il m’a donc suffit de me rendre dans mon back office  dans

catalogue/Gestion de réécriture d’URL

de filtrer ma colonne ‘ID chemin ‘ (le fameux ID_PATH ci-dessus) avec la valeur ‘product/64′ pour m’apercevoir que cette valeur était effectivement en double.

Après suppression de la ligne incriminée et relancement de ma commande SSH , j’ai pu avoir le bonheur de lire cette ligne dans Putty :

Catalog URL Rewrites index was rebuilt successfully

J’ai à posteriori du mal à comprendre car en théorie, Magento n’accepte pas d’enregistrer une réécriture personnalisée qui contient un doublon sur ce type de valeur.

Enfin ! Allez comprendre !

Ce tip vous sortira peut-être de ce genre d’embarras un de ces jours.

En utilisant exception.log, vous pourrez mettre en lumière, comme certains utilisateurs confrontés à des problématiques d’indexation que j’ai pu lire lors de mes recherches ,  des erreurs de doublon sur d’autre valeurs comme les URL’s de catégorie ou de pages CMS.

Nota : pour ceux qui aiment s’aventurer en SSH, je recommande vivement l’usage de la commande de réindexation shell lorsque vous vous trouvez dans le dossier de votre Magento en SSH :

php shell/indexer.php –reindex catalog_url

que vous pouvez décliner à toutes les sauces en fonction de vos besoins.

La méthode la plus « bourrin » consistant à réindexer tous les index en même temps avec :

php shell/indexer.php reindexall

Pour les gros catalogues, c’est une méthode que je recommande vivement sachant qu’elle est (je n’ai pas mesuré vraiment 🙂 au moins 10x plus rapide que l’indexation via le back office.

Vous pouvez aussi comme moi, lancer via une cron cette commande à échéance réulière pour vous assurer que votre index est toujours à jour.

Pour ceux que ça intéresse, allez donc jeter un oeil là-bas pour en savoir plus sur l’indexer.php.

Magento : appliquer une couleur différente par catégorie dans le top menu

Encore un casse-tête résolu après de longues heures passée pour essayer de mettre en relief via ma CSS une catégorie en particulier dans le menu principal de Magento. Le but étant de faire ressortir du lot telle ou telle autre catégorie ou tout simplement de rendre mon top menu multicolore.

J’ai même testé certaines extensions du type « Custom Menu »  mais systématiquement, je me retrouvais confronté soit à des conflits JS, soit à des incompatibilités graphiques avec le top menu de mon template. (Je rappelle que je suis une bille en code^^.)

Pour info, toujours sur Magento 1.8.1, j’utilise le template ULTIMENTO de feu l’éditeur Commative qui a mis la clé sous la porte il y a presque un an mais j’ai pu mettre en application la méthode sur 2 sites utilisant des  templates différents.

A la lecture des quelques posts évoquant ce sujet, il ressortait quasi systématiquement des astuces relatives aux templates qui hiérarchisent les items-menu du type nav-1, nav-2, nav-1-1 … mais rien n’y faisait. Marchait pas avec mon template « custom ».

N’étant pas expert CSS3, je me suis laisser espérer qu’un selecteur puisse de lui-même déterminer la position – le n° d’ordre – d’un élément d’une série de <li>, <p>, <a> … En clair, appliquer telle classe par exemple, au 2e paragraphe d’un texte, à la 3e puce d’une liste ou au 5e lien d’une série de liens.

Tintintin !! Le sélecteur en question existe et s’appelle nth-child().

En pratique : mon menu était construit ainsi. Chacun des item de la liste <li> (le catégories principales de mon catalogue) revêtaient la même classe :

#exploded-menu li a.top-nav-item {
text-decoration:none;
float:left;
display:block;
margin-top:2px;
line-height:42px;
font-size:15px;
color:#98151d;
text-align:center;
padding:0 9px;
}

Je rappelle – si besoin était – que vous pouvez trouver le nom de la classe à modifier en utilisant des outils tels que Firebug pour Mozilla ou les Developper Tools de Chrome (raccourci F12 pour lancer l’outil).

Souhaitant mettre en couleur la première catégorie de mon topmenu, j’ai simplement ajouté la classe :

#exploded-menu li:nth-child(3) a.top-nav-item {
background-color:#FFBA00;
border-radius:3px;
color:#fff;

Le 3 entre ()  signifie que le 3e <li> de mon <ul> devait porter cette classe.

Pourquoi 3e et non pas le 1er me direz-vous ?

Car le #1 est une petite icone en forme de maison pour linker vers la homepage, le 2e est un séparateur graphique PNG, et le 3e la catégorie concernée par le changement de couleur.

Autre exemple d’application de ce sélecteur sur un autre site :

#mainMenu .menu > li:nth-child(12) > a

N’oubliez pas au besoin d’adapter aussi la classe pour le :hover ou le :active :

#exploded-menu li:nth-child(3) a.top-nav-item:hover {
background-color:#FFBA00;
color:#fff;
}

Vous pourrez désormais colorer tous les items de votre top menu et le rendre un peu plus sexy.

Amusez-vous bien !

Pour plus d’info sur ce selecteur, je vous recommande l’excellent site w3schools.com.

Owebia : Call to a member function getData() on a non-object in CartItem.php on line 64

Je suis devenu fou en essayant de comprendre pourquoi un de mes produits phares ne se vendait plus depuis 10 jours.

Un coup de fil d’un de mes client m’a mis la puce à l’oreille : en fait, le module générait une erreur à cause d’un règle mise en place et expliquée dans ce billet pour analyser les attributs des produits contenus dans le panier et motiver le choix de telle ou telle méthode de livraison. Et cette erreur l’empêchait de commander. A la mise au panier, le client se retrouvait sur une page blanche et ne pouvait plus rien faire tant que son panier ne se vidait pas automatiquement … à savoir, pendant 1 heure.

En regardant mes logs je trouvais l’origine du problème :

Call to a member function getData() on a non-object in /[…]/app/code/community/Owebia/Shipping2/Model/Os2/Data/CartItem.php on line 64

En fait, l’erreur Magento 1.8.1 était liée à la typologie du produit : packagé et pour une raison inconnue (en tout cas de moi) l’analyse des attributs du produit en question ne pouvait se faire correctement.

Pour ceux qui se retrouveraient dans cette situation, voici la solution :

Dans config –> Owebia Shipping 2 –> Gestion des produits packagés (Bundle Product) , modifier le « Traitement des articles » en passant par « Les Enfants » au lieu de « Lui-même« .

Et hop ! Plus d’erreur !

 

Ajouter une description de méthode de livraison Owebia dans le tunnel

Toujours sur Magento 1.8.1, j’ai souhaité ajouter des précisions au niveau du choix du mode de livraison pour aiguiller les clients, notamment concernant le « retrait boutique ». Mais cela reste valable naturellement pour toutes les autres méthodes de shipping Owebia.

Cette procédure m’a aidé car mon template ne prévoyait pas à l’origine l’affichage des descriptions des modes de livraison.

Mais j’ai oui dire que certains templates le faisaient par défaut. Si vous êtes dans ce cas, ce tip ne vous concernera donc pas.

Dernière précision, j’utilise le ONEPAGE checkout natif de Magento 1.8.1.

Tout d’abord, il nous faut ajouter la description en question dans la config du module Owebia en ajoutant ceci au modes de livraison concernés:

{
« boutique »: {
« type »: « meta »,
« about »: « Chronopost – Tarifs 2015 »,
« author »: « moi »
},

« boutique »: {

« label »: « Retrait boutique »,
« description »: « Retirez vos articles dans 24h tous les jours du lundi au samedi inclus et de 9h30 à 18h30. Notre adresse : XXXXX – XXXXX  – Tél: XX XX XX XX XX »,
« conditions »: « {count items where product.attribute.dispo==’642′} == 0 »,
« shipto »: « FR,MC,AD »,
« fees »: 0
}

}

Nota : petite précision concernant la raison d’être du « shipto »: « FR,MC,AD » : des petits malins avaient trouvé l’astuce de mentionner une adresse de livraison dans les DOM TOM et choisissaient le retrait boutique pour éviter de payer la TVA. Ca ne marche plus désormais grâce à cette restriction 🙂 .

Une fois chose faite, il nous faut récupérer cette description dans le template. Elle est amenée à s’afficher à 2 étapes distinctes du funnel :

  1. dès l’arrivée au panier pour le résultat de l’estimation des frais de port.

    Estimation des frais de livraison

    Pour permettre l’affichage de cette description, il vous faut ajouter un echo dans le fichier : frontend/base/default/template/checkout/cart/shipping.phtml préalablement copié avec son arborescence dans votre template local.

    A partir de la ligne 94, dans la balise <label> il vous faudra remplacer :

    <label for= »s_method_<?php echo $_rate->getCode() ?> »><?php echo $this->escapeHtml($_rate->getMethodTitle()) ?>
    <?php $_excl = $this->getShippingPrice($_rate->getPrice(), $this->helper(‘tax’)->displayShippingPriceIncludingTax()); ?>
    <?php $_incl = $this->getShippingPrice($_rate->getPrice(), true); ?>
    <?php echo $_excl; ?>
    <?php if ($this->helper(‘tax’)->displayShippingBothPrices() && $_incl != $_excl): ?>
    (<?php echo $this->__(‘Incl. Tax’); ?> <?php echo $_incl; ?>)
    <?php endif; ?>
    </label>

    par

    <label for= »s_method_<?php echo $_rate->getCode() ?> »><?php echo $this->escapeHtml($_rate->getMethodTitle()) ?>
    <?php $_excl = $this->getShippingPrice($_rate->getPrice(), $this->helper(‘tax’)->displayShippingPriceIncludingTax()); ?>
    <?php $_incl = $this->getShippingPrice($_rate->getPrice(), true); ?>
    <?php echo $_excl; ?>
    <p style= »font-weight:normal; »><?php echo $this->escapeHtml($_rate->getMethodDescription()) ?></p>
    <?php if ($this->helper(‘tax’)->displayShippingBothPrices() && $_incl != $_excl): ?>
    (<?php echo $this->__(‘Incl. Tax’); ?> <?php echo $_incl; ?>)
    <?php endif; ?>
    </label>

     

  2. au niveau du choix du mode de livraison.

    Méthodes de livraison Owebia disponibles pour la commande en cours

    Méthodes de livraison Owebia disponibles pour la commande en cours

    Pour permettre l’affichage de cette description, il vous faut répéter la méthode ci-dessus dans le fichier : frontend/base/default/template/checkout/onepage/shipping-method/available.phtml préalablement copié avec son arborescence dans votre template local.

Un petit refresh de votre cache et l’affaire devrait être dans le sac.

 

Owebia 2.5.18 et Magento 1.8.1 : count items where product.attribute…

Voici un bon moyen de neutraliser l’affichage d’une méthode de livraison en fonction d’un attribut produit dans l’excellente et gratuite – dans sa version de base qui est déjà fantastique – solution OWEBIA  à votre dispostion içi.

Ce que nous allons aborder içi concerne la toute dernière version (actuellement 2.5.18). Si vous n’êtes pas équipés de la dernière version, je vous invite à faire une mise à jour car au fil du temps, de nouvelles fonctionnalités sont proposées. Attention en revanche car il se peut que des changements majeurs interviennent d’une version à l’autre. C’est ce qu’il m’est arrivé récemment et depuis, je m’impose de faire des tests en préprod avant de mettre à jour mon site de prod afin d’éviter de me retrouver à nouveau dans la situation  de devoir refaire ma configuration en urgence pour cause de disparition totale de mes méthodes de livraison.

Enfin! Nous n’allons pas nous attarder ici sur tous les bénéfices qu’Owebia peut vous apporter – je vous laisse découvrir par vous-même l’excellente doc mise à disposition sur le site de l’éditeur – mais seulement sur une difficulté que j’ai eue à mettre en place un filtre « attribut » dans la gestion des méthodes de livraison.

Le but étant de dire à Owebia : « tu ne m’affiches pas telle méthode de livraison si un ou plusieurs produits du panier ont telle ou telle valeur d’attribut. »

A la lecture de la documentation Owebia la tache semblait facile mais je me suis aperçu que , s’agissant d’attribut « non système » et dans la configuration qui était la mienne, la règle mise en place dans le module ne faisait pas son travail.

Pour ma part, une règle sensée compter le nombre de produit dans le panier dont l’attribut « etat » présentait une valeur « Echange Standard » ne fonctionnait pas.

Voici la syntaxe que j’ai utilisée :

« id_027 »: {
« label »: « boutique »,
« description »: « Retrait boutique »,
« shipto »: « FR,MC,AD »,
« conditions »: « {count items where product.attribute.etat==’Echange Standard‘} == 0″,
« fees »: 10
},

En clair : compter le nombre de produits dont l’attribut « etat » est « Echange Standard » et ne proposer le retrait boutique  que si le nombre de produits concernés est égal à zéro.

Même si le correcteur de syntaxe intégré à Owebia ne relevait aucune anomalie, ma règle ne fonctionnait pas.

La fonction « debug » du module Owebia m’a permis petit à petit de comprendre ce qui n’allait pas. Le « count result » mettait en lumière l’échec de la règle.

Le mode debug du module owebia visible au niveau du panier en front
Le mode debug du module owebia visible au niveau du panier en front

get id_027.conditions = {count items where product.attribute.etat==’Echange Standard’} > 0
start count items where product.attribute.etat==’Echange Standard’
• item = Mon article 1 (id:11, sku:724930)
replace product.attribute.etat by « 553 » => « 553 »==’Echange Standard’
evaluate « 553 »==’Echange Standard’ = false
» count result = 0
• item = Mon article 2 (id:340, sku:axel-rotot)
replace product.attribute.etat by « 553 » => « 553 »==’Echange Standard’
evaluate « 553 »==’Echange Standard’ = false
» count result = 0
end

Mais en faisant différents tests de valeurs et en essayant avec d’autres attributs, je n’avais pas les même résultats, notamment avec le SKU :

get id_027.conditions = {count items where product.attribute.sku==’axel’} > 0
start count items where product.attribute.sku==’axel’
• item = Mon article 1 (id:11, sku:724930)
replace product.attribute.sku by « 724930 » => « 724930 »==’axel’
evaluate « 724930 »==’axel’ = false
» count result = 0
• item = Mon article 2 (id:340, sku:axel-rotot)
replace product.attribute.sku by « axel » => « axel »==’axel’
evaluate « axel »==’axel’ = true
» count result = 1
end

Je me suis notamment aperçu qu’avec un « attribut système », le test fonctionnait. Mais en regardant le premier rapport (celui dans lequel je teste sur le sku « etat ») ci-dessus, j’ai noté la présence d’une variable « 553 ». J’en ai déduit que le module Owebia remplaçait le nom de l’attribut (etat) par son ID SQL à savoir 553.

Nota : pour précision, mon attribut « etat » semble tout à fait « ordinaire » à savoir : visible en front,  champs liste déroulante, non système, portée globale …

Paramètres de mon attribut "etat" 1
Paramètres de mon attribut « etat » 1
Paramètres de mon attribut "etat" 2
Paramètres de mon attribut « etat » 2

J’ai donc modifié ma règle en précisant que je souhaitais faire mon test sur l’attibut « N° » 553 et là, bingo !

« id_027 »: {
« label »: « boutique »,
« description »: « Retrait boutique »,
« shipto »: « FR,MC,AD »,
« conditions »: « {count items where product.attribute.553==’Echange Standard’} == 0″,
« fees »: 10
},

Le test était concluant et le résultat passait à 2:

get id_027.conditions = {count items where product.attribute.etat==’553‘} > 0
start count items where product.attribute.etat==’553’
• item = Mon article 1(id:11, sku:724930)
replace product.attribute.etat by « 553 » => « 553 »==’553′
evaluate « 553 »==’553′ = true
» count result = 1
• item = Mon article 2  (id:340, sku:axel-rotot)
replace product.attribute.etat by « 553 » => « 553 »==’553′
evaluate « 553 »==’553′ = true
» count result = 2
end

Ce « count result » étant >0, ma méthode « boutique » était bien neutralisée.

En conclusion

Si vous vous trouvez confronté à cette anomalie et pour parvenir à vos fins, vous devrez :

  1. rédiger une première règle afin d’identifier l’ID de votre attribut dans le debugger.
  2. corriger votre règle avec ll’ID de votre attribut.
  3. Effectuer à nouveau le test pour vérifier que votre résultat est le bon.

 

Ajout d’attributs produits dans les emails commande et facture Magento 1.8.1

Dans le cadre de la mise en ligne de produits destinés à la vente en drop-shipping (envoi depuis un autre site logistique ou depuis un fournisseur), je souhaitais ajouter des informations aux emails de confirmation de commande et de facture.

Le but étant de permettre aux opérateurs chargés de traiter les commandes de distinguer facilement les commandes comportant des produits concernés par le drop shipping et ce, afin d’éviter toute erreur de traitement.

J’ai donc décidé d’ajouter un attribut sur les produits concernés et de récupérer la valeur de cet  attribut produit pour l’intégrer aux différents emails transactionnels – confirmation de commande principalement – et de facture.

Voici la méthode que j’ai employée sous Magento 1.8.1. et qui m’a été dictée par http://ka.lpe.sh/2013/01/24/magento-add-additional-product-item-attributes-in-order-and-invoice-emails/

Nota : on ne le dira jamais assez, mais pensez bien à dupliquer les fichiers du /base/default  ainsi que l’arborescence des dossiers dans lequel ils se trouvent dans votre /default/votre thème   , sans quoi, toutes les modifications effectuées ne survivraient pas à une mise à jour de votre magento.

Avant tout, j’ai créé un attribut non visible nommé « dispo » et je lui ai attribué une valeur qui dans mon cas sera toujours la même mais uniquement appliquée sur les produits qui partiront en drop-shipping.

Pensez ensuite à associer cet attribut au jeu d’attributs auquel vos produits sont rattachés.

Concernant la confirmation de commande

Je souhaitais simplement ajouter la valeur de mon attribut …

Attribut sur la fiche produit du back-office Magento
Attribut sur la fiche produit du back-office Magento

en dessous de chaque ligne produit présente dans ma confirmation et obtenir ceci :

Attribut récupéré par la méthode ci-dessous et mis en forme par un span style=
Attribut récupéré par la méthode ci-dessous et mis en forme par un

 

Le contenu de ce mail est généré par le fichier :

\app\design\frontend\base\default\template\email\order\items\order\default.phtml

il suffit d’ajouter ces ligne à la fin de ce fichier pour obtenir le résultat souhaité. Un peu de CSS dan l’ echo permet de mettre en forme à votre goût.

<?php
$productId = $_item->getProduct()->getId();
$product = Mage::getModel('catalog/product')->load($productId);
$attributes = $product->getAttributes();
$dispAttribs = array('dispo');  // on peut étendre le tableau avec d'autres attributs , par exemple array('dispo', 'retour', 'autonomie')
foreach ($attributes as $attribute) {
$attributeCode = $attribute->getAttributeCode();
if(!in_array($attributeCode, $dispAttribs)) continue;
$label = $attribute->getFrontend()->getLabel($product);
$value = $attribute->getFrontend()->getValue($product);
echo '<span style="color:red;font-size:20px;">'. $value .'</span>';
}
?>

 Concernant la modification de l’email de la facture

La démarche est la même 2 différences près :

  • le fichier à modifier est:  \app\design\frontend\base\default\template\email\order\invoice\items.phtml
  • l’appel du produit se fait par –>getProductId() au lieu de ->getProduct()->getId()

<?php
$productId = $_item->getProductId();
$product = Mage::getModel(‘catalog/product’)->load($productId);
$attributes = $product->getAttributes();

$dispAttribs = array(‘dispo’);  // on peut étendre le tableau avec d’autres attributs , par exemple array(‘dispo’, ‘retour’, ‘autonomie’)

foreach ($attributes as $attribute) {
$attributeCode = $attribute->getAttributeCode();
if(!in_array($attributeCode, $dispAttribs)) continue;
$label = $attribute->getFrontend()->getLabel($product);
$value = $attribute->getFrontend()->getValue($product);
echo ‘<span style= »color:red;font-size:20px; »>’. $value .'</span>’;
}
?>

Le résultat obtenu est le suivant :

Ajout attibut produit sur l'email de facture Magento
Ajout attibut produit sur l’email de facture Magento

Pour finir …

Comme indiqué en commentaire dans le code, il est possible de récupérer par la même méthode et d’un seul coup plusieurs attributs en étendant le array à d’autres attributs : (‘dispo’, ‘retour’, ‘autonomie’). Le foreach est déjà en place pour cela dans le code ci-dessus.

Il est également possible de réupérer le nom de l’attribut ($label) et de l’afficher en même temps que la valeur associée ($value) à ce label :

echo « <br /><strong> » . $label . « :</strong>  » . $value;

 

 

 

Uncaught ReferenceError: opConfig is not defined sur Magento 1.8.1

Je me suis récemment un peu embêté sous Magento 1.8.1 avec la mise à jour dynamique des prix pour les produits BUNDLE et CONFIGURABLE qui ne fonctionnait pas. Même problème avec les produits qui disposaient d’options payantes et qui nécessitaient donc une réactualisation du prix produit en fonction des choix du client.

En fonction des options choisies par le client, le prix est normalement sensé se mettre à jour en temps réel
En fonction des options choisies par le client, le prix est normalement sensé se mettre à jour en temps réel

Le prix ne se mettait donc plus à jour en temps réel sur la fiche produit mais en « ajoutant au panier », le prix des options était bien intégré au total facturé.

Pas trop grave d’un point de vue fonctionnel mais pas top en termes de transparence pour le client. CaD que le client ne pouvait voir le prix total de son produit qu’une fois au niveau du panier Magento.

L’erreur se matérialisait par un gros « rien » visuellement parlant mais également par une bonne grosse vieille erreur JS sans la console développeur de Chrome.

erreur js dans google chrome
A chaque changement d’option, le prix ne se met pas à jour et une erreur JS est consignée par le navigateur.

 

Pour ceux qui ne connaissent pas, il faut utiliser la touche F12 pour l’activer. Cette fonctionnalité permet notamment de visualiser la feuille CSS de la page Internet active, de voir son code HTML, de détecter les erreurs telles que JS (javascript) …

Pour activer les outils de développement de Google Chrome, appyer sur F12 ou allez cher la fonctionnalité dans le menu "paramètres" de Chrome.
Pour activer les outils de développement de Google Chrome, appyer sur F12 ou allez cher la fonctionnalité dans le menu « paramètres » de Chrome.

Pour ma part, j’utilise surtout  cet outil pour adapter mes feuilles CSS.

Mais revenons à nos moutons !

Je constate l’erreur mais ne trouve rien sur le web pour m’indiquer une solution. Aucun site français ne traitait de cette erreur JS. Même les sites anglophones ne mentionnait un tel bug sur  Magento sauf … un , trouvé au bout de plusieurs heures de recherche.

La solution n’était pas facile à trouver. En revanche, rien de plus simple pour effectuer la correction : une minable petit e ligne blanche dans un fichier PHTML gérant les options produit qui induisent un changement de prix.

Le chemin du fichier incriminé :  /httpdocs/app/design/frontend/base/default/template/catalog/product/view/options.phtml

Une petite photo de la coupable. des heures de recherche pour une malheureuse ligne vide.
Une petite photo de la coupable. des heures de recherche pour une malheureuse ligne vide.

 

 

 

 

 

Une fois l’erreur corrigée, le bug est résolu.

Nota : au lieu de vous embêter à chercher des résolutions de bug sous Magento, ne faites pas comme moi et si vous le pouvez, mettez votre version de Magento à jour. Pour ce qui me concerne, j’ai trop de vieilles extensions qui tournent sur ma 1.8.1.