Archives pour la catégorie Migrer Magento

Réparer Magento avec Magento-db-repair-tool

voir tutoriel : https://erickranich.wordpress.com/2014/07/03/methode-pour-reparer-une-mise-a-jour-magento-qui-a-plante/#repair

 

 

 

 

 

Publicités

Méthode pour réparer une Mise à jour Magento qui à planté

Lorsque l’on souhaite mettre à jour Magento, nous sommes souvent confronté à quelques difficultés:

Erreur pendant l’update, message d’erreur pendant la ré-indexation, plantage du site, etc … erreur

 Voici la méthode pour s’en sortir :

L’idéal est de partir d’un Magento en état de marche, cette méthode fonctionne aussi avec un Magento planté :

Pre-requis : Avoir accès au serveur via un terminal SSH comme putty et installer l’utilitaire rpl qui permet de faire du « chercher/remplacer » dans les dossiers et fichiers, il est disponible dans  la plupart des distributions linux.

Installation de RPL :

#Sous Debian tapez; apt-get install rpl;
#sous Ubuntu tapez; sudo apt-get install rpl;
#sous Centos tapez; yum install rpl;

1) Créer un dossier un dossier_BIS de votre Magento, je  l’appelerai dossier_BIS 

2) Créer 2 bases vierges  MYSQL via l’outil d’administration serveur (PphpMyAdmin ou plesk ZpanelCP..). Une base que l’on va appeler « final » et une base que l’on va appeler « fraiche« .

Afin de simplifier, si possible, créer ces 2 bases avec le même utilisateur et même mot de passe que votre base Magento originale. (voir app/etc/local.xml).

Dupliquer la base originale de MAGENTO

Vous devez connaitre : username : nom d’utilisateur de la base de données,  password : Mot de passe, dbname : nom de la Base de données, vous pouvez retrouver ces informations dans le fichier local.xml du dossier /MonDossierMagento/app/etc/local.xml

Dans un premier temps on va exporter la base de données de votre Magento original :

mysqldump -u username -ppassword dbname > export.sql

-On  modifie l’export.sql afin que la base « final » pointe vers le  dossier_BIS 

rpl '/MonDossierMagento/' '/dossier_BIS/' export.sql;

MonDossierMagento = le nom du dossier actuel de votre magento, juste le nom du dossier rien d’autre.

(Cela évite de toucher le core_config_data c’est plus efficace)

-On importe le fichier export.sql corrigé vers la base que l’on a appelé  « final »

mysql -h localhost -u username -ppassword final <export.sql

Première étape est terminée, on peut supprimer export.sql

rm export.sql

On va dupliquer le dossier Magento  dans un dossier_bis

cp -R -f /var/www/Le_Chemin_Vers_Dossier/Mon_Magento/ /var/www/Le_Chemin_Verse_Dossier/dossier_bis/;

-On purge les logs/reports/caches…

rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/locks; 
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/cache; 
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/session;

-On vérifie qu’il n’y a plus au fichier qui pointe vers le dossier du Magento original

rpl -R '/MonDossierMagento/' '/dossier_BIS/' /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/;

(Cela évite entre autre de corriger le download/connect.cfg)

Testez-le vous devriez avoir un joli clone de votre Magento  http://votreSite.xx/dossier_bis

Vous avez un Magento identique qui fonctionne mais qui n’est pas encore updaté, on va pouvoir l’upgrader en tout sécurité 🙂

Résumer : vous pouvez en faire un script pour automatiser cette tâche

mysqldump -u username -ppassword dbname > export.sql;
rpl '/MonDossierMagento/' '/dossier_BIS/' export.sql;
mysql -h localhost -u username -ppassword final <export.sql;
rm export.sql;
cp -R -f /var/www/Le_Chemin_Vers_Dossier/Mon_Magento/ /var/www/Le_Chemin_Verse_Dossier/dossier_bis/;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/locks;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/cache;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/session;
rpl -R '/MonDossierMagento/' '/dossier_BIS/' /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/;

____________________________________________________

Maintenant nous allons mettre à jour  en ligne de commande :

1) Accédez au dossier _bis, mettre en mode maintenance puis donner les droits :

cd /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/;
touch maintenance.flag;### mode Maintenance;
chmod -R 777 . ;### tous les droits (pensez a les refermer après)

2)  initialiser magento connect:

rm downloader/connect.cfg  &> /dev/null;
rm -rf var/cache/* downloader/pearlib/cache/* downloader/pearlib/download/* &> /dev/null;
./mage mage-setup;
./mage sync --force;
./mage config-set preferred_state stable ; ## (stable, beta ou alpha);
./mage list-upgrades ;

3) Mise à jour  de Mage_All_Latest :

./mage install http://connect20.magentocommerce.com/community Mage_All_Latest --force ;
rm -rf var/cache/* ;rm downloader/pearlib/cache/*;rm downloader/pearlib/download/* ;
rm maintenance.flag;### fin du mode Maintenance;
chmod -R 777 . ;### tous les droits (pensez a les refermer après)

Testez votre site;  si ça fonctionne il est à jour,  (pensez à vérifier l’indexation) !  s’il ne fonctionne pas continuer ce tutoriel.

Votre site fonctionne mais pas la ré-indexation ? si elle ne fonctionne pas correctement (blocages ou erreurs)  continuer ce tutoriel

4 ) Mise à jour  Complète :

la mise à jour complète est nécessaire si Mage_All_Latest n’a pas réussi à mettre à jour Magento:

cd /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/;
touch maintenance.flag;### mode Maintenance;
chmod -R 777 .; ### tous les droits (pensez a les refermer après)

./mage upgrade-all --force

rm -rf var/cache/* ;rm downloader/pearlib/cache/*;rm downloader/pearlib/download/* ;
rm maintenance.flag;### fin du mode Maintenance;
chmod -R 777 . ;### tous les droits (pensez a les refermer après)

Testez votre site;  si ça fonctionne il est à jour,  (pensez à re-vérifier l’indexation) !  s’il ne fonctionne toujours pas continuer ce tutoriel.

____________________________________________________

Erreur classique « Base table or view exists : 1050 Table .. ‘catolog_product_entity_group_price’ etc..

erreur

Maintenant nous allons nettoyer la base :

un certains nombres de tables n’ont pas supportées la mise à jour, nous allons les supprimer, pour que magento puissent les créer correctement.

Ces tables sont en générale vides, vous pouvez les vérifier avec phpmyadmin

Sauf la table des codes de réductions, vous devrez les re-saisir.

mysql -h localhost -u username -ppassword final -e "SET foreign_key_checks = 0;
update core_resource set version='1.6.0.0.19' where code='catalog_setup';
update core_resource set data_version='1.6.0.0.19' where code='catalog_setup';
update core_resource set version='1.6.0.1' where code='eav_setup';
update core_resource set data_version='1.6.0.1' where code='eav_setup';
update core_resource set version='1.6.0.6' where code='sales_setup';
update core_resource set data_version='1.6.0.6' where code='sales_setup';
update core_resource set version='1.6.0.3' where code='salesrule_setup';
update core_resource set data_version='1.6.0.3' where code='salesrule_setup';
update core_resource set version='1.6.0.0.1' where code='reports_setup';
update core_resource set data_version='1.6.0.0.1' where code='reports_setup';
update core_resource set version='1.6.0.0.1' where code='xmlconnect_setup';
update core_resource set data_version='1.6.0.0.1' where code='reports_setup';
drop table if exists oauth_consumer ;
drop table if exists oauth_token ;
drop table if exists oauth_nonce ;
drop table if exists captcha_log;
drop table if exists api2_acl_role;
drop table if exists api2_acl_user;
drop table if exists api2_acl_rule;
drop table if exists api2_acl_attribute;
drop table if exists salesrule_coupon;
drop table if exists salesrule_website;
drop table if exists report_viewed_product_aggregated_daily;
drop table if exists catalog_product_entity_group_price;
drop table if exists tm_core_module;
drop table if exists turnkeye_testimonial;
";
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/locks;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/cache;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/session;
rm maintenance.flag;### fin du mode Maintenance;

Puis lancer votre site/dossier_bis dans votre navigateur 

 http://votreSite.xx/dossier_bis

ça doit être assez long..  

PS : si vous avez des erreurs APACHE/PHP, c’est que le temps d’attente « Time_out » du serveur est trop court, il faut le rallonger par exemple passer le time_out de 60 à 600 (60 secondes à 10 minutes) voir tutoriel optimiser serveur apache ou serveur ngnix plesk.

Votre Mise à jour est presque terminée, le site fonctionne, mais il manque des tables, la ré-indexation ne peut pas s’exécuter.

____________________________________________________

 Corriger la base de données Magento – Réparer l’indexation avec magento-db-repair-tool

nous allons créer une base de référence « fraiche » , le but est d’avoir une base de données sans défaut correspondant à votre installation.

Notez la clé de votre app/etc/local.xml on va en avoir.

Exemple : <key><![CDATA[60251864b2bb517851cf6d0exemple7f6478b3e]]></key>

On va renommer app/etc/local.xml en app/etc/local.xml-avant et re-vider la cache

Le bu est de créer une base de données de référence que l’on va appeler : fraiche

mv -f /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/app/etc/local.xml /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/app/etc/local.xml-avant;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/locks;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/cache;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/session;

Puis lancer-le  dans votre navigateur vous devriez avoir une jolie install fraîche vers la base  « fraiche »   http://votreSite.xx/dossier_bis

-Suivez les écrans comme si vous faisiez une nouvelle installation : En précisant la nouvelle base de donnée « fraiche »

Testez-le vous devriez avoir un joli Magento  neuf  http://votreSite.xx/dossier_bis nous allons pouvoir réparer la base endommagé.

Remettre le local.xml précédant afin que le site ne pointe plus vers la base de référence « fraiche » mais bien vers la base « final » et re-videz la cache.

mv -f /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/app/etc/local.xml /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/app/etc/local.xml-fraiche;
mv -f /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/app/etc/local-avant.xml /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/app/etc/local.xml;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/locks;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/cache;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/session;

 

Correction de la base de données:

Grace à notre base de référence « fraiche » nous allons pouvoir corriger notre base de données.

1-réparer-la-base

1) Télécharger l’utilitaire :  magento-db-repair-tool sur le site de Magento : http://www.magentocommerce.com/download

2) Décompressez-le et télécharger-le dans le dossier_bis de votre serveur

/var/www/Le_Chemin_De_Votre_Dossier/dossier_bis

3) lancer son exécution dans un navigateur :

http://votreSite.xx/dossier_bis/magento-db-repair-tool-1.1.php

Préciser à gauche la base « final »   et à droite la base de référence « Fraiche »

2-réparer-la-base

il indiquera les corrections qui va apporter

3-réparer-la-base

 

Dans mon cas j’ai du supprimer la table `salesrule_coupon`  cette table n’est pas très importante) c’est la des coupons de réductions (elle sera automatiquement re-créer vide .

Soit vous accédez à la base « final » via PhpMyAdmin et vous supprimez la table, soit en ligne de commande :

mysql -h localhost -u username -ppassword final -e "SET foreign_key_checks = 0; drop table if exists salesrule_coupon;";

Puis relancer   magento-db-repair-tool dans un navigateur :

http://votreSite.xx/dossier_bis/magento-db-repair-tool-1.1.php

Toujour aussi important : vider la cache et lancer la re-indexation 

cd  /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/locks;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/cache;
rm -f -R /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/var/session;
php shell/indexer.php reindexall;

Après cela : la mise a jour est opérationnelle

 

____________________________________________________

 

il est possible de supprimer et d’installer des extensions aussi en ligne de commandes :

Exemple  avec l’extension Magoch__QuickInform

cd /var/www/Le_Chemin_De_Votre_Dossier/dossier_bis/

chmod -R 777 . ;
./mage clear-cache;
./mage mage-setup . 
./mage sync --force 
./mage list-upgrades ;
#installation 
./mage install connect20.magentocommerce.com/community Magoch__QuickInform
#desinstallation
./mage install connect20.magentocommerce.com/community Magoch__QuickInform

 

Solution: impossible de ré-index Magento !

Votre magento ne veut plus re-indexer ! Pas de panique, voici les points à vérifier :

– avez vous purger le dossier locks ?

C’est lui qui peut bloquer la ré-indexation connectez vous a votre serveur avec putty par exemple, acéder au dossier de votre magento, et lancer la commande de re-indexation :

cd /var/www/vhost/VotreSiteWeb/Magento/
rm -R /var/locks

– Les paramètres du serveur sont-ils correct ? En grossissant la base mysql à besoin de ressource,  si les paramètres php sont d’origines : time_out sont à 60 et limit_ memory a 64/128Mo, etc.. il faut les modifier. voir ce tutoriel ►ici◄

PS : »nul besoin de prendre un serveur plus gros, un serveur puissant mal réglé fera la même chose »

– Avez vous essayé en SSH dans un terminal ?

La re-indexation sera plus rapide et s’il y a une erreur vous aurez un message précis. connectez vous a votre serveur avec putty par exemple, acéder au dossier de votre magento, et lancer la commande de re-indexation :

cd /var/www/vhost/VotreSiteWeb/Magento/
rm -R /var/locks; rm -R /var/cache;
php shell/indexer.php reindexall;

Si des messages d’erreurs apparaissent :

Exemple : exception ‘PDOException’ with message ‘SQLSTATE[21S01]: Insert value list does not match column list: 1136 Column count doesn’t match value count at row 1’ 

C’est que la base de données à subit des dommages il va falloir la réparer: il faut utiliser Magento-db-repair-tool-1.1

– voir tutoriel réparer magento avec Magento-db-repair-tool

Correction : Bug Magento 1.8 « Memory limit has been reached »

Untitled

Après une mise à jour vers Magento 1.8 je n’avais plus aucune image de mes produits,   même problème  avec un Magento 1.8 tout neuf avec une base vierge.

impossible d’insérer une image,  message d’erreur : « Memory limit has been reached »

Après pas mal de recherche ±2 jours de perdu (Merci Magento), je me suis rendu compte qu’ils ont ajouté dans Magento 1.8 un test de memory_limit de php dans  /magento/lib/varien/image/Adpater/Gd2.php

/**
 * Converts memory value (e.g. 64M, 129KB) to bytes.
 * Case insensitive value might be used.
 *
 * @param string $memoryValue
 * @return int
 */
 protected function _convertToByte($memoryValue)
 {
 if (stripos($memoryValue, 'M') !== false) {
 return (int)$memoryValue * 1024 * 1024;
 } elseif (stripos($memoryValue, 'KB') !== false) {
 return (int)$memoryValue * 1024;
 }
 return (int)$memoryValue;

Problème, ce test est incomplet il ne prend pas en compte les paramétrages en Go « G »  ou en illimité -1  

Il génère donc une fausse erreur  [un bug].

_______________________________________________

SOLUTIONS

 Modifier les paramètres de serveur php :

Ne pas utiliser de fonction illimité (-1)  ou convertir les (Go) G en M (Mo) dans le fichier php.ini

l’emplacement varie selon les installations /etc/php5/apache2/php.ini

  • si la valeur memory_limit = 2G remplacé par 2048M

memory_limit = 2048M

  • si la valeur est memory_limit = -1  changez pour   par exemple 128M
  • Redémarrer le service ou le serveur pour que ce soit pris en compte.
service apache2 stop service apache2 start
  • Enfin videz la cache de Magento
rm /magento/var/session; rm /magento/var/cache;

Bizarrement ça ne sert a rien de le faire dans le fichier .htaccess

_______________________________________________

Si vous utilisez une interface PLESK  

  • Abonnement ► Gérer l’hébergement ► Général Personnaliser ► Paramètre PHP
  • memory_limit   ► Entrer une valeur personnalisé saisissez  128M 
  • NE LAISSEZ PAS ILLIMITE ou PAS DE VALEUR EN G (GO)
  • Redémarrer le service ou le serveur pour que ce soit pris en compte.
service apache2 stop service apache2 start
  • Enfin videz la cache de Magento
rm /magento/var/session; rm /magento/var/cache;

plesk-limit

_______________________________________________

Pour tester votre php  créez un fichier test.php  dans votre dossier magento, puis lancer le de votre navigateur :

test.php   contenant :

<?php
  1. // Affiche toutes les informations, comme le ferait INFO_ALL
  2. phpinfo();
  3. // Affiche uniquement le module d’information.
  4. // phpinfo(8) fournirait les mêmes informations.
  5. phpinfo(INFO_MODULES);
  6. ?>

re-indexer Magento en ligne de commande

 

Avec un terminal ou putty par exemple acceder a votre dossier magento

et tapez :

php shell/indexer.php reindexall

 

si des erreurs apparaissent, c’est très souvent le serveur qui  n’est pas paramétré correctement.

Exemple d’erreur :  

‘safe_mode’ is deprecated in PHP 5.3 and greater in Unknown on line 0 ou 1

editer php.ini pour mettre Safe_Mode = Off   

puis Redemarrer le service apache2

service apache2 stop;

service apache2 start;

Exemple d’erreur :  

exceptionPDOException‘ with message ‘SQLSTATE[08S01]: Communication link failure: 1153 Got a packet bigger than ‘max_allowed_packet‘ bytes’ in /var/www/vhosts/votresite/httpdocs/shop/lib/Zend/Db/Statement/Pdo.php:228

 

Modifier la configuration du Mysql et redemarrer le Serveur complet.

dans /etc/my.cnf

Augmenter le max_allowed_packet   16M  passer le 32M ou 48M  selon les cas

plus d’info voir :  https://erickranich.wordpress.com/2013/11/26/exemple-de-my-cnf-pour-magento-1-6-1-7-1-8/

 

 

 

 

 

 

 

 

bug 1.6.1 Magento changement URL..

J’ai installé une copie de Magento 1.6.1.0 sur un site dev-je configurer pour faire quelques tests. Cependant, dans l’obligation d’être en mesure d’arriver à Magento en utilisant 2 URL différente, je suis tombé sur ce bug assez ennuyeux.

a:5:{i:0;s:67:"Illegal scheme supplied, only alphanumeric characters are permitted";i:1;s:729:"#0 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Model/Store.php(712): Zend_Uri::factory('{{base_url}}') #1 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Controller/Varien/Front.php(313): Mage_Core_Model_Store->isCurrentlySecure() #2 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Controller/Varien/Front.php(161): Mage_Core_Controller_Varien_Front->_checkBaseUrl(Object(Mage_Core_Controller_Request_Http)) #3 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Model/App.php(349): Mage_Core_Controller_Varien_Front->dispatch() #4 /home/dan/workspace/magento1610/app/Mage.php(640): Mage_Core_Model_App->run(Array) #5 /home/dan/workspace/magento1610/index.php(80): Mage::run('', 'store') #6 {main}";s:3:"url";s:85:"/index.php/admin/system_config/edit/section/web/key/41c8c3d3f4bcb72e3c267ae0b73333d7/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}

plus d’info ttp://www.danneh.org/2011/11/bug-magento-1-6-1-0-affecting-development-sites-base_url/

Merci à Denneh.org pour ça petite correction en attendant la version 1.7.

BTS_1610Fix.tar.gz