Debugowanie to trochę sztuka, ale coś, co można łatwo opanować, wykonując prosty schemat.
Śledź każdy punkt, aż w końcu dojdziesz do rozwiązania.
Włącz błędy PHP
To jest klucz do większości problemów. Ze względów bezpieczeństwa lub z innych powodów wyświetlanie błędów PHP może być domyślnie wyłączone przez konfigurację PHP.
Możesz włączyć błędy za pomocą bardziej trwałego rozwiązania lub po prostu czegoś bardziej tymczasowego.
Stałe rozwiązanie
Dla użytkowników Apache / mod_php
W .htaccesspliku głównym dokumentu - po prostu upuść go na górze.
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
Dla użytkowników Nginx / FastCGI
W konfiguracji wirtualnego hosta Nginx, albo w ostatecznej location .php {dyrektywie, albo w fastcgi_paramspliku (jeśli masz określony)
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;
Rozwiązanie tymczasowe / uniwersalne
Na każdą platformę
Edytuj pasek startowy Magento index.phpw katalogu głównym dokumentu i odkomentuj następujący wiersz:
#ini_set('display_errors', 1);
Włącz tryb programisty
Gdy wystąpił błąd i nagle trafiłeś na stronę „Raport o błędzie” i otrzymałeś pozornie bezużyteczny ciąg błędów, na przykład 1184257287824- masz kilka opcji.
Stałe rozwiązanie
Dla użytkowników Apache / mod_php
W głównym .htaccesspliku dokumentu - po prostu upuść go u góry.
SetEnv MAGE_IS_DEVELOPER_MODE true
Dla użytkowników Nginx / fastcgi
W konfiguracji wirtualnego hosta Nginx, albo w ostatecznej location .php {dyrektywie, albo w fastcgi_paramspliku (jeśli masz określony)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Rozwiązanie tymczasowe / uniwersalne
Zmodyfikuj bootstrap Magento index.phpw katalogu głównym dokumentu i spraw, aby ifinstrukcja zawsze była prawdziwa lub włączona dla określonego adresu IP.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
lub
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Sprawdź swoje uprawnienia
Niepoprawne uprawnienia spowodują wiele problemów, z których wiele nie jest tak łatwo znaleźć na pierwszy rzut oka.
Na przykład.
Jeśli PHP nie może zapisać do ./mediakatalogu, a masz włączoną kombinację JS - Magento nie może wygenerować połączonego pliku i powiązanego unikalnego identyfikatora URI dla nośnika. Zamiast tego w kodzie źródłowym przeglądarki znajdziesz pełną ścieżkę serwera do pliku multimedialnego
/home/path/public_html/media/xxx
W przeciwnym razie witryna może wyglądać normalnie - bez widocznych błędów krytycznych.
Należy pamiętać, że ta praktyka jest bezpieczna dla hostingu dedykowanego, ale może stwarzać problemy z bezpieczeństwem hostingu współdzielonego, jeśli proces Apache nie jest chroot'owany na użytkownika.
W naszym przykładzie użytkownik SSH / FTP to sonassiużytkownik Apache, apachea grupa toapache
Dodaj użytkownika FTP / SSH do grupy Apache
Co najważniejsze, musimy upewnić się, że użytkownik FTP / SSH jest częścią grupy Apache, w naszym przykładzie jest to apache(ale często też www-data)
usermod -a -G apache sonassi
Dodawaj do grupy tylu użytkowników, ile masz w przypadku FTP / SSH.
Zresetuj oryginalne uprawnienia
Zanim zaczniemy, upewnijmy się, że wszystkie uprawnienia są prawidłowe.
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 {} \;
Wprowadzanie zmian na stałe
Listy ACL i bity lepkie
Listy ACL w systemie Linux pozwalają nam zdefiniować określone reguły, w naszym przypadku, jakie pliki uprawnień powinny dziedziczyć po utworzeniu. Lepki bit (wspomniana później) dba o grupie dziedziczenia, ale nie pomaga z uprawnieniami, który jest dlaczego używamy ACL.
Zacznij od włączenia obsługi ACL na aktywnej partycji, upewnij się, że twoje jądro zostało skompilowane z obsługą ACL .
Partycja może być /, /home, /varlub coś innego, wymienić w razie potrzeby.
mount -o remount,acl /home
Teraz listy ACL są włączone, możemy ustawić reguły ACL i grupować bity lepkie:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Ale nie mam obsługi ACL
Jeśli twoje jądro nie obsługuje list ACL, możesz również użyć umask(które jest ustawieniem czasu działania BASH, FTP i PHP), aby ustawić domyślne uprawnienia do plików. Magento zwykle ustawia umask(0)się index.phpjednak, że byłoby w swoich zainteresowaniach, aby to zmienić.
W twojej index.phpzmianie umaskpowinna być linia
umask(022);
W środowisku BASH dla SSH ustaw to w swoim .bashrclub.bash_profile
umask 022
W przypadku serwera FTP musisz przeczytać jego dokumentację, ale zasada jest taka sama.
Przywróć motyw do domyślnych
Możliwe, że za ten problem odpowiada Twój motyw lub pakiet. Powrót do waniliowego motywu Magento to szybki sposób na sprawdzenie.
** Jest to związane z zastrzeżeniem, że niektóre moduły mogą być zależne od niektórych funkcji motywu *
Zamiast zmieniać cokolwiek za pomocą panelu administracyjnego, o wiele łatwiej jest po prostu zmienić nazwę katalogów naruszających prawo.
Przez SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
Lub za pośrednictwem klienta FTP przejdź do nazwy pakietu i zmień jego nazwę na inną. na przykład.myBrokenTheme.tmp
Jeśli to rozwiąże problem
Następnie musisz głębiej dowiedzieć się, która część szablonu jest problematyczna. Przywróć pakiet i spróbuj wykonać następujące czynności, testując między nimi.
Zasadniczo proces polega na stopniowym włączaniu katalogów podczas przechodzenia w dół drzewa plików - dopóki nie znajdziesz pliku, który Cię narusza.
- Zmień nazwę katalogu układu na
.tmp
- Zmień nazwę katalogu szablonów na
.tmp
Następnie, jeśli albo poprawka, zmień nazwę wszystkich plików w katalogu układu na .tmp- (dla użytkowników SSH ls | xargs -I {} mv {} {}.tmplub rename 's/^/.tmp/' *)
Następnie stopniowo włączaj każdy plik 1 na 1, aż zostanie rozwiązany.
Jeśli to nie rozwiąże problemu
Istnieje możliwość, że twój base/defaultlub enterprise/defaultkatalogi zostały zanieczyszczone - najlepiej je zastąpić znaną czystą wersją.
Możesz to zrobić, pobierając czystą wersję Magento i wymieniając katalogi w razie potrzeby. Za pośrednictwem SSH możesz to zrobić:
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 .
Możesz również skorzystać z okazji do diffdwóch katalogów, jeśli chcesz zweryfikować zmiany.
diff -r base base.tmp
NB. Ta metoda spowoduje więcej błędów podczas procesu, ponieważ zależność modułu dyktuje istnienie określonych plików. Niestety jest równy kursowi.
Wyłącz moduły lokalne
Domyślnie Magento definiuje ścieżkę dołączania PHP do ładowania klas w następującej kolejności
Local > Community > Core
Jeśli plik jest w trybie lokalnym - załaduj go i nie rób więcej.
Jeśli plik znajduje się we wspólnocie - załaduj go i nie rób więcej.
Jeśli pliku nie można znaleźć nigdzie indziej - załaduj go z rdzenia.
Ponownie, zamiast wyłączać moduły za pomocą panelu administracyjnego Magento, bardziej praktyczne jest robienie tego na poziomie plików.
Zazwyczaj, aby wyłączyć moduł w „prawidłowy” sposób, należy edytować odpowiedni ./app/etc/modules/MyModule.xmlplik i ustawić <active>false</active>- jednak tak naprawdę nie uniemożliwia to załadowania klasy.
Jeśli inna klasa rozszerzy daną klasę w module (ignorując jakiekolwiek deklaracje zależności Magento), nadal będzie ładowana - niezależnie od tego, czy rozszerzenie jest wyłączone, czy nie.
Zatem ponownie najlepszym sposobem na wyłączenie rozszerzenia jest zmiana nazwy katalogu.
Zacznij od wyłączenia lokalnego
Po prostu zmień nazwę katalogu przez FTP lub użyj następującego polecenia SSH
mv ./app/code/local{,.tmp}
Następnie wyłącz społeczność
mv ./app/code/community{,.tmp}
Jeśli problem zostanie rozwiązany z jednego lub drugiego
Jest to przypadek zrozumienia, z którego modułu wynikał w szczególności błąd. Podobnie jak w przykładzie podanym powyżej dla diagnozy pakietu, obowiązuje ten sam proces.
Więc przywróć katalog X i spróbuj wykonać następujące czynności, testując między nimi.
Zasadniczo proces polega na stopniowym włączaniu katalogów (modułów) jeden po drugim, aż błąd pojawi się ponownie
- Zmień nazwę wszystkich modułów w katalogu na
.tmp(dla użytkowników SSH ls | xargs -I {} mv {} {}.tmplub rename 's/^/.tmp/' *)
- Stopniowo włączaj każdy moduł jeden po drugim, usuwając
.tmpz nazwy pliku
Jeśli problem nie zostanie rozwiązany
Wtedy możliwe jest zanieczyszczenie samego rdzenia. Główny rdzeń Magento PHP składa się z
./app/code/core
./lib
Więc ponownie zmień nazwy tych katalogów i skopiuj w czystym wariancie. Zakładając, że już pobrałeś czystą wersję Magento jak wyżej, za pośrednictwem SSH, możesz to zrobić:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Następnie, jeśli problem nadal nie został rozwiązany, wymień również libkatalog
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
W tym momencie twój sklep Magento będzie niczym więcej jak waniliową instalacją ze zmodyfikowaną bazą danych.
Niektóre modele są nadal przechowywane w bazie danych (np. Przyrost zamówienia) - dlatego w tym momencie staje się konieczne ręczne wprowadzanie tych zmian. Do tej pory wszystkie powyższe kroki były odwracalne bez trwałych obrażeń. Ale jeśli zaimportujemy również czystą bazę danych Magento - może okazać się nieodwracalna (bez przywracania kopii zapasowej).
Powyższy przewodnik pomoże Ci zidentyfikować błąd; nie naprawić wynikowego błędu.
Treści chętnie pozyskiwane z www.sonassi.com/knowledge-base/magento-debug-process i www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently
