У даній статті ми будемо розглядати основи 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 файли.
Що таке 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:
Тепер, коли у нас є свій готовий файл, я покажу вам кілька поширених методів.
1. Додавання і видалення скриптів / файлів стилів
Щоб підключити файл, ми повинні спочатку вирішити, чи буде він глобальним, тобто підключеним на всіх сторінках нашого магазину, або ж тільки для певних областей. При цьому ми можемо вибрати правильний дескриптор (тег розмітки) макета для використання.
Я представлю два дескпрітора макета,
дескриптор
Тепер перейдемо до коду.
У цьому коді досить багато чого відбувається, але коли щось ламається, причину поломки відносно легко знайти.
- Метод, який ми задіємо для досягнення певної мети (додати або видалити файл)
- Тег type посилається на тип підключеного файлу і вказує, де цей файл знаходиться в ієрархії теми.
- Тег name містить шлях до файлу
- skin_js: skin / frontend /<название_пакета>/ Default /
- skin_css: skin / frontend /<название_пакета>/ Default /
- js: js /
Зверніть увагу на те, що завантаження файлу із зовнішнього джерела, наприклад CDN, має дещо інший синтаксис. Також важливо включати в нього jQuery.noConflict (); в кінці, щоб уникнути конфлікту jQuery з вбудованою в Magento бібліотекою Prototype.
2. Видалення Блоків
Magento поставляється в комплекті з кількома дефолтними блоками в сайдбар-панелях, такими як банер «Назад до школи», які, давайте дивитися правді в очі, ми ніколи не будемо використовувати в реальній життєвій ситуації. Нижче два методи, які ми можемо використовувати, щоб видалити блоки:
Метод remove - це хороший спосіб, щоб видалити блок незалежно від того, який макет завантажує блок. Іноді ми просто хочемо, щоб блок зник, незалежно від того, де він є, і щоб він ніколи не повертався!
З іншого боку unsetChild буде видаляти блок тільки всередині певного дескриптора макета. Як ви можете бачити, я задіюю його всередині дескриптора макета right. тому він буде вилучений тільки звідти (з правого сайдбар-колонки). Якщо блок right.poll викликається в будь-якому іншому макеті, то він все одно буде з'являтися (тобто, не сумнівайся).
3. Додавання зміни Макета
Тут ми маємо приклад додавання додаткового структурного блоку на головну сторінку сайту. Ми посилаємося на блок content і за допомогою тега after вказуємо, щоб блок відображався після всіх блоків в кінці блоку основного контенту (content).
4. Додавання статичного CMS Блоку
Нарешті, ми прийшли до прикладу додавання статичного CMS блоку, але спочатку вам потрібно його створити, щоб цей код заробив.
Після входу в панель адміністратора перейдіть до CMS> Статичні Блоки і додайте новий блок. Зауважте, що «Identifier» (ідентифікатор блоку) - використовується в якості посилання в XML коді.
Цей ідентифікатор ми повинні вписати в тег block_id.
Що далі?
У цій статті ми лише ледь оглянули всю поверхню даного питання, і є багато інших застосувань для XML, і десятки інших доступних дескрипторів макета і тегів XML. У наступній статті, ми будемо рухатися далі і розглянемо файли шаблонів.