Magento mağazamda nasıl hata ayıklayabilirim

Bu, şimdi bizim için çok da önemli olmayan bir sorudur, ancak 5 yıl önce bir Magento SE sitesi vardı, muhtemelen ilk sorumuz olurdu. Sadece Magento'ya giren veya bilmediğiniz kişiler için - hata ayıklamanın temellerini bilmek, sorunların nedenini dışlamak için anahtar olabilir. Ve şimdi bize olan ilgisizliğine rağmen, bu soruyu kendi kendine cevaplanmış bir yaklaşımla ortaya çıkmadan ön-duruyoruz.

Sitemin kapalı olmasına yardım edin!

1. Tasarımım hatalı mı?
2. 3. parti bir modül hatalı mı?
3. Neden hatayı göremiyorum?

Bu soruların her biri, en temel kullanıcıların bile yapabileceği hata ayıklamaya yönelik standart bir yaklaşım izleyerek kolayca yanıtlanabilir. Bir Magento mağazasında hata ayıklamanın temellerini ortadan kaldırma süreci yoluyla.

Hata ayıklama bir sanat eseridir, ancak basit bir rejimi takip ederek kolayca ustalaşılabilecek bir şeydir.

Sonunda bir çözüme ulaşana kadar her noktayı takip edin.

PHP Hatalarını Etkinleştir

Bu, çoğu sorunun anahtarıdır. Güvenlik veya başka nedenlerden dolayı, PHP hata gösterimi varsayılan olarak PHP yapılandırmanız tarafından devre dışı bırakılabilir.

Hataları daha kalıcı bir çözümle veya yalnızca daha geçici bir şeyle etkinleştirebilirsiniz.

Kalıcı çözüm

Apache / mod_php kullanıcıları için

Belgenizin kök .htaccessdosyasında - sadece bunu en üstüne bırakın.

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

Nginx / FastCGI kullanıcıları için

