Plusieurs problèmes sont connus sur la version 1.3.2.4 de Magento.

Le premier de ces bugs est dû au compilateur (intégré à Magento) en version beta activé par défaut. Ce bug est visible dans "System > Magentoc Connect > Magento Connect Manager" ou "System > Magento Connect > Package Extensions"

Fatal error: main() [function.require]: Failed opening required '/data/www/html/magedemo/includes/downloader/pearlib/php/PEAR.php' (include_path="/data/www/html/magedemo/includes/downloader/pearlib/php : /data/www/html/magedemo/includes/src:.:/usr/local/lib/php") in /data/www/html/magedemo/includes/src/Varien/Pear.php on line 265

Pour résoudre ce problème, il suffit de désactiver le Compilateur dans Système > Outils > Compilation.

Le second bug rencontré est un bug d'affichage du javascript aussi bien dans le back-office que sur le front-office. Dans certains cas, tout le JavaScript (menu déroulant, ...) ne s'affiche pas.

Pour résoudre ce problème il faut modifier le fichier app/code/core/Mage/Page/Block/Html/Head.php .

Voici une version patchée : http://blog.stockho.com/public/Head.php.new

Voici le fichier original pour information : http://blog.stockho.com/public/Head.php.old

Il est essentiel, pour se prémunir des attaques, bugs, et pour profiter des améliorations en tous genres, de tenir sa version Magento à jour. D'autant plus qu'il sera beaucoup plus difficile – voire impossible – de sauter d'une version à une autre, sans passer par toutes les versions intermédiaires qui seraient sorties entre temps.

Mettre à jour Magento peut s'avérer risqué, c'est pourquoi il faut se préparer au pire :

• on sauvegarde la base de données :

  mysqldump -u utilisateur -p"mot_de_passe" nom_de_la_base > sauvegarde_datée.sql

• on sauvegarde l'intégralité du dossier racine de magento.

Ensuite, on se rend dans le dossier de Magento et, en utilisateur root :

