Налагодження - це трохи мистецтво, але те, що можна легко освоїти, дотримуючись простого режиму.
Дотримуйтесь кожного пункту, поки нарешті не знайдете рішення.
Увімкнути помилки 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 virtualhost, або в кінцевій 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 virtualhost, або в кінцевій 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 та липкі шматочки
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
Якщо файл знаходиться в локальному - завантажте його і більше не робіть.
Якщо файл знаходиться у спільноті - завантажте його і більше не робіть.
Якщо файл не можна знайти більше ніде - завантажте його з ядра.
Знову, замість того, щоб відключити модулі через адміністративну панель 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з імені файлу
Якщо питання не вирішено
Тоді можливо, саме ядро забруднене. Основне ядро PHP Magento складається з
./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
