Parfois la réindexation des index de Magento est bloquée en admin.

Le message “En cours de traitement” peut rester affiché et il est impossible de relancer ou même stopper la réindexation.

Pour régler ce problème il suffit de se connecter en ssh, de se placer dans le répertoire de Magento et de lancer la commande suivante qui réindexe tout :

php shell/indexer.php reindexall

On peut également réindexer un index spécifique grâce aux commandes suivantes :

Attributs de produit :

php shell/indexer.php --reindex catalog_product_attribute

Prix du produit :

php shell/indexer.php --reindex catalog_product_price

Réécriture d’URL du catalogue

php shell/indexer.php --reindex catalog_url

Données fixes de produit :

php shell/indexer.php --reindex catalog_product_flat

Données fixes de catégorie :

php shell/indexer.php --reindex catalog_category_flat

Produits de la catégorie :

php shell/indexer.php --reindex catalog_category_product

Index de recherche catalogue :

php shell/indexer.php --reindex catalogsearch_fulltext

État du stock, Données d’aggrégation de mot clé :

php shell/indexer.php --reindex cataloginventory_stock

Si vous rencontrez l’erreur suivante “Sh/bin bad interpreter: No such file or directory” à l’exécution d’un script shell, c’est que le fichier est au format DOS au lieu du format UNIX.

Grâce à la commande od, qui permet de faire un dump au format octal, vous pouvez connaitre le format d’un fichier. Pour cela, il suffit d’exécuter la commande suivante :

head -1 monfichier.sh | od -c

Si en retour, en fin de ligne vous voyez \r  \n c’est que votre fichier est au format DOS. Pour un fichier au format UNIX \r n’apparait pas.

Pour le convertir vous pouvez utiliser la commande dos2unix :

dos2unix mon-fichier

On peut également convertir un fichier directement depuis l’éditeur vim, grâce à la commande suivante :

:set ff=unix

Il peut être intéressant de modifier l’emplacement par défaut du répertoire contenant les bases de données et tables MySQL. Cela peut-être pour faciliter des sauvegardes ou encore bénéficier d’un espace disque plus important. La procédure est plutôt simple et rapide. Nous allons utiliser les liens symboliques. Dans cet exemple, le nouvelle emplacement du répertoire sera /home/mysql/ Voici la liste des commandes à exécuter :

/etc/init.d/mysql stop

mv /var/lib/mysql /home/

ln -s /home/mysql/ /var/lib/mysql

chown mysql:mysql /home/mysql

chmod 777 /home/mysql

/etc/init.d/mysql start

Pour plus de logique , on peut également modifier le fichier de configuration de MySQL, même si, grâce aux liens symboliques, cela n’est pas nécessaire. Dans /etc/mysql/my.cnf :

[mysqld]

datadir = /home/mysql

Lors de la construction de la requête l’adresse IP du client est envoyé. Pour les personnes derrière un Proxy l’IP généré via HTTP_X_FORWARDED_FOR est de type “XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX” (IP du client et du Proxy) et non “XXX.XXX.XXX.XXX”. Cela entraîne un plantage du module lors de la redirection (page blanche).

Le patch suivant filtre les IP récupérées par la méthode Mage_Atos_Model_Api_Paramaters::getIpAddress et récupére uniquement la seconde quand une liste est fournie.

proxy.patch.txt

Pour l’utiliser, il faut le copier sur le serveur, le renommer en proxy.patch.
Puis à la racine de magento, exécuter : 
patch -p0 < /cheminverslefichier/proxy.patch
Enfin, ne pas oublier de vider le cache Magento.

Contenu du fichier :

Index: app/code/local/Mage/Atos/Model/Api/Parameters.php

===================================================================

--- app/code/local/Mage/Atos/Model/Api/Parameters.php   (revision 1644)

+++ app/code/local/Mage/Atos/Model/Api/Parameters.php   (working copy)

@@ -138,6 +135,30 @@

             }

         }



+        # Determine originating IP address. REMOTE_ADDR is the standard

+        # but will fail if the user is behind a proxy. HTTP_CLIENT_IP and/or

+        # HTTP_X_FORWARDED_FOR are set by proxies so check for these before

+        # falling back to REMOTE_ADDR. HTTP_X_FORWARDED_FOR may be a comma-

+        # delimited list in the case of multiple chained proxies; the first is

+        # the originating IP.

+        #

+        # Security note: do not use if IP spoofing is a concern for your

+        # application. Since remote_ip checks HTTP headers for addresses forwarded

+        # by proxies, the client may send any IP. remote_addr can't be spoofed but

+        # also doesn't work behind a proxy, since it's always the proxy's IP.

+        # @see http://metautonomo.us/2008/05/30/the-local_request-that-isnt/

+        $reg_priv_network = '/^unknown$|^(10|172\.(1[6-9]|2[0-9]|30|31)|192\.168)\./i';

+        if ( strpos($ip, ',') !== false ) {

+            $_ips = explode(',', $ip);

+

+            foreach ( $_ips as $_ip ) {

+                $_ip = trim($_ip);

+                if ( !preg_match($reg_priv_network, $_ip, $matches ) ) {

+                    return $_ip;

+                }

+            }

+        }

+

         return $ip;

 }

Grâce à find et l’option -ctime :
-ctime n : derniere modification du statut du fichier il y a n*24 heures.

Exemples :

Supprimer les fichiers modifiés il y a plus de 24 heures.

find . -ctime +1 -exec rm -f  \{\} \;

Supprimer les fichiers modifiés il y a plus de 10 jours.

find . -ctime +10 -exec rm -f  \{\} \;

Il existe 3 solutions disponibles au sein de l’admin mais je ne parlerai ici que de la solution de restauration en ligne de commande grâce à la commande BackupPC_tarCreate

Se connecter avec l’utilisateur backuppc :

su backuppc

Puis lancer la commande BackupPC_tarCreate

Extrait de la doc officielle :

  BackupPC_tarCreate [options] files/directories...
    Required options:
       -h host         host from which the tar archive is created
       -n dumpNum      dump number from which the tar archive is created
                       A negative number means relative to the end (eg -1
                       means the most recent dump, -2 2nd most recent etc).
       -s shareName    share name from which the tar archive is created
  
    Other options:
       -t              print summary totals
       -r pathRemove   path prefix that will be replaced with pathAdd
       -p pathAdd      new path prefix
       -b BLOCKS       BLOCKS x 512 bytes per record (default 20; same as tar)
       -w writeBufSz   write buffer size (default 1048576 = 1MB)
       -e charset      charset for encoding file names (default: value of
                       $Conf{ClientCharset} when backup was done)
       -l              just print a file listing; don't generate an archive
       -L              just print a detailed file listing; don't generate an archive

Exemple

/usr/share/backuppc/bin/BackupPC_tarCreate -t -n 252  -h host -s /dossier/ShareName sousrepertoire > restore.tar

Ou 252 est un numéro de sauvegarde et host un nom d’hôte sauvegardé

GWS (Global Website Store) est le nom donné par l’éditeur Varien à son système hiérarchique de gestion des données (produits, clients, configurations…) sur différents niveaux.

En résumé :

• Global : fait référence à l’instance Magento dans sa globalité (une installation Magento).
• Website : Les Websites (sites web) sont les “parents” des Stores (magasins). Un site web contient un ou plusieurs magasin(s). Les sites web peuvent être paramétrés pour partager les données client, ou ne partager aucune donnée.
• Store : les stores (magasins) sont les enfants des sites web. Chaque magasin est caractérisé par une catégorie racine, ce qui permet, au sein du même site web, d’avoir plusieurs magasins ayant des structures de catalogues complètement différentes.
• Store View : un magasin a besoin d’un ou plusieurs store views (vues magasin) afin d’être “navigable” en front office. La structure d’un catalogue, d’une vue d’un magasin à une autre du même magasin, sera toujours la même. Cela permet simplement d’avoir des présentations des données différentes. 90% du temps, les vues magasins sont utilisées pour gérer le passage d’une langue à une autre.

On retrouve GWS dans la gestion de la majeure partie des données des produits, catégories, CMS et configuration. A l’installation d’un projet, toutes les données font référence à une valeur par défaut commune à tous les niveaux hiérarchiques. Mais il est possible de rendre ces valeurs spécifiques à un web site ou store view.

Ainsi il existe 3 portées distinctes :

• [GLOBAL] signifie que la valeur du champ sera systématiquement commune à tous les sites web, magasins, vues magasin.

• [WEBSITE] signifie que la valeur d’un champ peut varier d’un site web à l’autre. En revanche il faut bien comprendre que cette portée signifie qu’au sein d’un même site web, tous les magasins ou vues magasin auront une valeur commune: celle définie au niveau du site web parent.

• [STORE VIEW] signifie que la donnée peut avoir des valeurs différentes d’une vue magasin à l’autre.

Ci-dessous, un tableau récapitulatif donnant un aperçu de la portée de quelques données importantes. Il est loin d’être complet mais pourra s’avérer être une aide non négligeable.

Source : http://www.bysoft.fr/blog/internet/instances-sites-web-magasins-vues-magasin-les-cles-de-la-decision-pour-definir-la-structure-d%E2%80%99un-projet-magento/190

Grâce à ntpdate

/usr/sbin/ntpdate cdns.ovh.net

Automatiser la mise à jour

Exemple, une fois par jour à 4h00

0 4 * * * root /usr/sbin/ntpdate cdns.ovh.net >/dev/null

Ajouter une tâche cron :

crontab -e

Créer une tâche exécutée à nH30 toute les 8h (0h30,8h30,16h30) :

30 */8 * * * mysqlcheck -Aao --auto-repair -u monlogin -pmonmotdepasse | grep OK > /var/log/mysqlcheck.log