Comments 15
Хорошо, что конфиги кэшируются. Вот здесь материал с MageConf, еще где то видео было.
Вот именно поэтому пользоваться магентой при всей её мощи просто невозможно…
Еще одна интересная особенность. Бытует мнение, что имя файла, декларируещего модуль в системе, должно быть таким же как имя модуля или CompanyName_All.xml. Но это далеко не так. Файл может называться хоть Вася_Пупкин.xml Главное чтобы содержимое файла было правильным
Было бы интересно почитать про опыт оптимизации: Nginx вместо Apache, percona, memcached, varnish…
На самом деле все не так. Надо было просто внимательнее посмотреть код метода Mage_Core_Model_Config::init()
Порядок такой:
1 — загрузка всех app/etc/*.xml
2 — загрузка app/etc/local.xml
3 — загрузка всех app/etc/modules/*.xml
4 — загрузка config.xml config.{resource_name}.xml из etc папок активных модулей в порядке их зависимости
5 — загрузка app/etc/local.xml (сделанно для того что бы никакой модуль или левый конфиг не убил ничего из предыдущей загрузки local.xml, так как все конфиги мерджатся в один xml)
6 — загрузка конфигов из базы данных
Порядок такой:
1 — загрузка всех app/etc/*.xml
2 — загрузка app/etc/local.xml
3 — загрузка всех app/etc/modules/*.xml
4 — загрузка config.xml config.{resource_name}.xml из etc папок активных модулей в порядке их зависимости
5 — загрузка app/etc/local.xml (сделанно для того что бы никакой модуль или левый конфиг не убил ничего из предыдущей загрузки local.xml, так как все конфиги мерджатся в один xml)
6 — загрузка конфигов из базы данных
Так же стоит заметить что файлы из app/etc/*.xml не кешируються, так как параметры кеширования и подключений определенны именно в них.
Больше информации как всегда можно узнать только из кода )) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L248
Больше информации как всегда можно узнать только из кода )) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L248
На самом деле вы правы только в том, что больше информации можно получить только из исходников.
Если внимательно пройтись по коду, а еще лучше дебагером, то можно заметить что метод init вызывается только в 3 случаях:
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/cron.php#L67
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L270
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L370
Первый случай вообще рассматривать не будет, т.к. это процесс запуска по крону. (Причем для cron.php init запустится дважды)
Для второго случая метод github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L258 вызывается в двух случаях:
1) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L615 — вызывается только если свойсто app не определено (в случае cron.php это будет первый запуск)
2) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L640
В случае запуска страницы в браузере 1 сразу исключается т.к. github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L669 свойсто не будет равно null
2 будет отрабатывать только если массив $modules будет пустым
reinit тоже расписывать не буду когда и как вызывается.
В заключении можно сказать, что указанный вами метод init вызывается только при вызове Mage::app() или Mage::init с пустым массивом $modules
Эти методы обычно используются при написании сторонних php скриптов, запускающихся из терминала, либо кроном.
Я же в статье рассматрива метод run из index.php (т.е. стандартного метода запуска магазина), который запускает всю цепочку.
Если внимательно пройтись по коду, а еще лучше дебагером, то можно заметить что метод init вызывается только в 3 случаях:
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/cron.php#L67
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L270
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L370
Первый случай вообще рассматривать не будет, т.к. это процесс запуска по крону. (Причем для cron.php init запустится дважды)
Для второго случая метод github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L258 вызывается в двух случаях:
1) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L615 — вызывается только если свойсто app не определено (в случае cron.php это будет первый запуск)
2) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L640
В случае запуска страницы в браузере 1 сразу исключается т.к. github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L669 свойсто не будет равно null
2 будет отрабатывать только если массив $modules будет пустым
reinit тоже расписывать не буду когда и как вызывается.
В заключении можно сказать, что указанный вами метод init вызывается только при вызове Mage::app() или Mage::init с пустым массивом $modules
Эти методы обычно используются при написании сторонних php скриптов, запускающихся из терминала, либо кроном.
Я же в статье рассматрива метод run из index.php (т.е. стандартного метода запуска магазина), который запускает всю цепочку.
Согласен с методом init я промахнулся, корерктнее смотреть в Mage_Core_Model_App::run()
Но порядок вызова остаеться прежним
Mage_Core_Model_App::baseInit() — (пункт 1 и 2)
Mage_Core_Model_App::_initModules() — (пункты 3,4,5,6)
Это просто расширенная версия того же Mage_Core_Model_Config::init()
Но порядок вызова остаеться прежним
Mage_Core_Model_App::baseInit() — (пункт 1 и 2)
Mage_Core_Model_App::_initModules() — (пункты 3,4,5,6)
Это просто расширенная версия того же Mage_Core_Model_Config::init()
А чем ваши этапы отличаются от тех, что были описаны мной?
Я расписал процессы, Вы указали пункты… Смыслы то не поменялся.
Я расписал процессы, Вы указали пункты… Смыслы то не поменялся.
local.xml подключаеться дважды, local.xml не ищеться в папке модуля. Модули грузяться только те которые enabled. Загрузка конфига из базы данных. Статья мягко говоря не полная. Еще и какие то непонятные куски кода, зачем?
Если хотите расказать про работу конфига в magento, разберитесь как все работает, на каком этапе какие файлы подключаються. В каких файлах как можно влиять на конфиг. Как работает деректива extends. нарисуйте красивую сиквенс диаграмму, где будет виден порядок вызовов. Так же стоит описать какие части конфига кешируються. И не стоит забивать на cron и shell скрипты, так как без них маджента работать не будет, и стоит упомянуть что там конфиг инициализируеться по другому.
Если хотите расказать про работу конфига в magento, разберитесь как все работает, на каком этапе какие файлы подключаються. В каких файлах как можно влиять на конфиг. Как работает деректива extends. нарисуйте красивую сиквенс диаграмму, где будет виден порядок вызовов. Так же стоит описать какие части конфига кешируються. И не стоит забивать на cron и shell скрипты, так как без них маджента работать не будет, и стоит упомянуть что там конфиг инициализируеться по другому.
Мне жаль, что вам не понятны эти куски кода…
На счет local.xml вы правы, это я не доглядел в статье. Он грузится из папки app/etс дважды, дабы магазин работал всегда. Обусловлено это тем, что все грузиться в единую древовидную структуру.
Увидим ли мы ваши статьи с «красивыми сиквенс диаграммами» и прочими красотулями?
На счет local.xml вы правы, это я не доглядел в статье. Он грузится из папки app/etс дважды, дабы магазин работал всегда. Обусловлено это тем, что все грузиться в единую древовидную структуру.
Увидим ли мы ваши статьи с «красивыми сиквенс диаграммами» и прочими красотулями?
вы еще вторую версию не видели, с обджект менеджером, декораторами на любой метод и пр.
Sign up to leave a comment.
Magento. Процесс загрузки конфигурационных файлов