Das Debuggen ist eine Kunst, die sich jedoch leicht beherrschen lässt, wenn man einem einfachen Schema folgt.
Folgen Sie jedem Punkt, bis Sie eine Lösung gefunden haben.
Aktivieren Sie PHP-Fehler
Dies ist der Schlüssel zu den meisten Problemen. Aus Sicherheitsgründen oder aus anderen Gründen ist die Anzeige von PHP-Fehlern wahrscheinlich standardmäßig in Ihrer PHP-Konfiguration deaktiviert.
Sie können Fehler durch eine dauerhaftere Lösung oder nur durch eine temporärere Lösung aktivieren.
Permanente Lösung
Für Apache / mod_php Benutzer
In der .htaccessDatei Ihres Dokumentenstamms - legen Sie diese einfach oben ab.
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
Für Nginx / FastCGI-Benutzer
In Ihrer Nginx virtualhost-Konfiguration, entweder in der finalen location .php {Anweisung oder in der fastcgi_paramsDatei (falls Sie eine angegeben haben)
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;
Temporäre / universelle Lösung
Für jede Plattform
Bearbeiten Sie den Magento-Bootstrap index.phpin Ihrem Dokumentenstamm und kommentieren Sie die folgende Zeile aus:
#ini_set('display_errors', 1);
Aktivieren Sie den Entwicklermodus
Wenn Sie einen Fehler hatten und plötzlich auf die Seite "Fehlerbericht" geklickt haben und eine scheinbar nutzlose Fehlerzeichenfolge erhalten haben, wie 1184257287824- Sie haben ein paar Optionen.
Permanente Lösung
Für Apache / mod_php Benutzer
In Ihrer Dokumentenstammdatei .htaccess- legen Sie dies einfach oben ab.
SetEnv MAGE_IS_DEVELOPER_MODE true
Für Nginx / fastcgi Benutzer
In Ihrer Nginx virtualhost-Konfiguration, entweder in der finalen location .php {Anweisung oder in der fastcgi_paramsDatei (falls Sie eine angegeben haben)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Temporäre / universelle Lösung
Bearbeiten Sie den Magento-Bootstrap index.phpin Ihrem Dokumentenstamm und geben Sie entweder die ifAussage immer wahr oder aktivieren Sie sie für Ihre spezifische IP.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
oder
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Überprüfen Sie Ihre Berechtigungen
Falsche Berechtigungen verursachen eine Fülle von Problemen, von denen viele auf den ersten Blick nicht so einfach zu finden sind.
Zum Beispiel.
Wenn PHP nicht in das ./mediaVerzeichnis schreiben kann und Sie JS Combine aktiviert haben, kann Magento die kombinierte Datei und die zugehörige eindeutige URI für das Medium nicht generieren. Stattdessen finden Sie in Ihrem Browser-Quellcode einen vollständigen Serverpfad zur Mediendatei
/home/path/public_html/media/xxx
Andernfalls funktioniert die Site möglicherweise wie gewohnt - und es werden keine kritischen Fehler angezeigt.
Bitte beachten Sie, dass diese Vorgehensweise für dediziertes Hosting sicher ist, jedoch möglicherweise Sicherheitsprobleme beim gemeinsamen Hosting aufwirft, wenn der Apache-Prozess nicht pro Benutzer chrooted wird.
In unserem Beispiel ist der SSH / FTP-Benutzer sonassi, der Apache-Benutzer apacheund die Gruppeapache
Fügen Sie den FTP / SSH-Benutzer der Apache-Gruppe hinzu
Am wichtigsten ist , müssen wir sicherstellen , dass die FTP / SSH Benutzerteil der Apache - Gruppe ist, in unserem Beispiel sein apache( ist aber auch allgemein www-data)
usermod -a -G apache sonassi
Fügen Sie der Gruppe so viele Benutzer hinzu, wie Sie für FTP / SSH haben.
Ursprüngliche Berechtigungen zurücksetzen
Bevor wir beginnen, sollten wir sicherstellen, dass alle Berechtigungen korrekt sind.
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 {} \;
Änderungen dauerhaft vornehmen
ACLs und Sticky Bits
Mit ACLs in Linux können wir bestimmte Regeln definieren, in unserem Fall, welche Berechtigungsdateien bei der Erstellung erben sollen. Ein Sticky-Bit (später erwähnt) kümmert sich um die Gruppenvererbung, hilft jedoch nicht mit den Berechtigungen, weshalb wir ACLs verwenden.
Beginnen Sie, indem Sie die ACL-Unterstützung auf der aktiven Partition aktivieren. Stellen Sie sicher , dass Ihr Kernel mit ACL-Unterstützung kompiliert wurde .
Ihre Partition kann sein /, /home, /varoder etwas anderes, ersetzen als angemessen.
mount -o remount,acl /home
Wenn die ACLs aktiviert sind, können wir die ACL-Regeln festlegen und Sticky-Bits gruppieren:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Aber ich habe keine ACL-Unterstützung
Wenn Ihr Kernel keine ACLs unterstützt, können Sie auch umask(dies ist eine Laufzeiteinstellung für BASH, FTP und PHP) die Standarddateiberechtigungen festlegen. Magento setzt in der Regel umask(0)in index.php, jedoch wäre es in Ihrem Interesse sein , dies zu ändern.
In deinem index.phpWechsel soll die umaskLeitung sein
umask(022);
Stellen Sie dies in Ihrer BASH-Umgebung für SSH entweder in Ihrer .bashrcoder in Ihrer ein.bash_profile
umask 022
Für Ihren FTP-Server müssen Sie die Dokumentation lesen, das Prinzip ist jedoch dasselbe.
Thema auf Standard zurücksetzen
Möglicherweise ist entweder Ihr Thema oder Ihr Paket für dieses Problem verantwortlich. Wenn Sie zu einem Vanille-Magento-Thema zurückkehren, können Sie dies schnell herausfinden.
** Dies ist mit dem Vorbehalt verbunden, dass einige Module von bestimmten Themenfunktionen abhängig sein können *
Anstatt etwas über das Admin-Panel zu ändern, ist es viel einfacher, die fehlerhaften Verzeichnisse nur umzubenennen.
Über SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
Oder über Ihren FTP-Client durchlaufen und benennen Sie Ihr Paket in etwas anderes. z.B.myBrokenTheme.tmp
Wenn dies Ihr Problem behebt
Dann müssen Sie etwas genauer untersuchen, welcher Teil der Vorlage problematisch ist. Stellen Sie also Ihr Paket wieder her und versuchen Sie Folgendes, indem Sie zwischen den beiden Tests wechseln.
Im Wesentlichen müssen die Verzeichnisse beim Durchlaufen des Dateibaums nach und nach aktiviert werden, bis die fehlerhafte Datei gefunden wird.
- Benennen Sie das Layoutverzeichnis in um
.tmp
- Benennen Sie das Vorlagenverzeichnis in um
.tmp
Wenn sich dann eine Korrektur ergibt, benennen Sie alle Dateien im Layoutverzeichnis in .tmp- um (für die SSH-Benutzer ls | xargs -I {} mv {} {}.tmpoder rename 's/^/.tmp/' *).
Aktivieren Sie dann nach und nach jede Datei 1 für 1, bis sie aufgelöst ist.
Wenn dies Ihr Problem nicht löst
Es besteht die Möglichkeit, dass Ihre base/defaultoder enterprise/defaultVerzeichnisse kontaminiert sind - und am besten durch eine bekannte saubere Version ersetzt werden.
Sie können dies tun, indem Sie einen sauberen Build von Magento herunterladen und Ihre Verzeichnisse nach Bedarf ersetzen. Über SSH können Sie dies tun:
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 .
Sie können auch die Gelegenheit nutzen, diffdie beiden Verzeichnisse zu durchsuchen, um Änderungen zu überprüfen.
diff -r base base.tmp
NB. Diese Methode führt während des Vorgangs zu mehr Fehlern, da die Modulabhängigkeit das Vorhandensein bestimmter Dateien vorschreibt. Leider ist es das Gleiche für den Kurs.
Deaktivieren Sie lokale Module
Standardmäßig definiert Magento den PHP-Include-Pfad zum Laden von Klassen in der folgenden Reihenfolge
Local > Community > Core
Wenn sich eine Datei in Local befindet, laden Sie sie und führen Sie keine weiteren Schritte aus.
Wenn sich eine Datei in der Community befindet, laden Sie sie und führen Sie keine weiteren Aktionen aus.
Wenn eine Datei nirgendwo anders zu finden ist, laden Sie sie vom Core.
Anstatt Module über das Magento Admin Panel zu deaktivieren, ist es auch hier praktischer, dies auf Dateiebene zu tun.
Um ein Modul auf die "richtige" Weise zu deaktivieren, müssen Sie normalerweise die entsprechende ./app/etc/modules/MyModule.xmlDatei bearbeiten und festlegen <active>false</active>. Dies verhindert jedoch nicht, dass eine Klasse geladen wird.
Wenn eine andere Klasse eine bestimmte Klasse in einem Modul erweitert (wobei alle Magento-Abhängigkeitsdeklarationen ignoriert werden), wird diese weiterhin geladen - unabhängig davon, ob die Erweiterung deaktiviert ist oder nicht.
Das beste Mittel zum Deaktivieren einer Erweiterung ist das Umbenennen des Verzeichnisses.
Deaktivieren Sie zunächst local
Benennen Sie das Verzeichnis einfach über FTP um oder verwenden Sie den folgenden SSH-Befehl
mv ./app/code/local{,.tmp}
Dann deaktiviere die Community
mv ./app/code/community{,.tmp}
Wenn das Problem von einem der beiden behoben ist
Dann gilt es zu verstehen, aus welchem Modul insbesondere der Fehler stammt. Wie im obigen Beispiel für die Paketdiagnose gilt der gleiche Vorgang.
Stellen Sie also das X-Verzeichnis wieder her und versuchen Sie Folgendes, indem Sie zwischen den beiden testen.
Im Wesentlichen müssen die Verzeichnisse (Module) nach und nach einzeln aktiviert werden, bis der Fehler erneut auftritt
- Benennen Sie alle Module im Verzeichnis in um
.tmp(für die SSH-Benutzer ls | xargs -I {} mv {} {}.tmpoder rename 's/^/.tmp/' *)
- Aktivieren Sie nach und nach jedes Modul einzeln, indem Sie es
.tmpaus dem Dateinamen entfernen
Wenn das Problem nicht behoben ist
Dann ist es möglich, dass der Kern selbst kontaminiert ist. Der Hauptkern von Magento PHP besteht aus
./app/code/core
./lib
Benennen Sie diese Verzeichnisse erneut um und kopieren Sie sie in einer sauberen Variante. Vorausgesetzt, Sie haben bereits eine saubere Version von Magento wie oben über SSH heruntergeladen, können Sie dies tun:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Wenn das Problem weiterhin besteht, ersetzen Sie auch das libVerzeichnis
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
Zu diesem Zeitpunkt ist Ihr Magento-Shop nichts anderes als eine Vanille-Installation mit einer geänderten Datenbank.
Einige Modelle sind tatsächlich noch in der Datenbank gespeichert (z. B. Auftragsinkrement). Daher müssen diese Änderungen an dieser Stelle manuell vorgenommen werden. Bisher konnten alle oben genannten Schritte ohne dauerhaften Schaden rückgängig gemacht werden. Wenn wir aber auch eine saubere Magento-Datenbank importieren würden, könnte sich dies als irreversibel erweisen (wenn nicht nur ein Backup wiederhergestellt wird).
Die obige Anleitung soll Sie auf den Weg bringen, einen Fehler zu identifizieren. den resultierenden Fehler nicht zu beheben.
Inhalte stammen bereitwillig von www.sonassi.com/knowledge-base/magento-debug-process und www.sonassi.com/knowledge-base/stop-magento-permissions-errermanently
