Debugging adalah sedikit seni, tetapi sesuatu yang dapat dengan mudah dikuasai dengan mengikuti rejimen sederhana.
Ikuti setiap titik sampai Anda akhirnya mencapai solusi.
Aktifkan Kesalahan PHP
Ini adalah kunci untuk sebagian besar masalah. Demi keamanan atau alasan lain, tampilan kesalahan PHP kemungkinan dapat dinonaktifkan secara default oleh konfigurasi PHP Anda.
Anda dapat mengaktifkan kesalahan dengan solusi yang lebih permanen, atau hanya sesuatu yang lebih sementara.
Solusi permanen
Untuk pengguna Apache / mod_php
Di .htaccess
file root dokumen Anda - cukup taruh ini di atas.
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
Untuk pengguna Nginx / FastCGI
Dalam konfigurasi virtualhost Nginx Anda, baik dalam location .php {
direktif akhir , atau dalam fastcgi_params
file (jika Anda memiliki satu yang ditentukan)
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;
Solusi sementara / Universal
Untuk platform apa pun
Edit bootstrap Magento index.php
di root dokumen Anda dan batalkan komentar pada baris berikut:
#ini_set('display_errors', 1);
Aktifkan Mode Pengembang
Ketika Anda memiliki kesalahan dan tiba-tiba tekan halaman "Laporan Kesalahan", dan diberi string kesalahan yang tampaknya tidak berguna seperti 1184257287824
- Anda punya beberapa opsi.
Solusi permanen
Untuk pengguna Apache / mod_php
Di .htaccess
file root dokumen Anda - cukup taruh ini di atas.
SetEnv MAGE_IS_DEVELOPER_MODE true
Untuk pengguna Nginx / fastcgi
Dalam konfigurasi virtualhost Nginx Anda, baik dalam location .php {
direktif akhir , atau dalam fastcgi_params
file (jika Anda memiliki satu yang ditentukan)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Solusi sementara / Universal
Edit bootstrap Magento index.php
di root dokumen Anda dan buat if
pernyataan itu selalu benar, atau diaktifkan untuk IP spesifik Anda.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
atau
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Periksa izin Anda
Izin yang tidak benar akan menyebabkan banyak masalah, banyak yang tidak mudah ditemukan pada pandangan pertama.
Sebagai contoh.
Jika PHP tidak dapat menulis ke ./media
direktori dan JS gabungan Anda diaktifkan - Magento tidak dapat membuat file gabungan dan URI unik terkait untuk media. Jadi alih-alih, apa yang akan Anda temukan dalam kode sumber peramban adalah jalur server lengkap ke file media
/home/path/public_html/media/xxx
Jika tidak, situs tersebut dapat berfungsi seperti biasa - tanpa ada kesalahan kritis yang benar-benar terlihat.
Harap diingat, praktik ini aman untuk hosting khusus tetapi dapat menghadirkan masalah keamanan dengan hosting bersama jika proses Apache tidak di-chroot per pengguna.
Dalam contoh kami, pengguna SSH / FTP adalah sonassi
, pengguna Apache apache
dan grupnyaapache
Tambahkan pengguna FTP / SSH ke grup Apache
Yang paling penting, kita perlu memastikan bahwa pengguna FTP / SSH adalah bagian dari kelompok Apache, dalam contoh kita, apache
(tetapi juga umum www-data
)
usermod -a -G apache sonassi
Terus tambahkan sebanyak mungkin pengguna ke grup yang Anda miliki untuk FTP / SSH.
Setel ulang izin asli
Jadi sebelum kita mulai, mari pastikan semua izin sudah benar.
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 {} \;
Membuat perubahan permanen
ACL dan Bit Lengket
ACL di Linux memungkinkan kami untuk menetapkan aturan tertentu, dalam kasus kami, file izin apa yang harus diwarisi saat dibuat. Sebuah bit lengket (disebutkan nanti) mengurus warisan kelompok, tetapi tidak membantu dengan hak akses, itulah sebabnya mengapa kita menggunakan ACL.
Mulailah dengan mengaktifkan dukungan ACL pada partisi aktif, pastikan Kernel Anda dikompilasi dengan dukungan ACL .
Partisi Anda mungkin /
, /home
, /var
atau sesuatu yang lain, ganti sesuai.
mount -o remount,acl /home
Sekarang ACL diaktifkan, kita dapat mengatur aturan ACL dan mengelompokkan bit yang lengket:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Tetapi saya tidak memiliki dukungan ACL
Jika Kernel Anda tidak mendukung ACL, Anda juga dapat menggunakan umask
(yang merupakan pengaturan waktu berjalan untuk BASH, FTP dan PHP) untuk mengatur izin file default. Magento biasanya set umask(0)
di index.php
, bagaimanapun, itu akan kepentingan Anda untuk mengubah ini.
Dalam index.php
mengubah umask
garis yang Anda buat
umask(022);
Dan di lingkungan BASH Anda untuk SSH, atur ini di Anda .bashrc
atau.bash_profile
umask 022
Untuk server FTP Anda, Anda harus membaca dokumentasi untuk itu, tetapi prinsipnya sama.
Kembalikan tema ke default
Kemungkinan tema atau paket Anda bertanggung jawab atas masalah ini. Mengembalikan ke tema vanilla Magento adalah cara cepat untuk mengetahuinya.
** Ini disertai dengan peringatan bahwa beberapa modul mungkin tergantung pada fitur tema tertentu *
Daripada mengubah apa pun melalui panel admin, lebih mudah untuk sekadar mengganti nama direktori yang menyinggung.
Melalui SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
Atau melalui klien FTP Anda, lintasi dan ganti nama paket Anda ke sesuatu yang lain. misalnya.myBrokenTheme.tmp
Jika ini menyelesaikan masalah Anda
Maka Anda perlu menggali sedikit lebih dalam tentang bagian mana dari template yang bermasalah. Jadi kembalikan paket Anda dan coba yang berikut ini, ujilah di antaranya.
Pada dasarnya, prosesnya adalah mengaktifkan direktori secara bertahap saat Anda menelusuri pohon file - hingga Anda dapat menemukan file yang menyinggung itu.
- Ubah nama direktori tata letak menjadi
.tmp
- Ganti nama direktori templat menjadi
.tmp
Kemudian jika salah satu menghasilkan perbaikan, ganti nama semua file di dalam direktori layout menjadi .tmp
- (untuk pengguna SSH ls | xargs -I {} mv {} {}.tmp
atau rename 's/^/.tmp/' *
)
Kemudian secara bertahap aktifkan setiap file 1 per 1 hingga teratasi.
Jika ini tidak menyelesaikan masalah Anda
Ada potensi bahwa Anda base/default
atau enterprise/default
direktori telah terkontaminasi - dan terbaik diganti dengan versi bersih dikenal.
Anda dapat melakukan ini dengan mengunduh membangun Magento yang bersih dan mengganti direktori Anda jika perlu. Melalui SSH Anda dapat melakukan ini:
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 .
Anda juga dapat mengambil kesempatan ke diff
dua direktori jika Anda ingin memverifikasi perubahan apa pun.
diff -r base base.tmp
NB. Metode ini akan menyebabkan lebih banyak kesalahan selama proses, karena ketergantungan modul menentukan keberadaan file tertentu. Sayangnya, par untuk kursus.
Nonaktifkan modul lokal
Secara default, Magento mendefinisikan jalur menyertakan PHP untuk memuat kelas dalam urutan berikut
Local > Community > Core
Jika file di Lokal - muat dan jangan lakukan lagi.
Jika file ada di komunitas - muat dan jangan lakukan lagi.
Jika file tidak dapat ditemukan di tempat lain - muat dari inti.
Sekali lagi, daripada menonaktifkan modul melalui panel admin Magento, lebih praktis untuk melakukan ini pada tingkat file.
Biasanya, untuk menonaktifkan modul dengan cara "benar", Anda akan mengedit ./app/etc/modules/MyModule.xml
file masing-masing dan mengatur <active>false</active>
- namun, ini sebenarnya tidak mencegah kelas dari memuat.
Jika kelas lain memperluas kelas yang diberikan dalam modul (mengabaikan deklarasi dependensi Magento), itu akan tetap dimuat - terlepas dari apakah ekstensi dinonaktifkan atau tidak.
Jadi sekali lagi, cara terbaik untuk menonaktifkan ekstensi adalah mengganti nama direktori.
Mulailah dengan menonaktifkan lokal
Cukup ganti nama direktori melalui FTP, atau gunakan perintah SSH berikut
mv ./app/code/local{,.tmp}
Kemudian nonaktifkan komunitas
mv ./app/code/community{,.tmp}
Jika masalah teratasi dari keduanya
Maka itu adalah kasus pemahaman dari modul mana kesalahan berasal. Seperti contoh yang diberikan di atas untuk diagnosis paket, proses yang sama berlaku.
Jadi kembalikan direktori X dan coba yang berikut, uji di antara masing-masing.
Intinya, prosesnya adalah mengaktifkan direktori (modul) secara bertahap satu per satu hingga kesalahan muncul kembali
- Ganti nama semua modul di direktori menjadi
.tmp
(untuk pengguna SSH ls | xargs -I {} mv {} {}.tmp
atau rename 's/^/.tmp/' *
)
- Secara bertahap aktifkan setiap modul satu per satu, dengan menghapus
.tmp
dari nama file
Jika masalah tidak terselesaikan
Maka tidak menutup kemungkinan inti itu sendiri terkontaminasi. Inti utama PHP Magento terdiri dari
./app/code/core
./lib
Jadi sekali lagi, ganti nama direktori ini dan salin dalam varian bersih. Dengan asumsi Anda sudah mengunduh versi Magento yang bersih seperti di atas, melalui SSH, Anda dapat melakukan ini:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Kemudian jika masalah masih belum terselesaikan, ganti lib
direktori juga
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
Pada titik ini, toko Magento Anda tidak lebih dari instalasi vanila dengan database yang dimodifikasi.
Beberapa model sebenarnya masih disimpan dalam basis data (Misalnya, peningkatan pesanan) - jadi pada titik ini, ini menjadi kasus pembuatan secara manual. Sejauh ini, semua langkah di atas telah dibalik tanpa kerusakan yang berlangsung lama. Tetapi jika kita juga mengimpor database Magento yang bersih - itu bisa membuktikan tidak dapat dikembalikan (singkatnya memulihkan cadangan).
Panduan di atas berfungsi untuk membantu Anda mengidentifikasi kesalahan; tidak memperbaiki kesalahan yang dihasilkan.
Konten rela bersumber dari www.sonassi.com/knowledge-base/magento-debug-process dan www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently