Основы отладки хранилища Magento

magento.stackexchange https://magento.stackexchange.com/questions/428

  •  16-10-2019
  •  | 
  •  

Вопрос

Как я могу отладить свой магазин Magento

Сейчас этот вопрос не слишком актуален для нас, но если бы сайт Magento SE существовал 5 лет назад, это, вероятно, был бы наш первый вопрос.Для тех, кто только начинает работать с Magento или незнаком с ним - знание основ отладки может стать ключом к устранению причины проблем.И, несмотря на его неуместность для нас, сейчас мы предотвращаем появление этого вопроса с помощью подхода, предполагающего самостоятельный ответ.

Помогите, мой сайт не работает!

  1. Виноват ли мой дизайн?
  2. Виноват ли сторонний модуль?
  3. Почему я не вижу ошибку?

На каждый из этих вопросов можно легко ответить, следуя стандартному подходу к отладке, который под силу даже самым простым пользователям.Посредством процесса устранения основ отладки хранилища Magento.

Это было полезно?

Решение

Отладка - это своего рода искусство, но им можно легко овладеть, следуя простому режиму.

Следуйте каждому пункту, пока, наконец, не придете к решению.

Включить Ошибки 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 combine - 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 {} \;

Внесение изменений на постоянной основе

Списки управления доступом и липкие биты

Списки управления доступом в Linux позволяют нам определять конкретные правила, в нашем случае, какие разрешения файлы должны наследовать при создании.A липкий кусочек (упоминается позже) заботится о групповом наследовании, но не помогает с разрешениями, именно поэтому мы используем списки управления доступом.

Начните с включения поддержки 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

Если ваше ядро не поддерживает списки управления доступом, вы также можете использовать 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

Если это решит вашу проблему

Затем вам нужно копнуть немного глубже относительно того, какая часть шаблона является проблемной.Поэтому восстановите свой пакет и попробуйте выполнить следующее, проводя тестирование между каждым из них.

По сути, процесс заключается в постепенном включении каталогов по мере продвижения вниз по файловому дереву - до тех пор, пока вы не сможете найти файл-нарушитель.

  1. Переименуйте каталог макета в .tmp
  2. Переименуйте каталог шаблонов в .tmp

Затем, если любой из них приведет к исправлению, переименуйте все файлы в каталоге layout в .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

ПРИМЕЧАНИЕ.Этот метод вызовет больше ошибок во время процесса, поскольку зависимость от модуля диктует существование определенных файлов. К сожалению, это в порядке вещей.

Отключить локальные модули

По умолчанию Magento определяет PHP include path для загрузки классов в следующем порядке

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 и попробуйте выполнить следующее, проводя тестирование между каждым из них.

По сути, процесс заключается в постепенном включении каталогов (модулей) один за другим до тех пор, пока ошибка не возникнет повторно

  1. Переименуйте все модули в каталоге в .tmp (для пользователей SSH ls | xargs -I {} mv {} {}.tmp или rename 's/^/.tmp/' *)
  2. Постепенно включайте каждый модуль один за другим, удаляя .tmp из имени файла

Если проблема не будет решена

Тогда, возможно, загрязнена сама сердцевина.Основное ядро Magento PHP состоит из

./приложение/код/ядро
./библиотека

Итак, еще раз переименуйте эти каталоги и скопируйте в чистом варианте.Предполагая, что вы уже загрузили чистую версию 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

Другие советы

В качестве запрошен в Твиттере а также обсуждается на мета Я начну здесь учебник отладки для не-дев.

Сначала я думаю, что (даже Magento пытается привлечь это) Magento слишком сложный для торговца без разработчика/команды разработчиков. Но если вы смелые и хотите попробовать, мы даем все возможное, чтобы помочь вам. Я думаю, что для некоторых вопросов граница между "Как я могу это сделать?" И «Пожалуйста, сделайте мою работу, я слишком глуп, чтобы Google This» - это довольно тонкая грань. Я понимаю, что это часто трудно, чтобы Google думал, потому что вы не знаете, для чего вы гуглите, потому что вы еще не знаете именование. Тем не менее, давайте заберем вещи, которые могут сделать все с магазином Magento, даже вы (ы) он не разработчики.

Очень хороший ответ, как отлаживать Magento, когда вы хотите испачкаться уже дал Сонасси, но я стараюсь добавить вещи и копировать то, что я думаю, применимо для торговцев.

Отказ от ответственности: все каталоги и файлы, упомянутые в этом посте, относятся к папке Magento Root, которая может быть в /var/www Но в зависимости от провайдера хостинга, ваш так называемый корень документа может быть везде, спросите своего провайдера, если вы не найдете свой Magento!

