Magento. Процесс загрузки конфигурационных файлов

[karser]

Хорошо, что конфиги кэшируются. Вот здесь материал с MageConf, еще где то видео было.

[Den4ik_k]

Интересная презентация. Раньше не встречал ее

[datacompboy]

Вот именно поэтому пользоваться магентой при всей её мощи просто невозможно…

[Den4ik_k]

Еще одна интересная особенность. Бытует мнение, что имя файла, декларируещего модуль в системе, должно быть таким же как имя модуля или CompanyName_All.xml. Но это далеко не так. Файл может называться хоть Вася_Пупкин.xml Главное чтобы содержимое файла было правильным

[entze]

Было бы интересно почитать про опыт оптимизации: Nginx вместо Apache, percona, memcached, varnish…

[fear86]

На самом деле все не так. Надо было просто внимательнее посмотреть код метода 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 — загрузка конфигов из базы данных

[fear86]

Так же стоит заметить что файлы из app/etc/*.xml не кешируються, так как параметры кеширования и подключений определенны именно в них.

Больше информации как всегда можно узнать только из кода )) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L248

[Den4ik_k]

На самом деле вы правы только в том, что больше информации можно получить только из исходников.
Если внимательно пройтись по коду, а еще лучше дебагером, то можно заметить что метод 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 (т.е. стандартного метода запуска магазина), который запускает всю цепочку.

[fear86]

Согласен с методом 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()

[Den4ik_k]

А чем ваши этапы отличаются от тех, что были описаны мной?
Я расписал процессы, Вы указали пункты… Смыслы то не поменялся.

[fear86]

local.xml подключаеться дважды, local.xml не ищеться в папке модуля. Модули грузяться только те которые enabled. Загрузка конфига из базы данных. Статья мягко говоря не полная. Еще и какие то непонятные куски кода, зачем?

Если хотите расказать про работу конфига в magento, разберитесь как все работает, на каком этапе какие файлы подключаються. В каких файлах как можно влиять на конфиг. Как работает деректива extends. нарисуйте красивую сиквенс диаграмму, где будет виден порядок вызовов. Так же стоит описать какие части конфига кешируються. И не стоит забивать на cron и shell скрипты, так как без них маджента работать не будет, и стоит упомянуть что там конфиг инициализируеться по другому.

[Den4ik_k]

Мне жаль, что вам не понятны эти куски кода…
На счет local.xml вы правы, это я не доглядел в статье. Он грузится из папки app/etс дважды, дабы магазин работал всегда. Обусловлено это тем, что все грузиться в единую древовидную структуру.
Увидим ли мы ваши статьи с «красивыми сиквенс диаграммами» и прочими красотулями?

[fear86]

Врядли, для написания качественных статей, одних технических навыков не достаточно :)

[greengarlic]

вы еще вторую версию не видели, с обджект менеджером, декораторами на любой метод и пр.

[Den4ik_k]

Да, со второй версией тоже уже игрался, и думаю ее тоже освещать буду