Коварная война россии против Украины. Ориентировочные потери врага
(по состоянию на 02.12.2024)
743920
солдат
369
самолетов
329
вертолетов
9478
танков
19397
ББМ
20953
артиллерия
1019
ПВО
1253
РСЗО
30606
машин
28
корабли и катера
Основы Magento – файлы макета
Опубликовано Обновлено: 08.08.2016

Основы Magento – файлы макета

 

 

В данной статье мы будем рассматривать основы XML макета Magento.

Мы будем использовать файл local.xml и сделаем некоторые основные изменения. Изменения будут включать в себя добавление и удаление скриптов, удаление блоков и добавление обновления макета.

Теперь, когда у нас есть базовое понимание логики дизайна для Magento, мы углубимся в этот вопрос немного больше и объясним шаблонные файлы.

Файлы шаблона размещаются в следующих двух подкаталогах:

  • Макет: app/design/frontend/<название_пакета>/<название_темы>/layout/
  • Шаблон: app/design/frontend/<название_пакета>/<название_темы>/template/

Я разделю рассмотрение этой темы на отдельные статьи. Сегодня мы будем рассматривать только аспект макетов. Аспекты шаблонов мы рассмотрим в следующей статье.

Прежде чем мы начнем что-то делать с макетами, нам нужно сделать одну важную вещь, — отключить кэш Magento. Это позволит нам просматривать изменения немедленно, вместо того, чтобы обновлять кэш каждый раз, когда мы делаем маленькие изменения. В идеале кэш должен быть выключен все время в процессе разработки сайта. Чтобы выключить кэш, зайдите в панель администрирования сайта и перейдите в меню Система > Управление кэшем и отключите все типы кэша.

Теперь давайте начнем.

 

Макет

Папка layout любой темы содержит XML-файлы, которые в значительной степени определяют то, что отображается во фронтенде магазина. Структура макетов в Magento достаточно сложная, но это одна из причин того, что делает движок таким мощным и гибким.

Вы найдете сотни файлов XML, каждый из которых делает свое дело, каждый Вид или Модуль в app/code/ имеет свой макет, определенный своим собственным файлом XML. Если вы когда-нибудь устанавливали сторонний модуль на свой магазин, и он влиял на фронтенд сайта, — без сомнения у этого модуля есть свой собственный файл XML.

Но как мне узнать, какой именно XML-файл мне нужно редактировать?

Для этого служит соглашение об именовании файлов, которое облегчает процесс отслеживания файла, когда вам нужно что-то изменить. Например, модуль Magento app/code/core/Mage/Page/ имеет свой собственный XML файл с именем app/design/frontend/base/default/layout/page.xml и как вы можете видеть, здесь уже прослеживается определенная схема! После того как вы ознакомитесь с вопросом и сделаете несколько магазинов, очень скоро вы заметите определенную повторяемость, что напомнит вам, какие файлы нужно редактировать.

Примечание: Обратите внимание на модули сторонних разработчиков, так как технически разработчик может называть свои XML-файлы как ему заблагорассудится. В этом случае, если это не описано в документации модуля, вам придется отследить имя файла внутри самого модуля, который обычно находится в файле config.xml.

Также обратите внимание, что не все модули имеют файл XML. Как правило, файл XML будет доступен только если он влияет на фронтенд магазина.

Путь к настройкам модуля: app/code/local/<пространство_имен>/<название_модуля>/etc/config.xml

Обратите внимание, ниже я ссылаюсь на  base/default, помните, что это место, где находятся основные файлы движка; если вам нужно внести изменения, всегда копируйте их в свою собственную область пакет/тема и никогда не редактируйте base/default файлы.

Например файл:

app/design/frontend/base/default/layout/page.xml

копируйте в:

app/design/frontend/<название_пакета>/<название_темы>/layout/page.xml

Сложные изменения этих файлов требуют опыта, а эта статья для начинающих, что выходит за рамки данной серии; но я буду работать с файлом local.xml и опишу, как это связано с разработкой собственной темы, а также приведу пример несколько основных модификаций которые, как я думаю, будут вам полезны.

 

Что такое local.xml?

Проще говоря, это файл, который размещается в папке макета нашей темы, который содержит большую часть наших модификаций или обновлений макетов XML для этой темы. Использование этого файла считается хорошей практикой и Magento рекомендует его. Мы могли бы сравнить этот файл, как Magento версию файла functions.php для WordPress.

