Spowoduje to, że powstanie ostateczne zamieszanie i będzie sprzeczne z zasadami każdego dewelopera Magento - ale mamy solidny proces do tworzenia motywów - który nie używa local.xml (więcej na ten temat później).
Zawsze pracujemy nad szablonem base/default(i enterprise/defaultdla EE) - ale zerujemy CSS. Chociaż wszystkie projekty nie nadają się szczególnie do strukturalnego układu waniliowego sklepu Magento - uważamy, że dobrą praktyką jest używanie tego defaultmotywu jako punktu wyjścia; w razie potrzeby możemy usunąć nieużywane metody / pętle / HTML itp.
Podczas uruchamiania motywu
Dla EE
Najpierw instalujemy to rozszerzenie , aby uzyskać poziom rezerwowania motywu - kiedy później usuwamy skopiowane pliki motywu.
Paczka
Najpierw zaczynamy od utworzenia pakietu i skopiowania całego base/defaultmotywu; więc na przykład (powiedzmy, że to była nasza własna strona internetowa, zadzwonilibyśmy do paczki sonassi)
cd ./app/design/frontend
mkdir sonassi
cp -par base/default sonassi/default
mkdir sonassi/default/layout/custom
Szablon
Ostatecznym celem jest to, że nie musimy kopiować i wklejać każdego pliku, który modyfikujemy, kiedy tylko jest to konieczne, po prostu edytujemy plik w kompozycji.
Ale za każdym razem, gdy edytujemy plik, usuwamy nagłówki Magento Commerce - i dodajemy odpowiedni nagłówek / identyfikator, aby oznaczyć plik jako szablon niestandardowy, zwykle coś w rodzaju ...
/*
* @category Template
* @package sonassi_default
* @copyright Copyright (c) 2013 Sonassi
*/
Ten nagłówek służy celowi później, gdy przeprowadzamy końcowe czyszczenie szablonu. Ponieważ zrobimy rekursywne diffdla base/default/templatekatalogu i sonassi/default/templatekatalogu - następnie usuń wszystko, co nie zostało zmienione.
W ten sposób zostają tylko zmodyfikowane pliki, a cały pakiet został zredukowany do minimum zmienionych plików.
Pliki układu
Używamy własnego standardowego modułu podstawowego sonassi.core. Tak, zawsze poprzedzamy przestrzeń nazw modułu unikalnym identyfikatorem - zatrzymuje konflikty, w których inne firmy wybrały tę samą nazwę (np. Fishpig / wordpress i sonassi / wordpress)
Metodologia układu nielokalnego
<core>
<rewrite>
<layout>Sonassi_Core_Model_Core_Layout</layout>
<layout_update>Sonassi_Core_Model_Core_Layout_Update</layout_update>
</rewrite>
</core>
Następnie dwie klasy magiczne, które dodają funkcjonalność, której już nigdy nie potrzebujesz 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;
}
}
i
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;
}
}
Dwie powyższe klasy dodają funkcjonalność do Magento, abyś mógł rozszerzyć - ale nie zastąpić pliku XML układu. Rozciągliwość XML układ jest dla nas ważne, gdyż pozwala nam wciąż utrzymują tę samą separację plików catalog.xml, cms.xmlitd. - ale wystarczy dodać krótkie fragmenty układu XML manipulować bloków (insert / klon / Usuń).
local.xmlMetodologia jest to, że po prostu wprowadzić swoje nadrzędne zmiany w jednym pliku kłopotliwe niewykonalna.
Te nolocalśrodki metodologia, że zamiast umieszczać wszystkie zmiany w jednym pliku, można umieścić je w pliku z odpowiedniego pliku, że jest modyfikowanie (np. catalog.xml) - po prostu tworząc nowy plik sonassi/default/layout/custom/catalog.xml- z * tylko modyfikacjami .
Ponownie, gdy skończymy tworzenie szablonu, możemy po prostu usunąć zawartość, sonassi/default/layoutz wyjątkiem customkatalogu. W ten sposób, podobnie jak w przypadku szablonu, mamy lekki rozszerzony szablon oparty na szablonach podstawowych.
Arkusze stylów
Usuwamy je wszystkie. Nie zawracamy sobie głowy kopiowaniem ich do katalogu CSS naszego pakietu. Skopiujemy do JS i to wszystko - katalog imagesi CSSod samego początku będzie pusty.
Ponieważ obecnie używamy SASS, będziemy mieli inny katalog ( scss) dla wstępnie przetworzonego CSS - i wyprowadzimy go do głównych plików / stylów CSS.
Czyszczenie szablonu
Jak już wspomnieliśmy, po zakończeniu motywu szablonu możesz go teraz wyczyścić - aby usunąć niezmodyfikowane pliki i zredukować go do absolutnego minimum.
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/"
Więc dlaczego nie local.xml?
To nie jest dla ciebie - jest dla stron trzecich, tak samo jak communitydla ciebie i localdla stron trzecich. Jest to rezerwowe wyjście awaryjne, ostateczne miejsce docelowe dla przesłonięć.
Struktura pliku XML w ten sposób utrzymuje go w jednej linii ze sposobem, w jaki Magento pierwotnie skonfigurował strukturę katalogów i plików. Dodatkowo, dla ciągłości rozwoju - ma to po prostu większy sens, jest o wiele łatwiejsze do strawienia i nie dodaje zauważalnego obciążenia.
Magento to dziwny produkt, społeczność wymyśliła własne najlepsze praktyki oparte na zdrowym rozsądku i naśladowaniu tego, co robią główny zespół Magento. Nie ma więc oficjalnej drogi (dopóki jednorożec nie włączy się z dokumentacją Magento-1) ; ale to jest nasza droga.
Tak bym nawet rozciągnąć do powiedzenia to nie jest odpowiedź, jego tylko jeden z wielu sposobów, aby zmierzyć się powszechnie w obliczu wyzwania. Chociaż chciałbym myśleć, że nasza metoda jest najlepsza.
Treść szczęśliwie pochodzi z sonassi.com