./pear mage-setup . (si la permission est rejetée : chmod 755 pear)
./pear install -f magento-core/Mage_All_Latest-stable
rm -rf racine_magento/var/cache/*
rm -rf racine_magento/var/session/*

Il faudra ensuite penser à recréer le cache à partir de l'interface d'administration et régler les éventuelles nouvelles options de configuration.

Magento sauvegarde dans sa base de données les informations relatives aux accès au site par les visiteurs.

Dans sa table de log, on trouve les champs log_url, log_url_info, log_visitor et log_visitor_info. Cette table peut grossir considérablement avec le temps, particulièrement sur un site à fort trafic, et affecter les performances du serveur hébergé. Par défaut, l'épuration de cette table n'est pas activée.

Pour l'activer et rélger les différentes options relatives au système de log, il convient de se rendre dans l'interface d'administration, menu Système -> Configuration, puis Système sur la gauche, puis dans l'onglet relatif aux logs.

Il peut être utile de stocker les sessions non plus sur le filesystem, ni même en RAM (cf ce billet), mais directement en base de données. Cela sera particulièrement utile dans le cas d'un environnement hébergé de cluster de base de données (cf ce billet) avec replication et load balancer, afin d'éviter des conflits de sessions entre les différents front offices...

Avec Magento, rien de plus simple : rendez-vous dans le fichier racine_magento/app/etc/local.xml, et changez la ligne
<session_save><![CDATA[files]]></session_save>
en
<session_save><![CDATA[db]]></session_save>

Et voilà.

Il est extrêmement fréquent -pour ne par dire constant- pour un serveur d'être la cible de scans par des scripts qui balayent de larges plages d'IP et qui testent les URLs d'administration communes telles que http://www.site.com/phpmyadmin ou encore http://www.site.com/admin.

Afin de protéger sa plateforme Magento contre une éventuelle faille favorisée par l'utilisation d'une URL d'administration trop évidente, il est donc conseillé de la changer en quelque chose de plus original.

Cela peut être fait à l'installation, ou plus tard dans le fichier racine_magento/app/etc/local.xml :

• à l'installation, il suffit de changer le chemin d'administration par défaut ("admin") en quelque chose qui répond à la syntaxe d'une URL.
• dans le fichier local.xml, changer la ligne <![CDATA[admin]]></frontName> en <frontName><![CDATA[nouveau_nom]]>.

Ne pas oublier de supprimer le cache (rm -rf racine_magento/var/cache/*), puis de le recréer via la nouvelle URL de l'interface d'administration.

Il peut arriver, par une erreur de manipulation, d'endommager gravement sa base de données. Heureusement, Varien -l'éditeur à l'origine de Magento- a prévu un système de réparation très poussé.

Allant jusqu'à recréer des tables manquantes, des champs, des indexes... ce script php suppose d'avoir conservé une version saine de sa base de données. Il permet de pointer la base saine et la base endommagée, de les comparer, et de faire les réparations qui s'imposent.

Imaginons un instant que l'administrateur de la plateforme hébergée ait procédé à l'ajout d'un millier de produits, avec les références, les tags, les prix, les descriptions... et que par mégarde il ait supprimé une table. Au lieu de reprendre une version antérieure de la base, et de perdre tout son travail, il lui suffira de réparer la base à l'aide de la structure de la base saine et ce, en quelques secondes.

Voici le lien vers le script, ainsi que la procédure d'utilisation. Ne pas oublier de déplacer/supprimer le script par la suite.

Afin de protéger l'envoi d'informations sur les pages clients et les pages liées au paiement de votre plateforme hébergée, il est essentiel d'utiliser le chiffrement des données par SSL. Ces certificats sont délivrés par de nombreux organismes, à tous les prix et, pour un site Magento, à peu près n'importe quel certificat fait l'affaire.

 

Pour le module de paiement, il faut nécessairement passer par celui de sa banque, à moins d'avoir la certification PCI-DSS, très coûteuse et difficile à obtenir.

Il peut arriver de perdre son mot de passe d'administrateur Magento, de l'oublier, ou de se resservir d'une ancienne sauvegarde de la base de données dont le mot de passe a été perdu depuis.

Il est heureusement possible de le changer manuellement, en passant directement pas la base de données (manipulation également possible par phpMyAdmin, si vous n'avez pas l'accès ssh sur le serveur hébergeant votre site…).

On se connecte donc à MySQL, puis :

mysql > use nom_de_la_bdd;
mysql > SELECT * FROM `admin_user`;

On trouve dans le résultat de cette commande le nom de l'administrateur dont on veut modifier le mot de passe, puis :

mysql > UPDATE `admin_user` SET `password` = MD5('nouveau_mot_de_passe') WHERE `username` = 'nom _administrateur';

Si, pour une raison ou pour une autre, il n'était pas possible d'installer une extension via Magento-Connect par le backoffice de votre site hébergé, voici comment le faire par SSH :

cd [racine_magento]
./pear mage-setup
./pear -V
./pear list-channels
./pear install connect.magentocommerce.com/community/nom_de_l'extension
(pour trouver le nom de l'extension, cliquer sur le bouton « Get extension key » sur la page de l'extension, et récupérer la fin de l'URL)

Penser ensuite à faire un chown -R user:group * sur le dossier racine de Magento (remplacer user et group par le nom d'utilisateur d'Apache et son groupe, ex : www-data:www-data sur Debian).

La facilité de création et d'installation des extensions est une des grandes forces de Magento. Virtuellement, s'il existe un vide laissé par l'absence d'une feature, une extension existe -ou existera- pour le combler. Pour s'en rendre compte, il suffit d'observer la croissance du site magento-connect.

Malheureusement, des petits malins semblent profiter de l'effervescence liée à cette croissance impressionnante. En navigant sur le forum du site officiel, il m'est arrivé de tomber, ici et là, sur des posts concernant diverses prétendues extensions qui -en réalité- n'existent même pas. Cela va sans dire : elles sont payantes.

La prudence est donc de mise lors de tout achat d'une extension pour votre site hébergé. Je ne saurais que conseiller de lire avec attention le forum correspondant à l'extension en question, et de se méfier si jamais ce forum s'avérait être vierge de tout commentaire.