Подождите, «большая часть», — а почему не «все части» наших модификаций или обновлений?

Существует много дискуссий на эту тему, и если бы мы сделали несколько исследований, мы нашли бы в каждой мысли свое рациональное зерно. Некоторые скажут, что они используют только local.xml, другие – что они редактируют во всех сопутствующих файлах; поэтому выберите для себя свой путь.

Лично я считаю, что этот файл – отличное место для небольших модификаций, таких как добавление блоков, удаление блоков или изменения шаблонов. Этот файл не годится для того, чтобы полностью обновить макет страницы товара или чего-то подобного; если вы хотите сделать такое, делайте это в соответствующем файле, например, catalog.xml

Да, это может сэкономить нам немного времени, когда мы обновляем Magento, поскольку все наши правки содержатся в одном файле, но хранение всех наших изменений в одном отдельном файле может привести к головным болям, когда мы захотим переопределить другие файлы XML.

Итак, как настроить этот файл…

Создайте файл local.xml внутри папки layout вашей темы app/design/frontend/<название_пакета>/default/layout/local.xml и добавьте небольшую основную структуру макета файла XML:

 

<?xml version="1.0"?>
<!--
/*
 * Название Магазина
 * URL Магазина
 *
 * @description  Модификации макета
 * @author       Имя автора
 * @package      packagename_default
 *
 */
-->
<layout version="0.1.0">
    <!-- Наши модификации будут здесь -->
</layout>

 

 

Теперь, когда у нас есть свой готовый файл, я покажу вам несколько распространенных методов.

1. Добавление и удаление скриптов / файлов стилей

Это очень распространенная модификация для добавления или удаления JavaScript и CSS. Если вы работаете с библиотекой jQuery, вы должны таким образом подключать ее, так же как и любые другие скрипты JavaScript.

Если мы просмотрим папки сразу после инсталляции Magento, мы увидим целый букет файлов JavaScript, большую массу из которых мы не будем использовать. В этом случае такие файлы должны быть удалены (или отключены), чтобы не создавать лишние http запросы – Magento не слишком быстрый, поэтому это должно быть сделано в первую очередь!

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

Я представлю два дескпритора макета, <default> и <cms_index_index>. Конечно, их гораздо больше, но сейчас давайте сосредоточимся на этих простых.

Дескриптор <default> — это глобальный дескриптор и он затронет все страницы, а дескриптор <cms_index_index> — повлияет только на главную страницу сайта.

Теперь перейдем к коду.

 

<?xml version="1.0"?>
<layout version="0.1.0">
    <default>
        <reference name="head">
            <!-- Локальное подключение библиотеки jQuery -->
            <action method="addItem"><type>skin_js</type><name>js/libs/jquery.min.js</name></action>
 
            <!-- Подключение библиотеки jQuery по CDN -->
            <block type="core/text" name="cdn.jquery">
                <action method="setText">
                    <text>
                        <![CDATA[
                        <script type="text/javascript" src="http://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
                        <script type="text/javascript">jQuery.noConflict();</script>
                        ]]>
                    </text>
                </action>
            </block>
 
            <!-- подключение некоторых скриптов (глобально) -->
            <action method="addItem"><type>skin_js</type><name>js/libs/modernizr.min.js</name></action>
            <action method="addItem"><type>skin_js</type><name>js/libs/html5shiv.min.js</name><params/><if>lt IE 9</if></action>
            <action method="addItem"><type>skin_js</type><name>js/libs/respond.min.js</name><params/><if>lt IE 9</if></action>
            <action method="addItem"><type>skin_js</type><name>js/libs/selectivizr.min.js</name><params/><if>lt IE 9</if></action>
 
            <!-- удаление (отключение) некоторых скриптов (глобально) -->
            <action method="removeItem"><type>skin_css</type><name>css/widgets.css</name></action>
            <action method="removeItem"><type>skin_css</type><name>css/print.css</name></action>
            <action method="removeItem"><type>skin_css</type><name>css/styles-ie.css</name><params/><if>lt IE 8</if></action>
            <action method="removeItem"><type>skin_js</type><name>js/ie6.js</name><if>lt IE 7</if></action>
            <action method="removeItem"><type>js</type><name>lib/ds-sleight.js</name><params/><if>lt IE 7</if></action>
        </reference>
    </default>
 
    <cms_index_index>
        <reference name="head">
            <!-- подключение определенных скриптов только на главной странице магазина -->
            <action method="addItem"><type>skin_js</type><name>js/libs/home.min.js</name></action>
            <action method="addItem"><type>skin_css</type><name>css/home.css</name></action>
        </reference>
    </cms_index_index>
</layout>

 

 

В этом коде довольно много чего происходит, но когда что-то ломается, причину поломки относительно легко найти.

<action method="{addItem или removeItem}">
    <type>{тип файла / локация}</type>
    <name>{путь к файлу}</name>
</action>

 

  1. Метод, который мы задействуем для достижения определенной цели (добавить или удалить файл)
  2. Тег type ссылается на тип подключенного файла и указывает, где этот файл находится в иерархии темы.
  3. Тег name содержит путь к файлу

 

Подробнее о пункте 2: локация указывает на то, где файл находится в иерархии, каждый тип ссылается на собственную позицию в иерархии, относительная той, которую вы указываете в поле <name>. Я перечислил их ниже для справки:

  • skin_js:  skin/frontend/<название_пакета>/default/{name}
  • skin_css: skin/frontend/<название_пакета>/default/{name}
  • js: js/{name}

Обратите внимание на то, что загрузка файла с внешнего источника, например CDN, имеет несколько другой синтаксис. Также важно включать в него jQuery.noConflict(); в конце, чтобы избежать конфликта jQuery со встроенной в Magento библиотекой Prototype.

 

2. Удаление Блоков

Magento поставляется в комплекте с несколькими дефолтными блоками в сайдбар-панелях, такими как баннер «Назад в школу», которые, давайте смотреть правде в глаза, мы никогда не будем использовать в реальной жизненной ситуации. Ниже два метода, которые мы можем использовать, чтобы удалить блоки:

<?xml version="1.0"?>
<layout version="0.1.0">
    <default>
        <!-- удаление (отключение) блока -->
        <remove name="right.permanent.callout" />
     
        <!-- открепление блока -->
        <reference name="right">
            <action method="unsetChild"><name>right.poll</name></action>
        </reference>
    </default>
</layout>

 

Метод remove – это хороший способ, чтобы удалить блок независимо от того, какой макет загружает блок. Иногда мы просто хотим, чтобы блок исчез, независимо от того, где он есть, и чтобы он никогда не возвращался!

С другой стороны unsetChild будет удалять блок только внутри определенного дескриптора макета. Как вы можете видеть, я задействую его внутри дескриптора макета right, поэтому он будет удален только оттуда (с правой сайдбар-колонки). Если блок right.poll вызывается в любом другом макете, то он все равно будет появляться (то есть, не удалится).

 

3. Добавление изменения Макета

Здесь мы имеем пример добавления дополнительного структурного блока на главную страницу сайта. Мы ссылаемся на блок content и с помощью тега after указываем, чтобы блок отображался после всех блоков в конце блока основного контента (content).

 

<?xml version="1.0"?>
<layout version="0.1.0">
    <cms_index_index>
        <reference name="content">
            <block type="core/template" name="home.additional" after="-" template="/home/additional.phtml" />
        </reference>
    </cms_index_index>
</layout>

 

4. Добавление статического CMS Блока

Наконец, мы пришли к примеру добавления статического CMS блока, но сначала вам нужно его создать, чтобы этот код заработал.

После входа в панель администратора перейдите к CMS > Статические Блоки и добавьте новый блок. Заметьте, что «Identifier» (идентификатор блока) — используется в качестве ссылки в XML коде.

 

<?xml version="1.0"?>
<layout version="0.1.0">
    <cms_index_index>
        <reference name="content">
            <block type="cms/block" name="home.static.block" after="-">
                <action method="setBlockId"><block_id>home_static_block</block_id></action>
            </block>
        </reference>
    </cms_index_index>
</layout>

 

Этот идентификатор мы должны вписать в тег block_id.

 

 

Что дальше?

В этой статье мы лишь едва осмотрели всю поверхность данного вопроса, и есть много других применений для XML, и десятки других доступных дескрипторов макета и тегов XML. В следующей статье, мы будем двигаться дальше и рассмотрим файлы шаблонов.

 

Перевод с украинской статьи для сайта Tuts+

 

 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *


Быстрый доступ по сайту SebWeo
Угости меня кофе