Comments 22
Отличная статья, спасибо!
Думаю, что это кому-то поможет в разработке расширений для Magento, потому что система и впрямь непроста.
Думаю, что это кому-то поможет в разработке расширений для Magento, потому что система и впрямь непроста.
0
Если претендуете на основательность, то нужно было указать, что добавлять что-то в
app/design/frontend/base/*
skin/frontend/base/*
нехорошо, нужно создавать собственную тему и пакет для неё
app/design/frontend/base/*
skin/frontend/base/*
нехорошо, нужно создавать собственную тему и пакет для неё
0
В base/default кидать действительно не рекомендуется, потому что:
1) Это просто плохой стиль, так как эта папка предназначена для хранения основной темы, а не для изменений в ней.
2) До версии 1.4 такой папки просто не существовало, а некоторые магазины до сих пор сидят на 1.3.
Но по теме на каждый модуль это как-то слишком много тем получается. Обычно всё кладётся в default/default. Во всяком случае все модули, которые я видел, так делают.
1) Это просто плохой стиль, так как эта папка предназначена для хранения основной темы, а не для изменений в ней.
2) До версии 1.4 такой папки просто не существовало, а некоторые магазины до сих пор сидят на 1.3.
Но по теме на каждый модуль это как-то слишком много тем получается. Обычно всё кладётся в default/default. Во всяком случае все модули, которые я видел, так делают.
+1
Согласен, что для каждого модуля своя тема — это жирно =) Однако упомянуть о назначении base каталогов стоило
+1
Base это то место где система будет искать шаблоны если не найдет в текущем пакете, тоесть если у магазина настроенно 20 тем (или пакетов), и наш модуль должен одним кликом установится и работать, то ему место именно в base. Собственно с версии 1.4 ее для этого и создали.
+1
Спасибо, конечно, буду иметь в виду. Вам как разработчику системы виднее, но, на мой взгляд, пока что самый лучший выход для обеспечения совместимости с 1.3 это всё-таки default/default. Кстати, зачем её вообще оставили, если её функции теперь выполняет base/default?
0
Base/default — это базовые шаблоны для фронтенда, не привязанные к какой либо теме (скелет), а default/default это уже тема, если посмотреть внимательней то можно увидить, что все скины (css, images, js) находятся в default/default. Раньше все было в default/default, что как бы не совсем логично :)
По поводу совместимости, если мне память не изменяет, система пытается грузить шаблоны в таком порядке:
v1.4
1 — maPackage/myTheam
2 — maPackage/default
3 — base/default
v1.3
1 — maPackage/myTheam
2 — maPackage/default
3 — default/default
То есть кладя файлы в default/default мы потеряем совместимость для версии 1.4+ c кастомной темой.
Вот такие пироги :)
По поводу совместимости, если мне память не изменяет, система пытается грузить шаблоны в таком порядке:
v1.4
1 — maPackage/myTheam
2 — maPackage/default
3 — base/default
v1.3
1 — maPackage/myTheam
2 — maPackage/default
3 — default/default
То есть кладя файлы в default/default мы потеряем совместимость для версии 1.4+ c кастомной темой.
Вот такие пироги :)
+1
Спасибо! Статья отличная.
А будет статья о том как создать свой модуль для вывода в админке и редактирования какого нибудь контента? например свой новостной модуль?
А будет статья о том как создать свой модуль для вывода в админке и редактирования какого нибудь контента? например свой новостной модуль?
0
Ну, статей мало потому что не у всех есть возможность их выкладывать :)
А статья замечательная.
Про хелпер не совсем точно — если его не вызывать и не объявлять в XML то в файле нет необходимости. Вроде в 1.3 и 1.5 так работает.
Так же отдельные модули лучше включать не в etc/modules/Mage_All.xml, а создав отдельный файл для модуля в котором мы его включаем. Тогда его можно устанавливать копированием всех файлов модуля.
А статья замечательная.
Про хелпер не совсем точно — если его не вызывать и не объявлять в XML то в файле нет необходимости. Вроде в 1.3 и 1.5 так работает.
Так же отдельные модули лучше включать не в etc/modules/Mage_All.xml, а создав отдельный файл для модуля в котором мы его включаем. Тогда его можно устанавливать копированием всех файлов модуля.
+1
Хелпер Data.php нужен, если предполагается использовать переводы. Если не предполагается ни переводить, ни использовать хелперы, то можно, по-моему, не «заводить» его.
0
Огромное спасибо за статью, очень много информации о кишочках этой CMS. Крайне полезно для тех, кто задумывается, стоит ли её изучать и стоит ли делать на ней сайты.
Собственно,
Еще раз спасибо, вы сэкономили кучу времени многим людям.
Собственно,
перед отображением страницы Magento парсит все .xml-файлы из папки layout— `nuff said
Еще раз спасибо, вы сэкономили кучу времени многим людям.
0
После полутора лет эксплуатации Magento нет ни малейшего желания продолжать развивать магазин на этой платформе.
Изначально подкупает наличие великолепной многослойной навигацией в стоке. А потом понимаешь, что ради этой функции не стоит получать столько гемороя во всем остальном.
Изначально подкупает наличие великолепной многослойной навигацией в стоке. А потом понимаешь, что ради этой функции не стоит получать столько гемороя во всем остальном.
0
Следует понимать, что для Magento порог вхождения довольно высок. Статья хорошая и понятная. Спасибо.
0
Есть еще вот такой бесплатный инструмент для разработчика:
www.mgt-modules.com/magento-developertoolbar/
www.mgt-modules.com/magento-developertoolbar/
0
Sign up to leave a comment.
Поэтапное создание расширения для Magento на примере debug-консоли