Comment puis-je déboguer mon magasin Magento

C’est une question qui ne nous concerne plus beaucoup à présent, mais si un site Magento SE avait existé il ya 5 ans, c’était probablement notre première question. Pour ceux qui débutent dans Magento ou ne le connaissent pas - connaître les bases du débogage peut être un élément clé pour éliminer la cause des problèmes. Et malgré son manque de pertinence pour nous maintenant, nous anticipons cette question en apparaissant avec une approche à réponse automatique.

Aide mon site est en panne!

1. Ma conception est-elle en cause?
2. Un module tiers est-il en cause?
3. Pourquoi je ne vois pas l'erreur?

Il est facile de répondre à chacune de ces questions en suivant une approche normalisée de débogage que même les utilisateurs les plus élémentaires peuvent résoudre. Au moyen d’un processus d’élimination des bases du débogage d’un magasin Magento.

Le débogage est un art, mais vous pouvez facilement le maîtriser en suivant un schéma simple.

Suivez chaque point jusqu'à ce que vous arriviez enfin à une solution.

Activer les erreurs PHP

C'est la clé de la plupart des problèmes. Pour des raisons de sécurité ou pour d’autres raisons, l’affichage des erreurs PHP pourrait probablement être désactivé par défaut avec votre configuration PHP.

Vous pouvez activer les erreurs avec une solution plus permanente ou simplement quelque chose de plus temporaire.

Solution permanente

Pour les utilisateurs d'Apache / mod_php

Dans le .htaccessfichier racine de votre document - il suffit de déposer ceci en haut.

php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag  log_errors on
php_value error_log  /home/path/public_html/var/log/system.log

Pour les utilisateurs de Nginx / FastCGI

Dans votre configuration virtualhost Nginx, dans la location .php {directive finale ou dans le fastcgi_paramsfichier (si vous en avez spécifié un)

fastcgi_param PHP_VALUE  display_startup_errors=on;
fastcgi_param PHP_VALUE  display_errors=on;
fastcgi_param PHP_VALUE  html_errors=on;
fastcgi_param PHP_VALUE  log_errors=on;
fastcgi_param PHP_VALUE  error_log=/home/path/public_html/var/log/system.log;

Solution temporaire / universelle

Pour toute plate-forme

Editez le bootstrap Magento index.phpdans la racine de votre document et décommentez la ligne suivante:

#ini_set('display_errors', 1);

Activer le mode développeur

Lorsque vous avez eu une erreur et que vous avez soudainement frappé la page "Rapport d'erreur", une chaîne d'erreur apparemment inutile 1184257287824vous a été donnée - vous avez plusieurs options.

Solution permanente

Pour les utilisateurs d'Apache / mod_php

Dans votre .htaccessfichier racine de document - il suffit de déposer ceci en haut.

SetEnv MAGE_IS_DEVELOPER_MODE true

Pour les utilisateurs de Nginx / fastcgi

Dans votre configuration virtualhost Nginx, dans la location .php {directive finale ou dans le fastcgi_paramsfichier (si vous en avez spécifié un)

fastcgi_param MAGE_IS_DEVELOPER_MODE true;

Solution temporaire / universelle

Editez le bootstrap Magento index.phpdans la racine de votre document et faites en sorte que la ifdéclaration soit toujours vraie ou soit activée pour votre adresse IP spécifique.

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
  Mage::setIsDeveloperMode(true);
}

ou

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
  Mage::setIsDeveloperMode(true);
}

Vérifiez vos autorisations

Des autorisations incorrectes entraîneront une multitude de problèmes, dont beaucoup ne sont pas faciles à trouver au premier abord.

Par exemple.
Si PHP ne peut pas écrire dans le ./mediarépertoire et que la combinaison JS est activée, Magento ne peut pas générer le fichier combiné et l'URI unique associé au support. Au lieu de cela, vous trouverez dans le code source de votre navigateur un chemin d'accès complet au fichier multimédia. /home/path/public_html/media/xxx

Sinon, le site peut sembler fonctionner normalement - sans erreur critique réellement visible.

N'oubliez pas que cette pratique est sécurisée pour l'hébergement dédié, mais qu'elle peut poser des problèmes de sécurité avec l'hébergement partagé si le processus Apache n'est pas modifié par utilisateur.

Dans notre exemple, l’utilisateur SSH / FTP est sonassi, l’utilisateur Apache est apacheet le groupe estapache

Ajouter l'utilisateur FTP / SSH au groupe Apache

Plus important encore, nous devons nous assurer que l’utilisateur FTP / SSH fait partie du groupe Apache. Dans notre exemple, c’est apache(mais c’est aussi couramment www-data)

usermod -a -G apache sonassi