Nginx virtualhost yapılandırmanızda, son location .php {yönergede veya fastcgi_paramsdosyada (belirtilmişse)

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;

Geçici / Evrensel çözüm

Herhangi bir platform için

Magento önyükleme index.phpbelgesini belgenizin kökünde düzenleyin ve şu satırdaki açıklamaları kaldırın:

#ini_set('display_errors', 1);

Geliştirici Modunu Etkinleştir

Bir hata yaşadığınızda ve aniden "Hata Raporu" sayfasına 1184257287824bastığınızda ve görünüşte işe yaramaz bir hata dizesi verildiğinde - birkaç seçeneğiniz vardır.

Kalıcı çözüm

Apache / mod_php kullanıcıları için

Belge kök .htaccessdosyanızda - sadece bunu en üstüne bırakın.

SetEnv MAGE_IS_DEVELOPER_MODE true

Nginx / fastcgi kullanıcıları için

Nginx virtualhost yapılandırmanızda, son location .php {yönergede veya fastcgi_paramsdosyada (belirtilmişse)

fastcgi_param MAGE_IS_DEVELOPER_MODE true;

Geçici / Evrensel çözüm

Magento önyükleme index.phpbelgesini belge kökünüzde düzenleyin ve ififadeyi her zaman doğru yapın veya IP'niz için etkinleştirin.

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

veya

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

İzinlerini kontrol et

Yanlış izinler birçoğu ilk bakışta bulmak o kadar kolay olmayan çok sayıda soruna neden olur.

Örneğin.
PHP ./mediadizine yazamıyorsa ve JS birleştirmeyi etkinleştirmişseniz - Magento, birleştirilmiş dosyayı ve medya için ilgili benzersiz URI'yı oluşturamaz. Bunun yerine, tarayıcı kaynak kodunda bulacağın şey medya dosyasına giden tam bir sunucu yoludur. /home/path/public_html/media/xxx

Aksi takdirde, site normal olarak çalışıyor gibi görünebilir - gerçekten önemli bir hata olmadan.

Lütfen unutmayın, bu uygulama özel barındırma için güvenlidir ancak Apache işlemi kullanıcı başına chro'ed değilse, paylaşılan barındırma ile ilgili güvenlik sorunları sunabilir.

Örneğimizde, SSH / FTP kullanıcısı, sonassiApache kullanıcısı apacheve grupapache

FTP / SSH kullanıcısını Apache grubuna ekleyin

En önemlisi, bizim örneğimizde, FTP / SSH kullanıcısının Apache grubunun bir parçası olduğundan emin olmamız gerekir apache(aynı zamanda yaygındır www-data).

usermod -a -G apache sonassi

FTP / SSH için grubunuza istediğiniz kadar kullanıcı eklemeye devam edin.

Orijinal izinleri sıfırla

Bu yüzden başlamadan önce, tüm izinlerin doğru olduğundan emin olalım.

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 {} \;

Değişikliklerin kalıcı hale getirilmesi

ACL'ler ve Yapışkan Uçlar

Linux'taki ACL'ler özel kuralları tanımlamamıza izin verir, bizim durumumuzda, hangi izin dosyalarının oluşturulduklarında devralınması gerektiğini. Bir yapışkan bit (daha sonra sözü) grubu miras ilgilenir ama biz EKL'lerini kullanmak yüzden izinleri ile yardımcı olmuyor.

Aktif bölümdeki ACL desteğini etkinleştirerek başlayın, lütfen Çekirdeğinizin ACL desteğiyle derlendiğinden emin olun .

Kişisel bir bölüm olabilir /, /home, /varveya başka bir şey gibi uygun değiştirin.

mount -o remount,acl /home

Şimdi ACL'ler etkin, ACL kurallarını ve yapışkan bit gruplarını ayarlayabiliriz:

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

Ama ACL desteğim yok

Çekirdeğiniz ACL'leri desteklemiyorsa umask, varsayılan dosya izinlerini ayarlamak için de (BASH, FTP ve PHP için çalışma zamanı ayarı olan) kullanabilirsiniz. Magento genellikle setleri umask(0)de index.php, ancak bunu değiştirmek için ilgi olacaktır.

Senin içinde index.phpdeğişim umaskçizgisi olmak

umask(022);

Ve SSH için BASH ortamınızda, bunu ya .bashrcda.bash_profile

umask 022

FTP sunucunuz için belgelerini okumanız gerekir, ancak prensip aynıdır.

Temayı varsayılana döndür

Temanız veya paketinizin bu sorundan sorumlu olması mümkündür. Vanilya temasına geri dönmek Magento temasını bulmak için hızlı bir yoldur.

** Bu, bazı modüllerin belirli tema özelliklerine bağlı olabileceği uyarısıyla birlikte gelir *

Yönetici paneli aracılığıyla bir şeyleri değiştirmek yerine, rahatsız edici dizinleri yeniden adlandırmak çok daha kolaydır.

SSH ile

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

Veya FTP istemciniz aracılığıyla paketinizi başka birşeye çevirin ve yeniden adlandırın. Örneğin.myBrokenTheme.tmp

Bu, sorununuzu çözerse

O zaman, şablonun hangi bölümünün sorunlu olduğu konusunda biraz daha derine inmeniz gerekir. Bu nedenle, paketinizi geri yükleyin ve her birini arasında test ederek aşağıdakileri deneyin.

Temel olarak süreç, dosya ağacında gezinirken dizinleri kademeli olarak etkinleştirmektir - sorunlu dosyayı bulana kadar.

1. Düzen dizinini yeniden adlandır .tmp
2. Şablon dizinini yeniden adlandır .tmp

Ya bir düzeltme verir Sonra, hiç düzen dizin içindeki tüm dosyaları yeniden adlandırmak .tmp- (SSH kullanıcıları için ls | xargs -I {} mv {} {}.tmpya rename 's/^/.tmp/' *)

Ardından, çözülene kadar her dosyayı yavaş yavaş 1'e 1 etkinleştirin.

Bu sorununuzu çözmezse

Sizin base/defaultveya enterprise/defaultdizinlerin kirlenmiş olma potansiyeli vardır - ve en iyi bilinen temiz bir versiyonla değiştirilmelidir.

Bunu, Magento'nun temiz bir derlemesini indirip ve dizinlerinizi gerektiği gibi değiştirerek yapabilirsiniz. SSH ile bunu yapabilirsiniz:

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 .

diffHerhangi bir değişikliği doğrulamak istiyorsanız, iki dizine de fırsat verebilirsiniz .

diff -r base base.tmp

NB. Modül bağımlılığı belirli dosyaların varlığını belirttiğinden, bu yöntem işlem sırasında daha fazla hataya neden olur. Ne yazık ki, kurs için eşit.

Yerel modülleri devre dışı bırak

Varsayılan olarak, Magento, PHP'yi sınıfları aşağıdaki sırayla yükleme yolunu tanımlar

Local > Community > Core

Bir dosya Yerel ise - yükleyin ve daha fazlasını yapmayın.
Bir dosya topluluktaysa - yükleyin ve daha fazlasını yapmayın.
Bir dosya başka bir yerde bulunamazsa - çekirdekten yükleyin.

Yine, Magento yönetici paneli aracılığıyla modülleri devre dışı bırakmak yerine, bunu dosya düzeyinde yapmak daha pratiktir.

Genellikle, bir modülü "uygun" şekilde devre dışı bırakmak için, ilgili ./app/etc/modules/MyModule.xmldosyayı düzenler ve ayarlarsınız <active>false</active>- ancak bu aslında bir sınıfın yüklenmesini engellemez.

Başka bir sınıf belirli bir sınıfı bir modülde uzatırsa (herhangi bir Magento bağımlılığı bildirimini dikkate almazsa), uzantının devre dışı olup olmamasından bağımsız olarak yine de yüklenir.

Dolayısıyla, bir uzantıyı devre dışı bırakmak için en iyi yol dizini yeniden adlandırmaktır.

Yerel devre dışı bırakarak başlayın

Dizini FTP ile yeniden adlandırın veya aşağıdaki SSH komutunu kullanın

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

Ardından topluluğu devre dışı bırak

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

Sorun ikisinden de çözülmüşse

O zaman özellikle hatanın hangi modülden kaynaklandığını anlamak bir durumdur. Paket teşhisi için yukarıda verilen örnekte olduğu gibi aynı işlem uygulanır.

Bu nedenle, X dizinini geri yükleyin ve her birini arasında test ederek aşağıdakileri deneyin.

Temel olarak, işlem, hatalar yeniden oluşana kadar dizinleri (modülleri) birer birer kademeli olarak etkin kılmaktır.

1. Dizindeki tüm modülleri yeniden adlandırın .tmp(SSH kullanıcıları ls | xargs -I {} mv {} {}.tmpveya rename 's/^/.tmp/' *)
2. .tmpDosya adını kaldırarak her bir modülü birer birer yavaş yavaş etkinleştirin

Sorun çözülmediyse

O zaman çekirdeğin kendisi kirlenmiş olabilir. Ana Magento PHP çekirdeği oluşur

./app/code/core
./lib

Böylece tekrar, bu dizinleri yeniden adlandırın ve temiz bir değişkende kopyalayın. Yukarıdaki gibi Magento'nun temiz bir sürümünü zaten indirdiğinizi varsayarsak, SSH aracılığıyla şunları yapabilirsiniz:

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

Sonra sorun hala çözülmediyse, libdizini de değiştirin

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

Bu noktada, Magento mağazanız, değiştirilmiş bir veritabanına sahip bir vanilya kurulumundan başka bir şey olmayacak.

Bazı modeller hala veritabanında saklanmaktadır (örneğin, sipariş artışı) - bu noktada, bu düzenlemeleri manuel olarak yapmak için bir durum haline gelir. Şimdiye kadar, yukarıdaki tüm adımlar kalıcı bir hasar olmadan geri dönüşümlü olmuştur. Fakat eğer temiz bir Magento veri tabanını da içeriyorsak, geri dönüşü olmayacaktı (bir yedeği geri yükleme yetersizliği).

Yukarıdaki rehber size bir hatayı belirlemenize yardımcı olur; sonuçta meydana gelen hatayı düzeltmemek.

^{İçerik isteyerek www.sonassi.com/knowledge-base/magento-debug-process ve www.sonassi.com/knowledge-base/magento-debug-process adresinden ve www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently adresinden alınmıştır.}

As Twitter'da talep ve Meta üzerinde tartışılan Burada olmayan cihazlarý bir hata ayıklama öğretici başlayacağız.

İlk önce sanırım (sen bile bu işe girmeye çalışırsan) Magento, geliştirici / geliştirme ekibi olmayan bir tüccar için çok karmaşık. Ama cesursanız ve denemek istiyorsanız, size yardımcı olmak için elimizden gelenin en iyisini yapıyoruz. Bazı sorular için “bunu nasıl yapabilirim?” Arasındaki sınır olduğunu düşünüyorum. ve "lütfen çalışmamı yapın, google'ı bulamayacak kadar aptalım" oldukça iyi bir çizgi. Google’ın ne kadar zor olduğunu bilmediğiniz için, çünkü adınızı henüz bilmediğiniz için düşünmenin zor olduğunu biliyorum. Bu, magento mağazasına sahip herkesin yapabileceği şeyleri toplayalım, geliştirici olmasanız bile.

Magento'nun nasıl hata ayıklanacağına dair çok güzel bir cevap, kirlenmek istediğinizde Sonassi tarafından çoktan verildi , ancak bir şeyler eklemeye ve tüccarlar için uygulanabilir olduğunu düşündüğüm şeyi kopyalamaya çalışıyorum.

Feragatname: Bu yayında belirtilen tüm dizinler ve dosyalar /var/www, barındırma sağlayıcısına bağlı olan ama içerdiği Belge Kökü'nün her yerde olabileceği magento kök klasörüne göredir; !

Geliştirme Modu

Magento'nun normal bir şekilde sunduğu " berbat bir hata oluştu" sayfasını değil, gerçek hatalara sahip olmak istiyorsunuz .

^{Bu görüntü için fontis.com'a teşekkürler .}

Sayfada belirtilen raporlarda bulunabilir. var/reports/<the_number>

Geliştirme modunu etkinleştirdiğinizde, magento gerçek hatayı yükseltir, bu hatalar özellikle veri tabanındakiler gibi kimlik bilgilerini sızdırabilir! Yani, üretim sunucularında açmadan önce düşünün!

index.phpDosyanızı magento'nun kök klasöründe açın , sürüme bağlı olarak, şu satırları satır 73 civarında bulabilirsiniz:

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

#ini_set('display_errors', 1);

Şimdi modu etkinleştirmek için bu satırları değiştirmeniz gerekir.

IP adresinizi biliyorsanız (çoğu insan 24 saatte bir, en azından Almanya'da yeni bir tane alır), google size yardımcı olur:

Genel IP adresiniz 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);
}

IP'nizi ne sebeple olursa olsun bilmiyorsanız, herkes için hatalar gösterebilirsiniz.

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

Kerestecilik

Magento bir çok şeyi iki dosyaya kaydeder:

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

İstisnalar her zaman kaydedilir. Sistem günlüğünün arka uçta etkinleştirilmesi gerekiyor:

System > Configuration > Developer > Log

EnabledEvet olarak ayarlayın ; içeride ve içeride daha fazla hata ve hata ayıklama görürsünüz system.log.exception.log

Bu bir tema sorunu mu?

Kendi temanız var, bu burada arka uçta yapılandırılmıştır:

Sistem> Konfigürasyon> Tasarım

^{Resim için kb.magenting.com'a teşekkürler}

Burada paketi ve temayı yapılandırabilirsiniz. Hatayı varsayılan temada yeniden oluşturmayı denemek istiyorsanız, giriş alanlarından her şeyi kaldırın. Ardından kaydet düğmesine tıklayın ve demo mağazasında olduğu gibi standart magento temasını görürsünüz, 1.8'den önce bir mağazanız varsa Magento Community Edition Kullanıcı Kılavuzu'nda ekran görüntüsü bulabilirsiniz.

Sorunu varsayılan temada yeniden oluşturamazsanız, temanız bozulursa, lütfen tema satıcısına başvurun. Üçüncü taraf temalarına, özellikle de ticari olanlara destek vermiyoruz.

Şimdi ne var?

Gerçek bir hata buldunuz, biri yeniden üretilebiliyor, varsayılan temada yeniden üretilebiliyor mu? Harika, lütfen bir soru aç, yardımcı olmak için elimizden geleni yapıyoruz.

Soruda:

• ne yaptığını tanımla
• hangi hata oluştu
• günlük dosyalarında herhangi bir şey var mı?
• belki de hatanın ekran görüntüsü

1. Öncelikle, Geliştirici modunu etkinleştirmelisiniz
2. Ayrıca index.php: ini_set ('display_errors', 1) 'de hataları göstermeyi de etkinleştirebilirsiniz.
3. Herhangi bir akıllı IDE ile xDebug uzantısını derleyin (PhpStrom / eclipse)
4. Özel ve 3. taraflar modülünü devre dışı bırakın
5. İstisna ve hata kayıtlarını inceleyin, istisna kayıtlarında listelenen hataları çözün
6. Curl'i kontrol edin ve mcrypt eklentisinin sunucunuza yüklenmesi gerektiğini kontrol edin.
7. Klasör ve dosya izinlerini kontrol edin 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 {} \;
8. Ayarlanmamışsa medyayı ve var dizin iznini 0777 güncelleyin
9. IDE'yi (phpstrom) başlatın, daha sonra index.php 10'daki hata ayıklayıcı başlangıç ​​noktalarını ayarlayın. F8 tuşuna basın ve hata elde edene kadar devam edin

Yukarıdaki adımları kullanmak için kesinlikle hata almalısınız.

Debug Backtrace

Bu magento işlev çağrısında hata ayıklamak için iyi bir fonksiyondur.

Bu işlevi include / config.php dosyasına ekleyin veya yeni bir dosya oluşturun ve tüm kullanılmış php işlevlerinizi koyun.

işlev back_trace ($ exit = true) {
  $ call_back_methods = '';
  $ call_back_methods. = '';
  $ call_back_methods. = 'SNFunction NameLine NumberFile Name';

  $ counter = 1;
  foreach (debug_backtrace () $ index => $ data) {
    // eğer (0 == $ index) devam;

    $ call_back_methods. = ''. $ counter ++. '';
    $ call_back_methods. = ''. $ data ['işlev']. '';
    $ call_back_methods. = ''. $ data ['line']. '';
    $ call_back_methods. = ''. $ data ['dosya']. '';
  }

  $ call_back_methods. = '';

  $ call_back_methods yazdırın;

  if (true == $ exit) exit;
}

Çıkış