Share
In dit artikel bespreken we de basis van Magento-lay-out XML.
We gaan over local.xml en enkele basisaanpassingen doen. Dit omvat het toevoegen en verwijderen van scripts, het verwijderen van blokken en het toevoegen van indelingswijzigingen.
Nu we een basisbegrip hebben van de themahiërarchie vanaf het eerste artikel in deze serie, duiken we een beetje dieper en leggen we de sjabloonbestanden uit.
De templating-bestanden bestaan uit twee submappen waarvan:
Accentsconagua
app / design / frontend /// Lay-out / app / design / frontend ///sjabloon/ Er valt veel te bedekken, daarom zal ik ze opsplitsen in hun eigen artikelen. Vandaag behandelen we alleen het lay-outaspect. Het sjabloonaspect komt in het volgende artikel in beeld.
Wacht, voordat we zelfs maar aan de slag gaan, moeten we één belangrijk ding doen om Magento-cache uit te schakelen, als je dat nog niet hebt gedaan! Door dit te doen, kunnen we onze wijzigingen direct bekijken in plaats van de cache te vernieuwen telkens wanneer we een wijziging aanbrengen. Idealiter zou het tijdens de ontwikkeling van een site moeten worden uitgeschakeld. Om dit te doen logt u in op het admin-gedeelte en gaat u naar systeem> cachebeheer en schakel alles uit.
Nu dat gesorteerd is, laten we beginnen.
De lay-outmap bevat de XML-bestanden die grotendeels dicteren wat wordt weergegeven aan de voorkant van de winkel. De lay-outstructuur is vrij complex in Magento, maar dit is een van de redenen waarom het zo krachtig en flexibel is.
Je zult honderden XML-bestanden vinden die elk hun eigen ding doen, elke weergave of module erin app / code / krijgt de lay-out gespecificeerd door zijn eigen XML-bestand. Als u ooit een module van derden op uw winkel installeert en dit heeft invloed op de voorkant, heeft deze ongetwijfeld een eigen XML-bestand.
Dus, hoe weet ik welk bestand ik moet bewerken als dat nodig is?
Welnu, de naamgevingsconventie van de bestanden maakt het gemakkelijker om te achterhalen wanneer u wijzigingen moet aanbrengen. Bijvoorbeeld Magento app / code / kern / Mage / Pagina / module heeft zijn eigen XML-bestand met de naam app / design / frontend / base / default / lay-out / page.xml zoals je kunt zien, begint hier een patroon op te duiken! Als je jezelf eenmaal vertrouwd hebt gemaakt en een paar winkels hebt voltooid, zul je al snel merken dat je wat herhalingen doet en je herinneren aan welke bestanden je moet bewerken.
Notitie:Let op modules van derden, omdat de ontwikkelaar technisch zijn XML-bestand naar eigen inzicht kan benoemen. In dit scenario moet u, tenzij het in hun documentatie staat, de naam van het bestand opsporen binnen de module zelf die u meestal aantreft in de config.xml het dossier. Merk ook op dat niet alle modules een XML-bestand hebben, meestal is het XML-bestand alleen aanwezig als dit van invloed is op de voorkant van de winkel, dus verwacht niet de hele tijd een!
Pad naar config: app / code / local /
Kennisgeving waarnaar ik heb verwezen base / default hierboven, onthoud dat hier de kernbestanden zich bevinden, als u wijzigingen moet aanbrengen, kopieer deze dan altijd naar uw eigen bestanden pakket / thema nooit Bewerk base / default bestanden.
Zoals zo:
app / design / frontend / base / default / lay-out / page.xml
kopiëren naar:
app / design / frontend /
Het intensief aanpassen van deze bestanden vereist ervaring en omdat dit een tutorial voor beginners is, valt deze buiten het bereik van deze serie; maar ik zal er doorheen rennen local.xml en hoe dit aansluit bij de themaontwikkeling en een handvol basisaanpassingen behandelt waarvan ik denk dat ze nuttig zullen zijn.
Simpel gezegd, het is een bestand dat zich in onze themalay-outmap bevindt en dat een groot deel van onze overrides of updates voor XML-verwijzingen voor dat thema bevat. Het wordt als een goede oefening beschouwd en Magento beveelt het aan. We zouden het kunnen zien als Magento-versie van WordPress functions.php het dossier.
Wacht, een "groot deel", waarom niet "alle" van onze overschrijvingen of updates?
Er is een debat over dit onderwerp en als we een beetje onderzoek doen, zullen we zien dat iedereen zijn eigen mening heeft. Sommigen zullen alleen gebruik zeggen local.xml en bewerk je nergens anders terwijl anderen het niet eens zijn, dus neem de volgende set niet in steen.
Persoonlijk vind ik het een geweldige plek voor kleine aanpassingen, zoals het toevoegen van blokken, het verwijderen van blokken of het wijzigen van sjablonen. Het is geen plaats om uw productpagina of iets dergelijks volledig in te delen, als u dat wilt doen, doe het dan in het relevante bestand, bijvoorbeeld catalog.xml
Ja, het kan ons een beetje tijd besparen als we Magento upgraden omdat al onze bewerkingen in een enkel bestand zijn, maar al onze bewerkingen in één enkel bestand krijgen in de eerste plaats, met alle hoofdpijn van het proberen andere XML-bestanden te overschrijven, het wordt eenvoudigweg gecompenseerd.
Verder, wanneer we een groot aantal wijzigingen aan een pagina aan het doen waren, willen we idealiter verwijzen naar de andere XML die deel uitmaakt van die pagina, we zouden constant moeten schakelen tussen de twee bestanden, en uiteindelijk moesten we functionaliteit splitsen tussen twee afzonderlijke bestanden - niet wat we echt willen!
Dus, hoe het in te stellen ...
Maak het local.xml bestand in onze themalay-outmap app / design / frontend / en voeg wat basis XML-markup structuur toe:
Nu we ons bestand klaar hebben, zal ik je een handvol gemeenschappelijke technieken laten zien.
Een veel voorkomende wijziging is om JavaScript en CSS toe te voegen of te verwijderen. Als je met jQuery werkt, moet je dit toevoegen omdat Magento het standaard niet bevat en elk aangepast JavaScript dat je nodig hebt, zal ook moeten worden toegevoegd.
Als we de bron bekijken op een Magento-installatie, zien we een hele reeks JavaScript-berichten die we niet zullen gebruiken, in welk geval het moet worden verwijderd omdat het een onnodige JavaScript-code is. http verzoek - Magento is niet snel dus laten we de basis goed doen!
Om een bestand op te nemen, moeten we beslissen of het globaal zal zijn, bijvoorbeeld op elke pagina van onze winkel of alleen bepaalde gebieden. Hiermee kunnen we de juiste lay-outhandgreep selecteren om te gebruiken.
Ik zal twee lay-outgrepen introduceren,
De
Nu, door naar de code.
skin_js js / libs / jquery.min.js ]]> skin_js js / libs / modernizr.min.js skin_js js / libs / html5shiv.min.js IE 9 skin_js js / libs / respond.min.js IE 9 skin_js js / libs / selectivizr.min.js IE 9 skin_css css / widgets.css skin_css css / print.css skin_css css / stijlen-ie.css Het IE 8 skin_js js / ie6.js Het is IE 7 js lib / ds-sleight.js Het is IE 7 skin_js js / libs / home.min.js skin_css css / home.css
Er gebeurt hier behoorlijk veel, maar bij een storing is het relatief eenvoudig.
type bestand / locatie pad naar het bestand
Volgend op punt twee: het dicteert ook waar het bestand zich in de hiërarchie bevindt, elk type verwijst naar een andere positie in de hiërarchie die voorvoegt bij wat u invoert in de hiërarchie
skin / frontend // Default / naam skin / frontend // Default / naam
js / naam Merk op dat het laden van een bestand van een externe bron, zoals een CDN, een iets andere syntaxis heeft. Het is ook belangrijk om de jQuery.noConflict (); aan het einde om te voorkomen dat jQuery in strijd is met Magento gebouwd in Prototype-bibliotheek.
Magento wordt gebundeld met meerdere zijbalkblokken die we nooit mogen gebruiken in een echte leefsituatie, zoals de advertentie 'Terug naar school'. Hieronder zijn twee methoden die we kunnen gebruiken:
right.poll
De verwijderen methode is een goede manier om een blok te verwijderen, ongeacht welke lay-outhandgreep het blok heeft geladen, soms willen we het gewoon wereldwijd laten gebeuren, ongeacht waar het zich bevindt en om nooit terug te komen!
Anderzijds unsetChild verwijdert alleen een blok uit een specifieke lay-outhandle. Je kunt zien dat ik het noem binnen de rechts lay-outhandvat, zodat het alleen daar wordt verwijderd. Als het right.poll blok wordt ergens anders aangeroepen in een andere lay-outhandle dat het wordt weergegeven.
Hier hebben we een voorbeeld van het toevoegen van een extra structureel blok aan de startpagina. We verwijzen naar het inhoudsblok en gebruiken het na tag om het blok op te geven dat aan het einde van het inhoudsblok moet worden weergegeven.
Ten slotte hebben we een voorbeeld van het toevoegen van een statisch CMS-blok, maar eerst moet u er een maken om dit te laten werken.
Eenmaal ingelogd op het admin-gedeelte ga naar CMS> Statische blokken en voeg een nieuw blok toe. Let op de "Identifier" aangezien we dit in de XML-code moeten vermelden.
home_static_block
Binnen de block_id is waar we onze identificatie invoeren.
We hebben amper oppervlakkig gekraakt en er zijn veel andere toepassingen voor XML, om nog maar te zwijgen over meer lay-outhandvatten en XML-tags die voor ons beschikbaar zijn. Magento lay-out zelf garandeert dat het een serie is, want er is veel te bedekken, want nu hou ik het alleen bij de basis.
Als je wat meer wilt lezen over de XML, raad ik je aan dit artikel te lezen en ook een exemplaar van Magento Official Design Guide te downloaden die dieper ingaat en een goede uitleg geeft van de andere XML-tags die we kunnen gebruiken.
In het volgende artikel gaan we door en bekijken we de sjabloonbestanden.
