Cela provoquera donc un tumulte ultime et ira à l'encontre de tous les développeurs de Magento - mais nous avons un processus solide pour le thème - qui n'utilise pas local.xml (plus à ce sujet plus tard).
Nous travaillons toujours à partir du modèle base/default(et enterprise/defaultpour EE) - mais à zéro le CSS. Même si tous les designs ne se prêtent pas particulièrement à la disposition structurelle d'un magasin Magento vanilla - nous trouvons une bonne pratique d'utiliser le defaultthème comme point de départ; nous pouvons supprimer les méthodes / boucles / html, etc. non utilisées, si nécessaire pendant la création de modèles.
Lors du démarrage d'un thème
Pour EE
Nous installons d'abord cette extension , afin d'obtenir un niveau de repli du thème - lorsque nous supprimons plus tard les fichiers de thème que nous avons copiés.
Le paquet
Nous commençons d'abord par créer le package et copier dans le base/defaultthème entier ; Ainsi, par exemple (disons que c'était notre propre site Web, nous appellerions le forfait sonassi)
cd ./app/design/frontend
mkdir sonassi
cp -par base/default sonassi/default
mkdir sonassi/default/layout/custom
Le gabarit
Le but ultime est de ne pas avoir à copier et coller chaque fichier que nous modifions chaque fois que nous en avons besoin, nous éditons simplement le fichier dans le thème.
Mais chaque fois que nous modifions le fichier, nous supprimons les en-têtes Magento Commerce - et ajoutons un en-tête / identifiant approprié pour marquer le fichier comme étant un modèle personnalisé, généralement quelque chose comme ...
/*
* @category Template
* @package sonassi_default
* @copyright Copyright (c) 2013 Sonassi
*/
Cet en-tête sert un objectif plus tard lorsque nous effectuons le nettoyage final du modèle. Comme nous allons faire une récursivité diffsur le base/default/templaterépertoire et le sonassi/default/templaterépertoire - puis supprimez tout ce qui n'a pas été modifié.
De cette façon, seuls les fichiers modifiés restent et le package global a été réduit au minimum de fichiers modifiés.
Les fichiers de mise en page
Nous utilisons notre propre module standard sonassi.core. Oui, nous préfixons toujours l'espace de noms du module avec un identifiant unique - il arrête les conflits lorsque d'autres sociétés ont choisi le même nom (par exemple, fishpig / wordpress et sonassi / wordpress)
La méthodologie de mise en page nolocal
<core>
<rewrite>
<layout>Sonassi_Core_Model_Core_Layout</layout>
<layout_update>Sonassi_Core_Model_Core_Layout_Update</layout_update>
</rewrite>
</core>
Ensuite, les deux classes magiques qui ajoutent la fonctionnalité pour nelocal.xml plus jamais avoir besoin ,
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;
}
}
et
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;
}
}
Les deux classes ci-dessus ajoutent la fonctionnalité dans Magento afin que vous puissiez étendre - mais pas écraser un fichier XML de mise en page. L'extensibilité du XML de mise en page est importante pour nous, car elle nous permet de conserver la même séparation de fichiers catalog.xml, cms.xmletc. - mais il suffit d'ajouter de courtes portions de XML de mise en page pour manipuler les blocs (insérer / cloner / supprimer).
La local.xmlméthodologie est que vous entrez simplement vos modifications prioritaires dans un seul fichier ingérable encombrant.
La nolocalméthodologie signifie que plutôt que de mettre toutes les modifications dans un seul fichier, vous les placez dans un fichier avec le nom de fichier approprié qu'il modifie (par exemple. catalog.xml) - en créant simplement un nouveau fichier sonassi/default/layout/custom/catalog.xml- avec * uniquement les modifications .
Encore une fois, une fois que nous avons terminé de créer le modèle, nous pouvons simplement supprimer le contenu de, sonassi/default/layoutà l'exception du customrépertoire. De cette façon, comme avec le modèle, nous avons un modèle étendu léger - basé sur les modèles de base.
Les feuilles de style
Nous les supprimons tous. Nous ne prenons pas la peine de les copier dans le répertoire CSS de notre package. Nous allons copier dans le JS et c'est tout - le répertoire imageset CSSsera vide dès le début.
Comme nous utilisons SASS de nos jours, nous aurons un autre répertoire ( scss) pour le CSS prétraité - et une sortie vers le (s) fichier (s) CSS principaux de styles / d'impression.
Nettoyage du modèle
Donc, comme nous l'avons mentionné, une fois le thème du modèle terminé, vous pouvez maintenant le nettoyer - pour supprimer les fichiers non modifiés et le réduire au strict 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/"
Alors pourquoi non local.xml?
Ce n'est pas pour vous - c'est pour les tiers, de la même manière que communitypour vous et localpour les tiers. C'est un retour en arrière, dernier recours, destination finale pour les remplacements.
Structurer le XML de cette manière le maintient en ligne avec la façon dont Magento a initialement configuré la structure des répertoires et des fichiers. De plus, pour la continuité du développement - cela a simplement plus de sens, est beaucoup plus facile à digérer et n'ajoute pas de surcharge notable.
Magento est un produit étrange, la communauté a inventé ses propres meilleures pratiques basées sur le bon sens et imitant ce que fait l'équipe de base de Magento. Il n'y a donc jamais de voie officielle (pas avant qu'une licorne ne vienne avec la documentation de Magento-1) ; mais c'est notre chemin.
Donc, je voudrais même dire que ce n'est pas la réponse, ce n'est qu'une des nombreuses façons de relever un défi commun. Bien que j'aimerais penser que notre méthode est la meilleure.
Contenu provenant heureusement de sonassi.com
default/defaultaux installations CE. Peut-être pas si difficile à pirater avec les sources données, juste curieux (à mâcher: Magento Theme Fall-back / Hierarchy à la lumière du thème personnalisé et des extensions tierces )"...the same way that community is for you and local is for 3rd parties..."La manière Magento est que cela soit l'inverse comme indiqué ici: magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/…Créez un thème d'amorçage vierge pour Enterprise. Cela signifie prendre le
enterprise/defaultthème, nettoyer son CSS et "cliquer sur toutes les choses" pour vérifier que vous avez bien géré le style des fonctionnalités. N'oubliez pas la vue de la grille des produits vaudou.L'un des avantages est que cela offre la possibilité de configurer un flux de travail MOINS (ou autre). Pensez-y - bien que le thème vide soit un bon début pour les thèmes de couleur claire, c'est un peu de travail de le changer pour l'adapter à un thème sombre / noir. Surtout, vous DEVEZ incorporer le
enterprise/defaultthème, sinon vous avez une installation EE cassée depuis le début.la source