Theming - à partir de zéro

30

Quelle est la méthode préférée pour commencer une construction de site complète , à partir de zéro ? Mes versions commencent généralement à partir de pages filaires HTML5 entièrement simulées, et nous y connectons des fonctionnalités.

Mais, une partie de moi pense que la plupart du temps, dans les dernières étapes d'un projet, nous finissons par trouver tous les domaines de fonctionnalité qui doivent être connectés - généralement des choses comme Enterprise RMA, la section Mon compte client, etc. Je pense cela pourrait être évité en commençant par un thème Magento dès le premier jour; le point de vue opposé dit qu'il y aura autant de temps pour écrire CSS et modifier la structure par défaut.

Construisez-vous sur le thème "vide" de base ? Existe-t-il une version Enterprise de ce thème vierge? Quelle est la meilleure pratique ici?

philwinkle
la source

Réponses:

32

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

Ben Lessani - Sonassi
la source
1
Vous n'êtes rien si ce n'est incroyablement créatif.
philwinkle
3
Très belle rédaction et de solides conseils tout autour.
ColinM
J'aime votre approche pour étendre la mise en page XML plutôt que de simplement copier sur des fichiers existants ou utiliser local.xml, c'est génial! Au lieu de copier initialement dans tous les fichiers de modèle, j'aime la commande "Copier le modèle" de Magicento, qui peut être utilisée pour copier facilement un modèle dans un autre thème, en le plaçant dans la bonne structure de dossiers. Alternativement, lors du nettoyage du thème3 à la fin, vous voudrez peut-être consulter la commande "dev: theme: duplicates" de n98-magerun.phar, qui produira une liste de fichiers qui n'ont pas été modifiés.
Jim OHalloran
Je me demande s'il y a un plugin qui se substitue 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 )
hakre
"...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/…
RichardBernards
7

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.

Benmarks
la source
Vous avez absolument raison
philwinkle