Режим разработки

Вы хотите иметь реальные ошибки, не так дерьмо "произошла ошибка" Страница, которую Magento обеспечивает нормально.http://www.fontis.com.au/blog/magento/custom-magento-error-page

Благодаря fontis.com для этого изображения.

Отчеты, упомянутые на странице, можно найти в var/reports/<the_number>

Когда вы активируете режим разработки, Magento вызывает реальную ошибку, эти ошибки могут особенно утекать учетные данные, например, для базы данных! Итак, подумайте, прежде чем включить его на производственные серверы!

Откройте свой index.php Файл в корневой папке Magento, в зависимости от версии, вы найдете эти строки вокруг строки 73:

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

#ini_set('display_errors', 1);

Для активности сейчас режим, вы должны изменить эти линии.

Если вы знаете свой IP -адрес (Большинство людей получают новый каждые 24 часа, по крайней мере, в Германии), Google помогает вам здесь:

Ваш общедоступный IP -адрес 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 по каким -либо причинам, вы можете показать ошибки для всех.

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

логирование

Magento регистрирует много вещей в два файла:

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

Исключения всегда регистрируются. Журнал системы должен быть включен в бэкэнд: 

System > Configuration > Developer > Log

enter image description here

Установлен Enabled да, и вы видите больше ошибок и отладки в сообщениях system.log И в exception.log

Это проблема темы?

У вас есть собственная тема, это настроено в Backend здесь:

Система> Конфигурация> Проектирование

enter image description here

Благодаря kb.magenting.com для изображения

Здесь вы можете настроить пакет и тему. Если вы хотите попытаться воспроизвести ошибку в теме по умолчанию, удалите все с полей ввода. Затем нажмите «Сохранить», и вы Смотрите стандартную тему Magento, как в демонстрационном магазине, если у вас есть магазин до 1.8, вы можете найти выстрел в экране в Руководство пользователя Magento Community Edition

Если вы не можете воспроизвести проблему в теме по умолчанию, ваша тема сломана, пожалуйста, свяжитесь с поставщиком темы. Мы не оказываем поддержкой третьих лиц, особенно коммерческих.

Что теперь?

Вы нашли реальную ошибку, можно воспроизвести, она воспроизводима в теме по умолчанию? Отлично, пожалуйста, откройте вопрос, и мы даем все возможное, чтобы помочь.

В вопросе:

  • Опишите, что вы делаете
  • Какая ошибка поднята
  • Что -нибудь в файлах журнала?
  • Может быть, выстрел в экране ошибки
  1. Прежде всего, вы должны включить режим разработчика
  2. Вы также можете включить ошибки в index.php: ini_set ('display_errors', 1);
  3. Скомпилируйте расширение XDEBUG с любой умной IDE (PHPSTROM/ECLIPSE)
  4. Отключить модуль пользовательских и третьих сторон
  5. Просмотрите свое исключение и журнал ошибок, разрешите перечисленные ошибки в журнале исключений
  6. Проверьте расширение Curl и McRypt, должно быть загружено на ваш сервер
  7. Проверьте папку и файлы разрешения chown -r sonassi: apache/home/public/public_html/find/home/public/public_html/-type d -exec chmod 775 {} ; Найти/home/public/public_html/-type f -exec chmod 664 {} ;
  8. Обновите разрешение на каталорию носителя и VAR 0777, если не установлено
  9. Start IDE (PHPSTROM), затем установите начальные точки отладчика на index.php 10. Пресс -ф8 и перейдите дальше, пока не получите ошибку

Для использования выше, вы должны определенно получить ошибки.

Отладка Backtrace

Это хорошая функция для отладки вызова функции в Magento.

Добавьте эту функцию income/config.php или создайте новый файл и поместите все общие используемые функции PHP.

function back_trace($exit = true) {
  $call_back_methods = '';
  $call_back_methods .= '';
  $call_back_methods .= 'S.N.Function NameLine NumberFile Name';

  $counter = 1;
  foreach (debug_backtrace() as $index => $data) {
    //if (0 == $index) continue;

    $call_back_methods .= '' . $counter++ . '';
    $call_back_methods .= '' . $data['function'] . '';
    $call_back_methods .= '' . $data['line'] . '';
    $call_back_methods .= '' . $data['file'] . '';
  }

  $call_back_methods .= '';

  print $call_back_methods;

  if (true == $exit) exit;
}

Вывод будет

enter image description here

Лицензировано под: CC-BY-SA с атрибуция
Не связан с magento.stackexchange
scroll top