Continuez à ajouter autant d'utilisateurs au groupe que vous avez pour FTP / SSH.

Réinitialiser les autorisations d'origine

Donc, avant de commencer, vérifions que toutes les autorisations sont correctes.

chown -R sonassi:apache /home/path/public_html/
find /home/path/public_html/ -type d -exec chmod 775 {} \;
find /home/path/public_html/ -type f -exec chmod 664 {} \;

Rendre les changements permanents

ACL et Sticky Bits

Les listes de contrôle d'accès sous Linux nous permettent de définir des règles spécifiques, dans notre cas, les fichiers d'autorisations qui doivent hériter à la création. Un sticky bit (mentionné plus tard) prend en charge l'héritage de groupe, mais n'aide pas avec les autorisations, c'est pourquoi nous utilisons des ACL.

Commencez par activer le support ACL sur la partition active, assurez-vous que votre noyau a été compilé avec le support ACL .

Votre partition peut être /, /home, /varou quelque chose d' autre, remplacer le cas échéant.

mount -o remount,acl /home

Maintenant que les listes de contrôle d'accès sont activées, nous pouvons définir les règles de la liste de contrôle d'accès et regrouper les sticky bits:

setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/

Mais je n'ai pas de support ACL

Si votre noyau ne prend pas en charge les listes de contrôle d'accès, vous pouvez également utiliser umask(ce qui correspond à un paramètre d'exécution pour BASH, FTP et PHP) pour définir les autorisations de fichier par défaut. Magento met généralement umask(0)en index.php, cependant, il serait dans votre intérêt de changer cela.

Dans votre index.phpchangement la umaskligne à être

umask(022);

Et dans votre environnement BASH pour SSH, définissez-le dans votre .bashrcou.bash_profile

umask 022

Pour votre serveur FTP, vous devrez lire la documentation correspondante, mais le principe est le même.

Rétablir le thème par défaut

Il est possible que votre thème ou votre package soit responsable de ce problème. Revenir à un thème vanillé de Magento est un moyen rapide de le découvrir.

** Cela vient avec la mise en garde que certains modules peuvent dépendre de certaines fonctionnalités de thème *

Plutôt que de changer quoi que ce soit via le panneau d'administration, il est beaucoup plus simple de simplement renommer les répertoires incriminés.

Via SSH

mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}

Ou via votre client FTP, traversez et renommez votre paquet en quelque chose d'autre. par exemple.myBrokenTheme.tmp

Si cela résout votre problème

Ensuite, vous devez approfondir un peu la question de savoir quelle partie du modèle pose problème. Donc, restaurez votre paquet et essayez ce qui suit, en testant entre chacun.

Le processus consiste essentiellement à activer progressivement les répertoires au fur et à mesure que vous parcourez l’arborescence de fichiers - jusqu’à ce que vous puissiez trouver le fichier incriminé.

1. Renommez le répertoire de disposition en .tmp
2. Renommez le répertoire du modèle en .tmp

Ensuite, si l'un des correctifs est corrigé, renommez tous les fichiers du répertoire de présentation en .tmp- (pour les utilisateurs SSH ls | xargs -I {} mv {} {}.tmpou rename 's/^/.tmp/' *)

Ensuite, activez progressivement chaque fichier 1 par 1 jusqu'à ce qu'il soit résolu.

Si cela ne résout pas votre problème

Il est possible que votre base/defaultou vos enterprise/defaultannuaires soient contaminés et qu’ils soient remplacés par une version propre connue.

Vous pouvez le faire en téléchargeant une version propre de Magento et en remplaçant vos répertoires si nécessaire. Via SSH, vous pouvez faire ceci:

cd /home/path/public_html/
mkdir clean_mage
cd clean_mage
MAGENTO_VERSION=1.7.0.0
wget -O magento.tgz  http://www.magentocommerce.com/downloads/assets/$MAGENTO_VERSION/magento-$MAGENTO_VERSION.tar.gz
tar xvfz magento.tgz
cd /home/path/public_html/app/design/frontend
mv base{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/design/frontend/base .
cd /home/path/public_html/skin/frontend
mv base{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/skin/frontend/base .

Vous pouvez également profiter des diffdeux répertoires si vous souhaitez vérifier les modifications.

diff -r base base.tmp

NB Cette méthode entraînera davantage d'erreurs au cours du processus, car la dépendance du module dicte l'existence de fichiers spécifiques. Malheureusement, c'est la normale pour le cours.

Désactiver les modules locaux

Par défaut, Magento définit le chemin d’inclusion PHP pour charger les classes dans l’ordre suivant

Local > Community > Core

Si un fichier est en local, chargez-le et n'en faites plus.
Si un fichier est en communauté, chargez-le et n'en faites plus.
Si un fichier ne peut être trouvé nulle part ailleurs, chargez-le à partir du noyau.

Encore une fois, plutôt que de désactiver les modules via le panneau d’administration de Magento, il est plus pratique de le faire au niveau du fichier.

Généralement, pour désactiver un module de la manière "appropriée", vous devez éditer le ./app/etc/modules/MyModule.xmlfichier et le fichier respectifs <active>false</active>. Toutefois, cela n’empêche pas le chargement d’une classe.

Si une autre classe étend une classe donnée dans un module (en ignorant les déclarations de dépendance Magento), elle sera toujours chargée, que l'extension soit désactivée ou non.

Encore une fois, le meilleur moyen de désactiver une extension est de renommer le répertoire.

Commencez par désactiver le local

Renommez simplement le répertoire via FTP ou utilisez la commande SSH suivante

mv ./app/code/local{,.tmp}

Puis désactiver la communauté

mv ./app/code/community{,.tmp}

Si le problème est résolu depuis

Il s’agit ensuite de comprendre de quel module en particulier l’erreur provient. Comme avec l'exemple donné ci-dessus pour le diagnostic du colis, le même processus s'applique.

Donc, restaurez le répertoire X et essayez ce qui suit en testant entre eux.

Essentiellement, le processus consiste à activer progressivement les répertoires (modules) un par un jusqu'à ce que l'erreur se reproduise.

1. Renommez tous les modules du répertoire en .tmp(pour les utilisateurs SSH ls | xargs -I {} mv {} {}.tmpou rename 's/^/.tmp/' *)
2. Activer progressivement chaque module un par un en supprimant .tmple nom du fichier

Si le problème n'est pas résolu

Il est alors possible que le noyau lui-même soit contaminé. Le noyau principal de Magento PHP est composé de

./app/code/core
./lib

Encore une fois, renommez ces répertoires et copiez-les dans une variante propre. En supposant que vous ayez déjà téléchargé une version propre de Magento comme ci-dessus, via SSH, vous pouvez le faire:

cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .

Ensuite, si le problème persiste, remplacez également le librépertoire.

cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .

À ce stade, votre boutique Magento ne sera plus qu'une installation vanille avec une base de données modifiée.

En fait, certains modèles sont toujours stockés dans la base de données (par exemple, incrément de commande). À ce stade, il devient alors nécessaire d’effectuer ces modifications manuellement. Jusqu'à présent, toutes les étapes ci-dessus ont été réversibles sans dommages durables. Mais si nous importions également une base de données propre Magento, elle pourrait être irréversible (à moins de restaurer une sauvegarde).

Le guide ci-dessus vous aide à identifier une erreur; ne pas réparer l'erreur qui en résulte.

^{Le contenu provient volontairement de www.sonassi.com/knowledge-base/magento-debug-process et www.sonassi.com/knowledge-base/stop-magento-permissions-errors- de manière permanente.}

Comme demandé sur Twitter et discuté sur Meta, je vais commencer ici un tutoriel de débogage pour les non-développeurs.

Premièrement, je pense (même si Magento essaie de s’engager dans cette voie), Magento est trop complexe pour un commerçant sans développeur / équipe de développement. Mais si vous êtes courageux et que vous voulez l'essayer, nous faisons de notre mieux pour vous aider. Je pense que pour certaines questions est la frontière entre "comment puis-je faire cela?" et "s'il vous plaît faites mon travail, je suis trop stupide pour google cela" est une ligne assez fine. Je comprends que c’est souvent difficile, Google pense parce que vous ne savez pas pourquoi vous googlez, parce que vous ne connaissez pas encore le nom. Ceci dit, rassemblons tout ce que tout le monde peut faire dans un magasin magento, même s'il n'est pas un développeur.

Sonassi a déjà expliqué comment déboguer magento lorsque vous souhaitez vous salir , mais j'essaie d'ajouter des éléments et de copier ce que je pense qui est applicable aux marchands.

Clause de non-responsabilité: Tous les répertoires et fichiers mentionnés dans ce message sont relatifs au dossier racine de magento, qui peut se trouver /var/wwwmais, en fonction du fournisseur d'hébergement, votre soi-disant racine de document peut être partout, demandez à votre fournisseur, si vous ne trouvez pas votre magento !

Mode de développement

Vous voulez avoir de vraies erreurs, pas cette page "une erreur survenue" que magento livre normalement.

^{Merci à fontis.com pour cette image.}

Les rapports mentionnés sur la page se trouvent dans var/reports/<the_number>

Lorsque vous activez le mode développement, magento génère une erreur réelle. Ces erreurs peuvent notamment laisser échapper des informations d'identification, comme celles de la base de données! Alors, réfléchissez avant de l’activer sur les serveurs de production!

Ouvrez votre index.phpfichier dans le dossier racine de magento. Selon la version, vous trouvez ces lignes autour de la ligne 73:

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE'])) {
    Mage::setIsDeveloperMode(true);
}

#ini_set('display_errors', 1);

Pour activer maintenant le mode, vous devez changer ces lignes.

Si vous connaissez votre adresse IP (la plupart des gens en reçoivent une nouvelle toutes les 24 heures, au moins en Allemagne), Google vous aide ici:

Votre adresse IP publique est 87.138.100.68.

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) 
    || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress'
) {
    Mage::setIsDeveloperMode(true);
    ini_set('display_errors', 1);
}

Si vous ne connaissez pas votre adresse IP pour quelque raison que ce soit, vous pouvez afficher des erreurs pour tout le monde.

#if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
  Mage::setIsDeveloperMode(true);
#}
ini_set('display_errors', 1);

Enregistrement

Magento enregistre beaucoup de choses dans deux fichiers:

• var/log/exception.log
• var/log/system.log

Les exceptions sont toujours enregistrées. Le journal système doit être activé dans le backend:

System > Configuration > Developer > Log

Définissez Enabledsur Oui et vous voyez plus d'erreurs et messages de débogage dans system.loget dansexception.log

Est-ce un problème de thème?

Vous avez votre propre thème, celui-ci est configuré dans le backend ici:

Système> Configuration> Conception

^{Merci à kb.magenting.com pour l'image}

Ici, vous pouvez configurer le paquet et le thème. Si vous voulez essayer de reproduire l'erreur dans le thème par défaut, supprimez tout ce qui se trouve dans les champs de saisie. Cliquez ensuite sur Enregistrer et vous verrez le thème standard de Magento comme dans la boutique de démonstration . Si vous avez une boutique avant la version 1.8, vous pouvez trouver une capture d’écran dans le Guide de l’utilisateur de Magento Community Edition.

Si vous ne pouvez pas reproduire le problème dans le thème par défaut, votre thème est cassé, veuillez contacter le fournisseur du thème. Nous n'offrons pas d'assistance pour les thèmes tiers, en particulier les thèmes commerciaux.

Et maintenant?

Vous avez trouvé une erreur réelle, on peut reproduire, est-il reproductible dans le thème par défaut? Génial, veuillez poser une question et nous faisons de notre mieux pour vous aider.

Dans la question:

• décris ce que tu fais
• quelle erreur est levée
• y a-t-il quelque chose dans les fichiers journaux?
• peut-être une capture d'écran de l'erreur

1. Tout d'abord, vous devez activer le mode développeur
2. Vous pouvez également activer l'affichage des erreurs dans index.php: ini_set ('display_errors', 1);
3. Compilez l'extension xDebug avec n'importe quel IDE intelligent (PhpStrom / eclipse)
4. Désactiver le module personnalisé et tiers
5. Consultez votre journal des exceptions et des erreurs, résolvez les erreurs répertoriées dans le journal des exceptions
6. Vérifiez que les extensions curl et mcrypt doivent être chargées sur votre serveur
7. Vérifiez les autorisations de dossier et de fichiers chown -R sonassi: apache / home / chemin / public_html / find / home / chemin / public_html / -type d -exec chmod 775 {} \; find / home / path / public_html / -type f -exec chmod 664 {} \;
8. Mettez à jour l'autorisation du répertoire media et var 0777 si elle n'est pas définie
9. Démarrez IDE (phpstrom), puis définissez les points de départ du débogueur sur index.php 10.Appuyez sur F8 et poursuivez jusqu'à ce que vous obteniez une erreur.

Pour utiliser les étapes ci-dessus, vous devriez certainement avoir des erreurs.

Debug Backtrace

C'est la bonne fonction pour déboguer l'appel de fonction dans magento.

Ajoutez cette fonction dans includes / config.php ou créez un nouveau fichier et mettez toutes vos fonctions php couramment utilisées.

fonction back_trace ($ exit = true) {
  $ call_back_methods = '';
  $ call_back_methods. = '';
  $ call_back_methods. = 'Nom de la SNFunctionNom du fichier';

  compteur $ = 1;
  foreach (debug_backtrace () en tant que $ index => $ data) {
    // if (0 == $ index) continue;

    $ call_back_methods. = ''. $ compteur ++. '';
    $ call_back_methods. = ''. $ data ['fonction']. '';
    $ call_back_methods. = ''. $ data ['line']. '';
    $ call_back_methods. = ''. $ data ['file']. '';
  }

  $ call_back_methods. = '';

  print $ call_back_methods;

  if (true == $ exit) exit;
}

OutPut sera