Таким чином, це викличе остаточний шум і піде проти зерна кожного розробника Magento - але у нас є надійний процес їх розробки, який не використовує local.xml (докладніше про це пізніше).
Ми завжди працюємо за шаблоном base/default
(і enterprise/default
для EE), але не враховуємо CSS. Незважаючи на те, що всі дизайни не особливо піддаються структурному плануванню магазину ванільного Magento - ми вважаємо гарною практикою використання default
теми як вихідної точки; ми можемо видалити невикористані методи / циклі / html тощо за необхідності під час шаблонування.
При запуску теми
Для ЕЕ
Спочатку ми встановлюємо це розширення , щоб ми отримали рівень відпадання теми - коли згодом видаляємо файли тем, які ми скопіювали.
Пакунок
Спочатку починаємо зі створення пакету та копіювання у всій base/default
темі; так, наприклад (скажімо, це наш власний веб-сайт, ми би назвали пакет sonassi
)
cd ./app/design/frontend
mkdir sonassi
cp -par base/default sonassi/default
mkdir sonassi/default/layout/custom
Шаблон
Кінцева мета полягає в тому, що нам не потрібно зберігати копії та вставляти кожен файл, який ми змінюємо, коли потрібно, ми просто редагуємо файл у темі.
Але кожен раз, коли ми редагуємо файл, ми викреслюємо заголовки Magento Commerce - і додаємо відповідний заголовок / ідентифікатор, щоб позначити файл як власний шаблон, як правило, щось на зразок ...
/*
* @category Template
* @package sonassi_default
* @copyright Copyright (c) 2013 Sonassi
*/
Цей заголовок служить цілі пізніше, коли ми робимо остаточне очищення шаблону. Оскільки ми будемо робити рекурсивну diff
для base/default/template
каталогу та sonassi/default/template
каталогу - тоді видаляємо все, що не було змінено.
Таким чином, залишаються лише модифіковані файли, і загальний пакет було зменшено до мінімально змінених файлів.
Файли компонування
Ми використовуємо власний стандартний базовий модуль sonassi.core
. Так, ми завжди префіксуємо простір імен модулів за допомогою унікального ідентифікатора - він зупиняє конфлікти, коли інші компанії вибрали таке ж ім’я (наприклад, fishpig / wordpress та sonassi / wordpress)
Методика нолокального компонування
<core>
<rewrite>
<layout>Sonassi_Core_Model_Core_Layout</layout>
<layout_update>Sonassi_Core_Model_Core_Layout_Update</layout_update>
</rewrite>
</core>
Потім два магічні класи, які додають функціонал ніколи більше не потрібен local.xml
,
class Sonassi_Core_Model_Core_Layout
extends Mage_Core_Model_Layout
{
/**
* Loyout xml generation
*
* @return Mage_Core_Model_Layout
*/
public function generateXml()
{
$xml = $this->getUpdate()->asSimplexml();
$removeInstructions = $xml->xpath("//remove");
if (is_array($removeInstructions)) {
foreach ($removeInstructions as $infoNode) {
$attributes = $infoNode->attributes();
$blockName = (string)$attributes->name;
if ($blockName) {
$unremoveNodes = $xml->xpath("//unremove[@name='".$blockName."']");
if (is_array($unremoveNodes) && count($unremoveNodes) > 0) {
continue;
}
$ignoreNodes = $xml->xpath("//block[@name='".$blockName."']");
if (!is_array($ignoreNodes)) {
continue;
}
$ignoreReferences = $xml->xpath("//reference[@name='".$blockName."']");
if (is_array($ignoreReferences)) {
$ignoreNodes = array_merge($ignoreNodes, $ignoreReferences);
}
foreach ($ignoreNodes as $block) {
if ($block->getAttribute('ignore') !== null) {
continue;
}
$acl = (string)$attributes->acl;
if ($acl && Mage::getSingleton('admin/session')->isAllowed($acl)) {
continue;
}
if (!isset($block->attributes()->ignore)) {
$block->addAttribute('ignore', true);
}
}
}
}
}
$this->setXml($xml);
return $this;
}
}
і
class Sonassi_Core_Model_Core_Layout_Update
extends Mage_Core_Model_Layout_Update
{
public function getFileLayoutUpdatesXml($area, $package, $theme, $storeId = null)
{
if (null === $storeId) {
$storeId = Mage::app()->getStore()->getId();
}
/* @var $design Mage_Core_Model_Design_Package */
$design = Mage::getSingleton('core/design_package');
$layoutXml = null;
$elementClass = $this->getElementClass();
$updatesRoot = Mage::app()->getConfig()->getNode($area.'/layout/updates');
Mage::dispatchEvent('core_layout_update_updates_get_after', array('updates' => $updatesRoot));
$updateFiles = array();
foreach ($updatesRoot->children() as $updateNode) {
if ($updateNode->file) {
$module = $updateNode->getAttribute('module');
if ($module && Mage::getStoreConfigFlag('advanced/modules_disable_output/' . $module, $storeId)) {
continue;
}
$updateFiles[] = (string)$updateNode->file;
// custom theme XML contents
$updateFiles[] = 'custom/'.(string)$updateNode->file;
// custom theme XML override
$updateFiles[] = 'local/'.(string)$updateNode->file;
}
}
// custom local layout updates file - load always last
$updateFiles[] = 'local.xml';
$layoutStr = '';
foreach ($updateFiles as $file) {
$filename = $design->getLayoutFilename($file, array(
'_area' => $area,
'_package' => $package,
'_theme' => $theme
));
if (!is_readable($filename)) {
continue;
}
$fileStr = file_get_contents($filename);
$fileStr = str_replace($this->_subst['from'], $this->_subst['to'], $fileStr);
$fileXml = simplexml_load_string($fileStr, $elementClass);
if (!$fileXml instanceof SimpleXMLElement) {
continue;
}
$layoutStr .= $fileXml->innerXml();
}
$layoutXml = simplexml_load_string('<layouts>'.$layoutStr.'</layouts>', $elementClass);
return $layoutXml;
}
}
Два вищевказані класи додають функціональність у Magento, щоб ви могли розширити, але не перезаписати XML-файл макета. Розширюваність макета XML важлива для нас, оскільки вона дозволяє зберігати одне і те ж розділення файлів catalog.xml
і cms.xml
т. Д. - але потрібно лише додати короткі частини XML верстки для маніпулювання блоками (вставити / клонувати / видалити).
local.xml
Методології є те , що ви просто введіть перевизначення зміни в один громіздкий некерований файл.
У nolocal
методології означає , що замість того , щоб помістити всі зміни в одному файлі, помістити їх в файл з відповідним ім'ям файлу , що він модифікує (наприклад. catalog.xml
) - просто створити новий файл sonassi/default/layout/custom/catalog.xml
- з * тільки модифікаціями .
Знову ж таки, щойно ми зробимо шаблон, ми можемо просто видалити вміст, sonassi/default/layout
за винятком custom
каталогу. Таким чином, як і з шаблоном, у нас є легкий розширений шаблон - на основі базових шаблонів.
Таблиці стилів
Видаляємо їх, усі вони. Ми не турбуємось копіювати їх у каталог CSS нашого пакету. Ми скопіюємо в JS, і це все - images
і CSS
каталог буде порожнім з самого початку.
Оскільки ми сьогодні використовуємо SASS, ми матимемо інший каталог ( scss
) для попередньо обробленого CSS - і виводимо до основних стилів / друкуємо CSS-файли.
Прибирання шаблону
Як ми вже згадували, як тільки тема шаблону буде завершена, тепер ви можете її очистити - видалити незмінені файли та зменшити її до мінімуму.
cd ./app/design/frontend
PREFIX="cleantheme_"
THEME="sonassi/default"
diff -BPqr "base/default/template" "$THEME/template" | \
awk '{print $4}' | \
while read FILE; do
DIR=$(dirname "$FILE")
[ -d "$PREFIX$DIR" ] || mkdir -p "$PREFIX$DIR"
[ -f "$PREFIX$FILE" ] || cp -pa "$FILE" "$PREFIX$FILE"
done
cp -par "$THEME/layout" "$PREFIX$THEME/"
То чому ні local.xml
?
Це не для вас - його для третіх сторін, так само, community
як для вас і local
для третіх сторін. Це відмова, остання інстанція, кінцеве місце призначення для відміни.
Структурування XML таким чином підтримує його відповідність тому, як Magento спочатку налаштував каталог та структуру файлів. Плюс, для безперервності розвитку - це просто має більше сенсу, набагато простіше засвоюється і не додає помітних витрат.
Magento - це дивний продукт, спільнота винайшла власну найкращу практику, засновану на здоровому глузді та імітуючи те, що робить основна команда Magento. Так що офіційного шляху не існує (доки єдиноріг не їде з документацією на Magento-1) ; але це наш шлях.
Так що я б навіть розтягнути сказати , що це не відповідь, його тільки один з багатьох способів вирішення з якими нерідко стикаються виклику. Хоча я хотів би вважати, що наш метод найкращий.
Вміст із задоволенням походить від sonassi.com