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é.
- Renommez le répertoire de disposition en
.tmp
- 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.
- Renommez tous les modules du répertoire en
.tmp(pour les utilisateurs SSH ls | xargs -I {} mv {} {}.tmpou rename 's/^/.tmp/' *)
- 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.
