Share
Dans cet article, nous couvrirons les bases de la mise en page XML de Magento..
Nous allons passer en revue local.xml et faire quelques modifications de base. Cela inclura l'ajout et la suppression de scripts, la suppression de blocs et l'ajout de modifications à la présentation.
Maintenant que nous avons une compréhension de base de la hiérarchie des thèmes du premier article de cette série, nous allons plonger un peu plus loin et expliquer les fichiers de modèles.
Les fichiers de modèles sont constitués de deux sous-répertoires:
Accentsconagua
app / design / frontend ///disposition/ app / design / frontend ///modèle/ Il y a beaucoup à couvrir, pour cette raison, je les séparerai dans leurs propres articles. Aujourd'hui, nous ne couvrirons que l'aspect mise en page. L'aspect de modèle entrera en jeu dans le prochain article.
Attendez, avant même de commencer, nous devons faire une chose essentielle: désactiver le cache Magento, si vous ne l'avez pas déjà fait, c'est-à-dire! Ce faisant, cela nous permettra de visualiser nos modifications instantanément sans avoir à rafraîchir le cache chaque fois que nous apportons des modifications. Idéalement, il devrait être désactivé lors du développement d'un site. Pour ce faire, connectez-vous à la zone d'administration et dirigez-vous sur système> gestion du cache et désactiver tout.
Maintenant c'est réglé, commençons.
Le dossier de présentation contient les fichiers XML qui dictent en grande partie ce qui est affiché au début du magasin. La structure de présentation est assez complexe dans Magento, mais c’est une des raisons qui la rend si puissante et flexible..
Vous trouverez des centaines de fichiers XML, chacun faisant sa propre chose, chaque vue ou module dans app / code / obtient sa mise en page spécifiée par son propre fichier XML. Si vous installez un module tiers dans votre magasin et que cela affecte le système frontal, il aura sans doute son propre fichier XML..
Alors, comment puis-je savoir quel fichier éditer si je dois?
Eh bien, la convention de dénomination des fichiers facilite le repérage lorsque vous devez apporter des modifications. Par exemple, Magento app / code / core / Mage / Page / le module a son propre fichier XML nommé app / design / frontend / base / default / layout / page.xml comme vous pouvez le constater, un modèle commence à émerger ici! Une fois que vous vous êtes familiarisé et que vous avez effectué quelques magasins, vous remarquerez bientôt une certaine répétitivité et rappelez les fichiers que vous devez modifier..
Remarque:Soyez conscient des modules tiers, car techniquement, le développeur peut nommer son fichier XML comme il le souhaite. Dans ce scénario, à moins que ce ne soit dans leur documentation, vous devrez rechercher le nom du fichier dans le module lui-même, généralement trouvé dans le répertoire. config.xml fichier. Notez également que tous les modules ne disposent pas d'un fichier XML. Généralement, le fichier XML ne sera présent que s'il affecte le front-end du magasin. Ne vous en attendez donc pas toujours.!
Chemin de la configuration: app / code / local /
Avis que j'ai référencé base / défaut ci-dessus, rappelez-vous que c’est là que résident les fichiers de base. Si vous devez apporter des modifications, copiez-les toujours sur votre propre forfait / thème jamais modifier base / défaut des dossiers.
Ainsi:
app / design / frontend / base / default / layout / page.xml
copier:
app / design / frontend /
La modification importante de ces fichiers nécessite une certaine expérience et comme il s’agit d’un tutoriel pour débutants, cela sort du cadre de cette série; cependant, je vais parcourir local.xml et comment cela est lié au développement du thème et couvre une poignée de modifications de base qui, à mon avis, seront utiles.
En termes simples, c'est un fichier qui est placé dans notre dossier de disposition de thème et qui hébergera une grande partie de nos remplacements ou mises à jour de références XML pour ce thème. C'est considéré comme une bonne pratique et Magento le recommande. On pourrait le regarder comme une version Magento de WordPress functions.php fichier.
Attendez, une "grande partie" pourquoi pas "tous" de nos remplacements ou mises à jour?
Il y a un débat sur ce sujet et si nous faisons un peu de recherche, nous verrons que tout le monde a sa propre opinion. Certains diront seulement utiliser local.xml et n'effectuez aucune modification ailleurs, alors que d'autres ne seront pas d'accord, alors ne prenez pas la pierre qui suit.
Personnellement, je pense que c'est un endroit idéal pour de petites modifications, telles que l'ajout de blocs, la suppression de blocs ou la modification de modèles. Ce n'est pas un endroit pour mettre en page complètement votre page de produit ou similaire, si vous voulez le faire, faites-le dans le fichier approprié, par exemple catalogue.xml
Ouais, cela pourrait nous faire gagner un peu de temps lors de la mise à niveau de Magento, car toutes nos modifications sont dans un seul fichier mais que toutes nos modifications sont regroupées dans un seul fichier, avec tous les soucis de remplacer d'autres fichiers XML. est tout simplement dépassé.
En outre, lorsque nous apportions de nombreuses modifications à une page, nous souhaitions idéalement faire référence à l’autre code XML faisant partie de cette page. Nous devions alors basculer constamment entre les deux fichiers et, au final, diviser la fonctionnalité entre deux fichiers distincts - pas ce que nous voulons vraiment!
Alors, comment le configurer…
Créer le local.xml fichier dans notre dossier de disposition de thème app / design / frontend / et ajoutez une structure de balisage XML de base:
Maintenant que notre fichier est prêt, je vais vous montrer quelques techniques courantes.
Une modification très courante consiste à ajouter ou supprimer JavaScript et CSS. Si vous travaillez avec jQuery, vous devrez l'ajouter car Magento ne l'inclut pas par défaut et tout code JavaScript personnalisé dont vous avez besoin devra également être ajouté..
Si nous visualisons les sources sur une installation Magento, nous verrons tout un tas de JavaScript, dont certains ne seront pas utilisés, auquel cas il doit être supprimé car il est inutile de le supprimer. http demande - Magento n'est pas rapide alors faisons bien les bases!
Pour inclure un fichier, nous devons décider s’il sera global, par exemple sur chaque page de notre magasin ou seulement dans certaines zones. Avec cela, nous pouvons sélectionner le bon gestionnaire de mise en page à utiliser..
Je vais présenter deux poignées de mise en page,
le
Passons maintenant au code.
skin_js js / libs / jquery.min.js ]]> skin_js js / libs / modernizr.min.js skin_js js / libs / html5shiv.min.js lt IE 9 skin_js js / libs / respond.min.js lt IE 9 skin_js js / libs / selectivizr.min.js lt IE 9 skin_css css / widgets.css skin_css css / print.css skin_css css / styles-ie.css lt IE 8 skin_js js / ie6.js lt IE 7 js lib / ds-sleight.js lt IE 7 skin_js js / libs / home.min.js skin_css css / home.css
Il y a beaucoup de choses qui se passent ici, mais quand elles sont décomposées, elles sont relativement simples..
type de fichier / emplacement chemin vers le fichier
Suivi du point deux: il indique également où se trouve le fichier dans la hiérarchie, chaque type fait référence à une position différente dans la hiérarchie, à laquelle s'ajoute une préfixe que vous entrez dans la liste.
peau / frontend // default / nom peau / frontend // default / nom
js / name Notez que le chargement d'un fichier à partir d'une source externe telle qu'un CDN a une syntaxe légèrement différente. En outre, il est important d'inclure le jQuery.noConflict (); à la fin pour éviter que jQuery entre en conflit avec Magento dans la bibliothèque de prototypes.
Magento est livré avec plusieurs blocs de la barre latérale qui, avouons-le, ne seront jamais utilisés dans une situation réelle, telle que la publicité "Back to School". Voici deux méthodes que nous pouvons utiliser:
droit
le retirer La méthode est un bon moyen de supprimer un bloc, quel que soit le gestionnaire de mise en page chargé dans le bloc. Parfois, nous voulons simplement qu'il disparaisse globalement, peu importe où il se trouve et qu'il ne retourne jamais.!
D'autre part unsetChild supprime uniquement un bloc dans un descripteur de présentation spécifique. Vous pouvez voir que je l’appelle dans le droite poignée de mise en page afin qu'il ne sera supprimé à partir de là. Si la droit le bloc est appelé de n'importe où ailleurs dans une poignée de mise en page différente, il sera affiché.
Ici, nous avons un exemple d’ajout d’un bloc structurel supplémentaire à la page d’accueil. Nous référençons le bloc de contenu et utilisons le après balise pour spécifier le bloc à afficher à la fin du bloc de contenu.
Enfin, nous avons un exemple d’ajout dans un bloc CMS statique, mais vous devez d’abord en créer un pour que cela fonctionne..
Une fois connecté à la zone d'administration, rendez-vous sur CMS> Blocs statiques et ajoutez un nouveau bloc. Prenez note de "l'identifiant" car nous devons le référencer dans le code XML.
home_static_block
Dans le block_id est où nous entrons notre identifiant.
Nous avons à peine rayé la surface et il existe de nombreuses autres utilisations du langage XML, sans parler de davantage de poignées de présentation et de balises XML à notre disposition. La mise en page de Magento elle-même mérite d’être une série car il y a beaucoup à couvrir, pour le moment je la garde pour l'essentiel.
Si vous voulez faire plus de lecture sur le XML, je vous recommande de lire cet article et de télécharger également une copie du Guide de conception officiel de Magento qui va plus en profondeur et qui a une bonne explication des autres balises XML que nous pouvons utiliser..
Dans le prochain article, nous allons avancer et examiner les fichiers modèles.
