Gỡ lỗi là một chút nghệ thuật, nhưng một cái gì đó có thể dễ dàng được làm chủ bằng cách làm theo một chế độ đơn giản.
Thực hiện theo từng điểm cho đến khi bạn đạt được một giải pháp.
Kích hoạt lỗi PHP
Đây là chìa khóa cho hầu hết các vấn đề. Vì lý do bảo mật hoặc lý do khác, hiển thị lỗi PHP có thể bị tắt theo mặc định bởi cấu hình PHP của bạn.
Bạn có thể kích hoạt các lỗi với một giải pháp lâu dài hơn, hoặc chỉ là một cái gì đó tạm thời hơn.
Giải pháp lâu dài
Dành cho người dùng Apache / mod_php
Trong .htaccesstập tin gốc của tài liệu của bạn - chỉ cần thả cái này ở trên cùng.
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
Dành cho người dùng Nginx / FastCGI
Trong cấu hình máy chủ ảo Nginx của bạn, trong lệnh cuối cùng location .php {hoặc trong fastcgi_paramstệp (nếu bạn có một chỉ định)
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;
Giải pháp tạm thời / phổ quát
Đối với bất kỳ nền tảng
Chỉnh sửa bootstrap Magento index.phptrong thư mục gốc của bạn và bỏ dòng sau:
#ini_set('display_errors', 1);
Kích hoạt chế độ nhà phát triển
Khi bạn gặp lỗi và bất ngờ nhấn trang "Báo cáo lỗi" và được cung cấp một chuỗi lỗi dường như vô dụng như 1184257287824- bạn có một vài tùy chọn.
Giải pháp lâu dài
Dành cho người dùng Apache / mod_php
Trong .htaccesstệp gốc tài liệu của bạn - chỉ cần thả cái này ở trên cùng.
SetEnv MAGE_IS_DEVELOPER_MODE true
Dành cho người dùng Nginx / fastcgi
Trong cấu hình máy chủ ảo Nginx của bạn, trong lệnh cuối cùng location .php {hoặc trong fastcgi_paramstệp (nếu bạn có một chỉ định)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Giải pháp tạm thời / phổ quát
Chỉnh sửa bootstrap Magento index.phptrong thư mục gốc của bạn và làm cho ifcâu lệnh luôn luôn đúng hoặc được bật cho IP cụ thể của bạn.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
hoặc là
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Kiểm tra quyền của bạn
Quyền không chính xác sẽ gây ra vô số vấn đề, rất nhiều trong số đó không dễ tìm thấy ngay từ cái nhìn đầu tiên.
Ví dụ.
Nếu PHP không thể ghi vào ./mediathư mục và bạn đã bật kết hợp JS - Magento không thể tạo tệp kết hợp và URI duy nhất được liên kết cho phương tiện truyền thông. Vì vậy, thay vào đó, những gì bạn sẽ tìm thấy trong mã nguồn trình duyệt của mình là đường dẫn máy chủ đầy đủ đến tệp phương tiện
/home/path/public_html/media/xxx
Mặt khác, trang web có thể hoạt động như bình thường - không có lỗi nghiêm trọng thực sự có thể nhìn thấy.
Xin lưu ý, thực tiễn này an toàn cho lưu trữ chuyên dụng nhưng có thể gây ra sự cố bảo mật với lưu trữ được chia sẻ nếu quy trình Apache không bị chroot'ed cho mỗi người dùng.
Trong ví dụ của chúng tôi, người dùng SSH / FTP là sonassi, người dùng Apache apachevà nhóm làapache
Thêm người dùng FTP / SSH vào nhóm Apache
Quan trọng nhất, chúng ta cần đảm bảo rằng người dùng FTP / SSH là một phần của nhóm Apache, trong ví dụ của chúng tôi, apache(nhưng cũng thường gặp www-data)
usermod -a -G apache sonassi
Tiếp tục thêm nhiều người dùng vào nhóm như bạn có cho FTP / SSH.
Đặt lại quyền ban đầu
Vì vậy, trước khi chúng tôi bắt đầu, hãy đảm bảo tất cả các quyền là chính xác.
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 {} \;
Làm cho những thay đổi vĩnh viễn
ACL và bit dính
ACL trong Linux cho phép chúng tôi xác định các quy tắc cụ thể, trong trường hợp của chúng tôi, các tệp quyền nào sẽ được kế thừa khi tạo. Một bit dính (được đề cập sau) sẽ đảm nhiệm việc kế thừa nhóm, nhưng không giúp với các quyền, đó là lý do tại sao chúng tôi sử dụng ACL.
Bắt đầu bằng cách bật hỗ trợ ACL trên phân vùng hoạt động, vui lòng đảm bảo Kernel của bạn được biên dịch với hỗ trợ ACL .
Phân vùng của bạn có thể /, /home, /varhay cái gì khác, thay thế cho phù hợp.
mount -o remount,acl /home
Bây giờ ACL đã được bật, chúng ta có thể đặt quy tắc ACL và nhóm bit dính:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Nhưng tôi không có hỗ trợ ACL
Nếu Kernel của bạn không hỗ trợ ACL, bạn cũng có thể sử dụng umask(đó là cài đặt thời gian chạy cho BASH, FTP và PHP) để đặt quyền truy cập tệp mặc định. Magento thường đặt umask(0)trong index.php, tuy nhiên, nó sẽ là vì lợi ích của bạn để thay đổi điều này.
Trong index.phpsự thay đổi của bạn , umaskdòng
umask(022);
Và trong môi trường BASH của bạn cho SSH, hãy đặt cái này trong .bashrchoặc.bash_profile
umask 022
Đối với máy chủ FTP của bạn, bạn sẽ cần đọc tài liệu cho nó, nhưng nguyên tắc là như vậy.
Hoàn nguyên chủ đề về mặc định
Có thể chủ đề hoặc gói của bạn chịu trách nhiệm cho vấn đề này. Quay trở lại một chủ đề Magento vanilla là một cách nhanh chóng để tìm hiểu.
** Điều này đi kèm với cảnh báo rằng một số mô-đun có thể phụ thuộc vào các tính năng chủ đề nhất định *
Thay vì thay đổi bất cứ điều gì thông qua bảng quản trị, việc đổi tên các thư mục vi phạm sẽ đơn giản hơn nhiều.
Qua SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
Hoặc thông qua ứng dụng khách FTP của bạn, duyệt qua và đổi tên gói của bạn thành một thứ khác. ví dụ.myBrokenTheme.tmp
Nếu điều này giải quyết vấn đề của bạn
Sau đó, bạn cần đào sâu hơn một chút về phần nào của mẫu có vấn đề. Vì vậy, khôi phục gói của bạn và thử sau đây, thử nghiệm giữa mỗi.
Về cơ bản, quy trình là dần dần kích hoạt các thư mục khi bạn duyệt qua cây tệp - cho đến khi bạn có thể tìm thấy tệp vi phạm.
- Đổi tên thư mục bố trí thành
.tmp
- Đổi tên thư mục mẫu thành
.tmp
Sau đó, nếu mang lại một bản sửa lỗi, hãy đổi tên tất cả các tệp trong thư mục bố trí thành .tmp- (đối với người dùng SSH ls | xargs -I {} mv {} {}.tmphoặc rename 's/^/.tmp/' *)
Sau đó dần dần kích hoạt từng tệp 1 cho đến khi giải quyết.
Nếu điều này không giải quyết vấn đề của bạn
Có khả năng rằng thư mục base/defaulthoặc enterprise/defaultthư mục của bạn đã bị ô nhiễm - và được thay thế tốt nhất bằng phiên bản sạch đã biết.
Bạn có thể làm điều này bằng cách tải xuống bản dựng Magento sạch và thay thế các thư mục của bạn khi cần thiết. Thông qua SSH bạn có thể làm điều này:
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 .
Bạn cũng có thể tận dụng cơ hội đến diffhai thư mục nếu bạn muốn xác minh bất kỳ thay đổi nào.
diff -r base base.tmp
Lưu ý Phương pháp này sẽ gây ra nhiều lỗi hơn trong quá trình, vì sự phụ thuộc mô-đun chỉ ra sự tồn tại của các tệp cụ thể. Thật không may, mệnh của nó cho khóa học.
Vô hiệu hóa các mô-đun cục bộ
Theo mặc định, Magento định nghĩa PHP bao gồm đường dẫn để tải các lớp theo thứ tự sau
Local > Community > Core
Nếu một tệp trong Local - tải nó và không làm gì nữa.
Nếu một tệp trong cộng đồng - tải nó và không làm gì nữa.
Nếu một tập tin không thể được tìm thấy ở bất cứ nơi nào khác - tải nó từ lõi.
Một lần nữa, thay vì vô hiệu hóa các mô-đun thông qua bảng quản trị Magento, sẽ thực tế hơn khi thực hiện việc này ở cấp độ tệp.
Thông thường, để vô hiệu hóa mô-đun theo cách "phù hợp", bạn sẽ chỉnh sửa ./app/etc/modules/MyModule.xmltệp và cài đặt tương ứng <active>false</active>- tuy nhiên, điều này thực sự không ngăn một lớp tải.
Nếu một lớp khác mở rộng một lớp nhất định trong một mô-đun (bỏ qua mọi khai báo phụ thuộc Magento), nó sẽ vẫn được tải - bất kể tiện ích mở rộng có bị vô hiệu hóa hay không.
Vì vậy, một lần nữa, phương tiện tốt nhất để vô hiệu hóa một phần mở rộng là đổi tên thư mục.
Bắt đầu bằng cách vô hiệu hóa cục bộ
Chỉ cần đổi tên thư mục qua FTP hoặc sử dụng lệnh SSH sau đây
mv ./app/code/local{,.tmp}
Sau đó vô hiệu hóa cộng đồng
mv ./app/code/community{,.tmp}
Nếu vấn đề được giải quyết từ một trong hai
Sau đó, đó là một trường hợp hiểu được mô-đun cụ thể là lỗi bắt nguồn từ đâu. Như với ví dụ được đưa ra ở trên để chẩn đoán gói, quy trình tương tự được áp dụng.
Vì vậy, khôi phục thư mục X và thử các mục sau, kiểm tra giữa mỗi thư mục.
Về cơ bản, quy trình là dần dần kích hoạt từng thư mục (mô-đun) cho đến khi xảy ra lỗi
- Đổi tên tất cả các mô-đun trong thư mục thành
.tmp(cho người dùng SSH ls | xargs -I {} mv {} {}.tmphoặc rename 's/^/.tmp/' *)
- Dần dần kích hoạt từng mô-đun từng cái một, bằng cách xóa
.tmpkhỏi tên tệp
Nếu vấn đề không được giải quyết
Sau đó, có thể chính lõi bị ô nhiễm. Lõi PHP Magento chính bao gồm
./app/code/core
./lib
Vì vậy, một lần nữa, đổi tên các thư mục này và sao chép trong một biến thể sạch. Giả sử bạn đã tải xuống một phiên bản Magento sạch như trên, thông qua SSH, bạn có thể làm điều này:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Sau đó, nếu vấn đề vẫn không được giải quyết, thay thế libthư mục quá
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
Tại thời điểm này, cửa hàng Magento của bạn sẽ không có gì khác hơn là cài đặt vanilla với cơ sở dữ liệu được sửa đổi.
Một số mô hình thực sự vẫn được lưu trữ trong cơ sở dữ liệu (Ví dụ: tăng thứ tự) - vì vậy tại thời điểm này, nó trở thành một trường hợp thực hiện thủ công các chỉnh sửa đó. Cho đến nay, tất cả các bước trên đã có thể đảo ngược mà không có thiệt hại lâu dài. Nhưng nếu chúng ta cũng đang nhập một cơ sở dữ liệu Magento sạch - nó có thể chứng minh không thể đảo ngược (thiếu khôi phục bản sao lưu).
Hướng dẫn ở trên phục vụ để giúp bạn xác định lỗi; không sửa lỗi kết quả.
Nội dung sẵn sàng có nguồn gốc từ www.sonassi.com/ledgeledge-base/magento-debug- Process và www.sonassi.com/ledgeledge-base/stop-magento-permissions-errors-permanently
