Отладка - это что-то вроде искусства, но с этим можно легко справиться, следуя простому режиму.
Следуйте каждому пункту, пока, наконец, не найдете решение.
Включить ошибки PHP
Это ключ к большинству вопросов. В целях безопасности или по другим причинам отображение ошибок PHP может быть отключено по умолчанию в вашей конфигурации PHP.
Вы можете включить ошибки с более постоянным решением или просто что-то более временное.
Постоянное решение
Для пользователей Apache / mod_php
В .htaccessфайле корня вашего документа - просто поместите это вверху.
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
В вашей конфигурации виртуального хоста Nginx, либо в конечной location .php {директиве, либо в fastcgi_paramsфайле (если он указан)
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;
Временное / Универсальное решение
Для любой платформы
Отредактируйте загрузчик Magento index.phpв корневом каталоге вашего документа и раскомментируйте следующую строку:
#ini_set('display_errors', 1);
Включить режим разработчика
Когда у вас возникла ошибка, и вы внезапно нажали на страницу «Отчет об ошибке», и вам была дана, казалось бы, бесполезная строка с ошибкой вроде 1184257287824- у вас есть несколько вариантов.
Постоянное решение
Для пользователей Apache / mod_php
В корневой .htaccessфайл вашего документа - просто поместите это вверху.
SetEnv MAGE_IS_DEVELOPER_MODE true
Для пользователей Nginx / fastcgi
В вашей конфигурации виртуального хоста Nginx, либо в конечной location .php {директиве, либо в fastcgi_paramsфайле (если он указан)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Временное / Универсальное решение
Отредактируйте загрузочную версию Magento index.phpв корневом каталоге вашего документа и либо сделайте ifутверждение всегда верным, либо включите его для вашего конкретного IP-адреса.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
или же
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Проверьте ваши разрешения
Неправильные разрешения вызовут массу проблем, многие из которых не так легко найти на первый взгляд.
Например.
Если PHP не может записать в ./mediaкаталог, и у вас включено объединение JS - Magento не может сгенерировать объединенный файл и связанный уникальный URI для носителя. Таким образом, вместо того, что вы найдете в исходном коде вашего браузера, это полный путь сервера к медиа-файлу
/home/path/public_html/media/xxx
В противном случае сайт может функционировать как обычно - без видимых критических ошибок.
Пожалуйста, имейте в виду, что эта практика безопасна для выделенного хостинга, но может представлять проблемы безопасности с общим хостингом, если процесс Apache не привязан к каждому пользователю.
В нашем примере пользователь SSH / FTP - sonassiэто пользователь Apache, apacheа группа -apache
Добавьте пользователя FTP / SSH в группу Apache
Самое главное, мы должны убедиться, что пользователь FTP / SSH входит в группу Apache, в нашем примере это ее apache(но также обычно www-data)
usermod -a -G apache sonassi
Добавляйте в группу столько пользователей, сколько у вас есть для FTP / SSH.
Сбросить исходные разрешения
Итак, прежде чем мы начнем, давайте удостоверимся, что все разрешения правильны.
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 {} \;
Делать изменения постоянными
ACL и Sticky Bits
ACL в Linux позволяют нам определять конкретные правила, в нашем случае, какие файлы разрешений должны наследоваться при создании. Липкий бит (упомянутый выше) заботится о группе наследования, но не помогает с правами, и именно поэтому мы используем ACL.
Начните с включения поддержки ACL на активном разделе, убедитесь, что ваше ядро скомпилировано с поддержкой ACL .
Ваш раздел может быть /, /home, /varили что - то другое, заменить в случае необходимости.
mount -o remount,acl /home
Теперь ACL включены, мы можем установить правила ACL и группировать липкие биты:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Но у меня нет поддержки ACL
Если ваше Ядро не поддерживает ACL, вы также можете использовать umask(это настройка времени выполнения для BASH, FTP и PHP), чтобы установить разрешения для файлов по умолчанию. Magento обычно устанавливает umask(0)в index.php, однако, это было бы в ваших интересах , чтобы изменить это.
В вашем index.phpизменении umaskстрока должна быть
umask(022);
И в вашей среде BASH для SSH, установите это либо в вашем .bashrcили.bash_profile
umask 022
Для вашего FTP-сервера вам необходимо прочитать документацию к нему, но принцип тот же.
Восстановить тему по умолчанию
Вполне возможно, что ваша тема или пакет отвечает за эту проблему. Возвращаясь к ванильной теме Magento - это быстрый способ выяснить это.
** Это связано с оговоркой, что некоторые модули могут зависеть от определенных функций темы *
Вместо того, чтобы что-либо менять через панель администратора, гораздо проще просто переименовать нарушающие каталоги.
Через SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
Или через ваш FTP-клиент, пройдите и переименуйте ваш пакет во что-то другое. например.myBrokenTheme.tmp
Если это решит вашу проблему
Затем вам нужно немного покопаться в том, какая часть шаблона проблематична. Так что восстановите ваш пакет и попробуйте следующее, тестируя между ними.
По сути, процесс состоит в том, чтобы постепенно включать каталоги при прохождении по дереву файлов - пока вы не найдете файл, нарушающий работу.
- Переименуйте каталог макета в
.tmp
- Переименуйте каталог шаблона в
.tmp
Затем, если любой из них приведет к исправлению, переименуйте все файлы в каталоге макета в .tmp- (для пользователей SSH ls | xargs -I {} mv {} {}.tmpили rename 's/^/.tmp/' *)
Затем постепенно включите каждый файл 1 на 1 до разрешения.
Если это не решит вашу проблему
Существует вероятность того, что ваши каталоги base/defaultили enterprise/defaultкаталоги были заражены - и их лучше заменить известной чистой версией.
Вы можете сделать это, загрузив чистую сборку Magento и при необходимости заменив каталоги. Через SSH вы можете сделать это:
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 .
Вы также можете воспользоваться возможностью для diffдвух каталогов, если вы хотите проверить какие-либо изменения.
diff -r base base.tmp
NB. Этот метод вызовет больше ошибок во время процесса, так как зависимость от модуля диктует существование определенных файлов. К сожалению, его номинал для курса.
Отключить локальные модули
По умолчанию Magento определяет путь включения PHP для загрузки классов в следующем порядке
Local > Community > Core
Если файл находится в Local - загрузите его и больше не делайте.
Если файл находится в сообществе - загрузите его и не делайте больше.
Если файл не может быть найден где-либо еще - загрузите его из ядра.
Опять же, вместо того, чтобы отключать модули через админ-панель Magento, это более практично делать на уровне файлов.
Как правило, чтобы отключить модуль «правильным» способом, вы должны отредактировать соответствующий ./app/etc/modules/MyModule.xmlфайл и установить его <active>false</active>- однако это не мешает загрузке класса.
Если другой класс расширяет данный класс в модуле (игнорируя любые объявления зависимостей Magento), он все равно будет загружен - независимо от того, отключено ли расширение или нет.
Итак, еще раз, лучший способ отключить расширение - переименовать каталог.
Начните с отключения локальной
Просто переименуйте каталог через FTP или используйте следующую команду SSH
mv ./app/code/local{,.tmp}
Затем отключите сообщество
mv ./app/code/community{,.tmp}
Если проблема решена из
Тогда это пример понимания того, из какого модуля произошла ошибка. Как и в примере, приведенном выше для диагностики упаковки, применяется тот же процесс.
Поэтому восстановите каталог X и попробуйте выполнить следующее, тестируя между ними.
По сути, процесс состоит в том, чтобы постепенно включать каталоги (модули) по одному, пока ошибка не возникнет снова.
- Переименуйте все модули в каталоге в
.tmp(для пользователей SSH ls | xargs -I {} mv {} {}.tmpили rename 's/^/.tmp/' *)
- Постепенно включите каждый модуль по отдельности, удалив
.tmpиз имени файла
Если проблема не решена
Тогда возможно, что само ядро загрязнено. Основное ядро Magento PHP состоит из
./app/code/core
./lib
Итак, еще раз, переименуйте эти каталоги и скопируйте в чистом варианте. Предполагая, что вы уже загрузили чистую версию Magento, как указано выше, через SSH, вы можете сделать это:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Тогда, если проблема все еще не решена, замените libкаталог тоже
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
На этом этапе ваш магазин Magento будет не более чем простой установкой с измененной базой данных.
Некоторые модели на самом деле все еще хранятся в базе данных (например, приращение порядка) - поэтому на данном этапе это становится случаем ручного внесения этих изменений. До сих пор все вышеперечисленные шаги были обратимыми без какого-либо длительного ущерба. Но если бы мы импортировали чистую базу данных Magento - это могло бы стать необратимым (если не считать восстановления резервной копии).
Приведенное выше руководство поможет вам обнаружить ошибку; не исправить полученную ошибку.
Контент охотно получен от www.sonassi.com/knowledge-base/magento-debug-process и www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently
