В даній статті ми будемо розглядати основи XML макету Magento.
Ми використаємо файл local.xml
і зробимо деякі основні зміни. Зміни будуть включати в себе додавання і видалення скриптів, видалення блоків і додавання оновлення макету.
Тепер, коли у нас є базове розуміння логіки дизайну для Magento, ми поглибимося в це питання трохи більше і пояснимо шаблонні файли.
Файли шаблону розміщуються в наступних двох підкаталогах:
app/design/frontend/<назва_пакету>/<назва_теми>/layout/
app/design/frontend/<назва_пакету>/<назва_теми>/template/
Я розділю розгляд цієї теми на окремі статті. Сьогодні ми будемо розглядати тільки аспект макетів. Аспекти шаблонів ми розглянемо в наступній статті.
Перш ніж ми почнемо щось робити з макетами, нам потрібно зробити одну важливу річ, – відключити кеш Magento. Це дозволить нам переглядати зміни негайно, замість того, щоб оновлювати кеш щоразу, коли ми робимо найменші зміни. В ідеалі кеш повинен бути вимкнений весь час в процесі розробки сайту. Щоб вимкнути кеш, зайдіть в панель адміністрування сайту і перейдіть в меню Система > Керування кешем і відключить всі типи кешу.
Тепер давайте почнемо.
Папка layout будь-якої теми містить XML-файли, які в значній мірі визначають те, що відображається у фронтенді магазину. Структура макетів в Magento досить складна, але це одна з причин того, що робить двигун таким потужним і гнучким.
Ви знайдете сотні файлів XML, кожен з яких робить свою справу, кожен Вид або Модуль в app/code/
має свій макет, визначений своїм власним файлом 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
і опишу, як це пов’язано із розробкою власної теми, а також наведу приклад кілька основних модифікацій які, як я думаю, будуть вам корисні.
Простіше кажучи, це файл, який розміщується в папці макету нашої теми, який містить велику частину наших модифікацій або оновлень макетів 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>
Тепер, коли у нас є свій готовий файл, я покажу вам кілька поширених методів.
Дуже поширена модифікація для додавання або видалення 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>
Детальніше про пункт 2: локація вказує на те, де файл знаходиться в ієрархії, кожен тип посилається на власну позицію в ієрархії, яка відносна до тієї, яку ви вказуєте в полі <name>
. Я перерахував їх нижче для довідки:
skin/frontend/<назва_пакету>/default/{name}
skin/frontend/<назва_пакету>/default/{name}
js/{name}
Зверніть увагу на те, що завантаження файлу з зовнішнього джерела, наприклад, CDN має трохи інший синтаксис. Також важливо включати в нього jQuery.noConflict();
в кінці, щоб уникнути конфлікт jQuery з вбудованою в Magento бібліотекою Prototype.
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 викликається в будь-якому іншому макеті, то він все-рівно буде з’являтись (тобто, не видалиться).
Тут ми маємо приклад додавання додаткового структурного блоку на головну сторінку сайту. Ми посилаємося на блок 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>
Нарешті, ми дійшли до прикладу додавання статичного 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+
Навчання за кордоном вже давно асоціюється з якісною освітою, новими можливостями та безліччю перспектив. Але…
Вибір майстра для ремонту та перетяжки меблів – завдання, яке потребує вдумливого підходу. Адже від…
Вибір ідеального хостингу під свій сайт може бути досить заплутаною справою, особливо коли існує багато…
Щоб уникати помилок, потрібно набиратися досвіду; щоб набиратися досвіду, потрібно робити помилки Лоуренс Пітер
Коротке визначення Чорного SEO Чорне СЕО (або Чорна оптимізація) — це будь-яка практика, метою якої…
Отримання прав водія категорії C відкриває двері до професійної діяльності, пов'язаної з керуванням вантажними автомобілями.…