Share
Als het gaat om het bouwen van WordPress-thema's - zoals met veel andere soorten dingen, echt - zijn er goede manieren en verkeerde manieren om het te doen. Voor diegenen onder ons die professionele WordPress-ontwikkelaars willen zijn, voor degenen onder ons die echt geven om het werk dat we doen, en voor degenen onder ons die willen dat ons werk duurt, moeten we vooruitdenken over hoe we organiseren de bestanden en de code die bij ons thema hoort.
Ja, de WordPress Codex biedt een fantastisch artikel over thema-ontwikkeling, en ik geloof dat het verplicht moet worden gelezen voor iedereen die bezig is met het bouwen van thema's - vooral premium thema's - maar er zijn een aantal strategieën die het niet bestrijkt en waarvan ik heb ontdekt dat het zeer nuttig is, omdat het gaat om het bouwen, loslaten en onderhouden van thema's in de loop van de tijd.
In de volgende twee artikelen gaan we een paar strategieën bekijken die een beetje dieper ingaan op de ontwikkeling van het thema, zodat we onze thema's zo kunnen structureren dat ze niet alleen de richtlijnen van de WordPress volgen. Codex, maar zal het ook veel gemakkelijker maken om te onderhouden, updaten en verbeteren, niet alleen omdat WordPress verder gaat, maar ook naarmate ons thema rijpt..
De kwaliteit van de organisatie van de bestanden en van de code die wordt gebruikt bij het bouwen van WordPress-thema's is een beetje een hot topic.
Voor de duidelijkheid, dit is een van die dingen waar ontwikkelaars en ontwerpers graag over praten tot het punt dat het is veranderd in iets dat mensen graag haten. Dat wil zeggen dat anderen vaak commentaar geven op thema's van slechte kwaliteit die beschikbaar zijn voor WordPress, en dat argument dan gebruiken als reden waarom WordPress een slecht platform is, niet alleen voor bloggen, maar ook om andere redenen.
Dat is niet het punt of het argument van wat we hier zullen bespreken, noch is het de bedoeling om dat soort discussie in de commentaren te inspireren. In plaats daarvan gaat deze tweedelige serie van het volgende uit:
Natuurlijk, wij ze hebben allemaal onze eigen manieren om dingen te doen, dus de aanbevelingen die in deze serie worden gedeeld, werken mogelijk niet met je huidige workflow. Misschien wil je niet veranderen - en dat is prima! - of misschien ben je op zoek naar verandering.
Ongeacht het geval, alles wat hier wordt gedeeld, is gebaseerd op ervaring met het bouwen en onderhouden van premium WordPress-thema's en heeft het veel gemakkelijker gemaakt om ze in de loop van de tijd te onderhouden, zowel vanuit een themaspecifiek standpunt, maar ook vanuit het oogpunt van WordPress-compatibiliteit..
Een van de moeilijkste onderdelen van het bouwen van software is de oorspronkelijke versie niet verzenden (hoewel dat is moeilijk op zichzelf), maar het product blijft behouden na vrijgave.
Dit houdt niet alleen in dat ervoor moet worden gezorgd dat de codebasis compatibel blijft met de onderliggende infrastructuur - waarover we het in de volgende sectie zullen hebben - maar dat de bestanden zo zijn georganiseerd dat ze door het ontwikkelteam kunnen worden begrepen , dat ze een niveau van cohesie hebben, en dat ze een rijm hebben en reden waarom ze worden genoemd en geplaatst zoals ze zijn.
We weten uit de Codex dat er een aantal bestanden zijn die de kern van het thema vormen. Dit omvat sjablonen, een functiebestand en ten minste één stylesheet.
Wat gebeurt er echter als je thema gecompliceerder wordt? Zeg dat je ...
Al het bovenstaande kan netjes worden georganiseerd in een WordPress themabestand. We zullen deze in meer detail bekijken en de reden achter hun plaatsing in de themamap bekijken in de hoop dat dit de themaontwikkeling schoner maakt en dat onderhoud hierdoor een stuk eenvoudiger wordt..
Hoewel ze in veel contexten onafhankelijk van elkaar kunnen worden besproken, omdat ze verantwoordelijk zijn voor verschillende dingen, is hun organisatiestructuur binnen een thema zo vergelijkbaar dat het zinvol is om ze samen te groeperen.
Ten eerste, ervan uitgaande dat u geen type CSS-pre-processor gebruikt, moet er voor elk van deze typen bestanden een directory zijn. Dat wil zeggen, je zou een css map en a js directory (of misschien noem je ze stijlen en javascript).
Hoe het ook zij, elk bestandstype zou in zijn eigen map moeten staan. Van daaruit kunt u vervolgens gebruiken functions.php om de bestanden te registreren en in te stellen als dat nodig is. Als het een bestand is dat wordt gebruikt in het hele thema, dan registreert u het onvoorwaardelijk.
Maar als het een stijl of een script is die alleen wordt gebruikt voor een bepaalde sjabloon, een bepaald berichttype of zelfs voor een deel van het dashboard, dan kunt u het bestand voorwaardelijk en moet dit in de wachtrij worden geplaatst.
Maar laten we zeggen dat jij zijn een preprocessor gebruiken. Op dit punt blijft het voorverwerkte bestand en uw nabewerkte bestanden achter. Afhankelijk van de aard van uw project, kunt u al dan niet alles teruggebracht tot een enkel bestand.
ik zou aanbevelingen doen voor het benoemen van bestanden; echter, de variatie in thema's, hoe mensen hun werk opbouwen en het probleem dat een bepaald thema probeert op te lossen, en dat ons buiten het bereik van deze specifieke strategie haalt.
Hoe dan ook, als je een pre-processor gaat gebruiken, raad ik aan om een submap te maken in de css en js mappen genoemd dev (of ontwikkeling of hoe je het ook noemt). In deze map schrijf je al je voorverwerkte bestanden, laat je je gereedschap naar keuze (of het nu CodeKit, Grunt of iets dergelijks is) voer het verwerkte bestand (en) uit naar de root van de css en js directories.
Op deze manier hebt u nog steeds bewerkte, gecombineerde en / of verkleinde code en hebt u een map die de bron van die bestanden bevat. Wanneer het tijd is om het thema te verzenden, hebt u niet alleen de functies.php die bestanden in hun respectieve mappen oproepen, maar u kunt ook de dev directory van de laatste build, zodat de eindgebruiker een kleiner themapakket krijgt en niets meer krijgt dan nodig is om het thema uit te voeren.
Sjabloongedeelten worden vaak partities genoemd (meer in andere talen dan in WordPress) en worden vaak aangeroepen door te gebruiken get_template_part in WordPress. Kort gezegd, hun doel is om herhalende code uit te sluiten die eenvoudig in meerdere sjablonen kan worden opgenomen.
Een voorbeeld hiervan is bijvoorbeeld de post-metadata. Dit bevat meestal de volgende informatie:
Aangezien deze informatie in meerdere sjablonen kan bestaan (denk aan losse berichten, pagina's, archieven, enzovoort), is het logisch om deze op te splitsen in een enkel bestand en te verwijzen naar dat ene bestand wanneer u het nodig hebt.
Het punt is, post metagegevens is niet de enkel en alleen type informatie dat door een thema wordt hergebruikt. Zoek daartoe de kernelementen die opnieuw worden gebruikt, vat ze samen in een bestand en maak vervolgens een partials directory.
Van daar, noem elk sjabloondeel iets dat aangeeft wat het vertegenwoordigt (zoals post-meta.php, gravatar.php, navigation.php, pagination.php, en ga zo maar door) en bel dan naar de gedeeltelijke in de sjabloon waar dit nodig is.
In post-, pagina- en archiveringssjablonen kunt u bijvoorbeeld bellen get_template_part ('partials / post-meta');. Zorgt voor een veel gemakkelijker lezen en zorgt voor een single plaats om een wijziging aan te brengen in plaats van in elke sjabloon.
Als je een thema schrijft dat is geïnternationaliseerd, wat je zou moeten doen als je het openbaar maakt, dan is er een heel duidelijke en schone manier om dit te doen.
Ten eerste, als dit een nieuw onderwerp voor u is, raad ik u aan het artikel in de Codex te lezen. Het zal u alles vertellen wat u moet weten over hoe u strings moet voorbereiden voor vertaling, beschikbare tools, enzovoort.
Vervolgens raad ik aan ervoor te zorgen dat u een speciale plaats in uw thema heeft voor uw talen. Over het algemeen beveel ik aan om een map te maken in het genoemde thema LANG of talen en dan de .po en .mo bestanden in de map. Dit is ook een algemeen geaccepteerde en verwachte praktijk binnen de WordPress-gemeenschap als geheel.
Dit verbiedt niet alleen de vertalingen naar hun eigen plaats binnen de themastructuur, maar geeft ook aan anderen door waar ze vertalingen kunnen zoeken en waar ze moeten zoeken naar de bestanden die de tekenreeksen bieden die vertaald moeten worden.
Nogmaals, het gaat om cohesie en ervoor te zorgen dat dingen van vergelijkbaar nut op een redelijke manier worden gegroepeerd.
Afhankelijk van uw achtergrond in ontwikkeling, worden functies die u gebruikt om werk gedaan te krijgen en om bedrijfslogica te scheiden van presentatielogica (of, in veel van onze gevallen, rechte PHP van HTML), helperfuncties of hulpprogramma's genoemd.
Voor het doel van deze reeks zullen we naar hen verwijzen als helperfuncties, hoewel ze weten dat ze allemaal hetzelfde zijn.
Maar dit roept twee vragen op:
Accentsconagua
functions.php?functions.php, waar wonen zij?Kortom, ik ben van de geest die helpers en nutsbedrijven zouden moeten hebben niet leven in functions.php. Mijn vuistregel is eenvoudig dit: als de code die ik schrijf direct communiceert met WordPress zoals add_theme_support, dan hoort het thuis functions.php. Maar als er code is die ik aan het schrijven ben dat een aangepaste vraag zal uitvoeren om informatie op te halen en het verwerkte resultaat terug naar de sjabloon (of het sjabloondeel) over te dragen, dan hoort het in een hulpfunctie.
Net zoals WordPress sjabloontags of sjabloonfuncties heeft die in een sjabloon kunnen worden aangeroepen, zoals de inhoud(), behandel helper-functies op een vergelijkbare manier - je kunt ze in je sjablonen en partities noemen, maar ze bevinden zich in hun eigen bestand.
Omdat deze hulpfuncties niet leven functions.php, dan zouden ze in hun eigen bestand moeten leven en dat bestand moet ergens in de codebase van het thema worden vermeld, toch? Bovendien is het ook heel goed mogelijk dat je je helpers verder opsplitst in meerdere bestanden om ze te baseren op de complexiteit van je thema.
Daarom raad ik aan om een inc of een omvat map in de kern van uw thema. Vanaf daar plaatst u uw helper-bestanden in die map en eenvoudig include_once het helper-bestand bovenaan uw functiedossier en de functies zullen gemakkelijk en gemakkelijk toegankelijk zijn in de rest van uw thema.
Ten slotte zijn er tijden dat we bibliotheken van derden opnemen in onze thema's. Simpel gezegd, dit zijn tools die door anderen zijn ontwikkeld en die vrij beschikbaar zijn voor gebruik en distributie, waardoor we ook gemakkelijk op het werk van anderen kunnen meeliften..
Dus waar moeten ze wonen? Eerlijk gezegd hangt dit af van het type bibliotheek waarmee je werkt. Bibliotheken kunnen bijvoorbeeld komen in de vorm van CSS, JavaScript of PHP. Als zodanig zou daar een plaats voor moeten zijn:
lib map binnen uw js directory. Dit geeft aan dat de map JavaScript-bibliotheken bevat.lib map binnen uw css directory. Nogmaals, dit geeft aan dat je een CSS-bibliotheek hebt.lib map in de hoofdmap van de themamap. Dit geeft aan dat het geen JavaScript of CSS is en dat het bijdraagt aan de functionaliteit van het kernthema (dat grotendeels bestaat uit PHP-functieaanroepen, sjabloontags, enzovoort).Natuurlijk heb ik ook gezien dat sommige ontwikkelaars een lib map en maak vervolgens aan js, css, en php submappen in de lib directory. Het is een beetje een omkering van de hierboven gegeven tips.
Het is geen slechte strategie; De reden dat ik deze benadering echter niet leuk vind, is omdat het JavaScript-, CSS- en PHP-bestanden in meerdere mappen in het thema verspreidt.
Het maken van een georganiseerde directorystructuur is slechts een deel ervan. WordPress heeft een sjabloonhiërarchie die een bepaalde naamgevingsconventie vereist. Volgt logischerwijs niet dat onze aangepaste bestanden hetzelfde moeten doen?
Verder, hoe zit het met de naamgevingsconventies van functies? Doen ze echo gegevens of terugkeer gegevens? Bovendien, hoe we weten dat we goede API-functieaanroepen doen en dat we geen verouderde functies van WordPress gebruiken?
In het volgende artikel zullen we het hebben over dit alles en over hulpmiddelen die we kunnen installeren om valkuilen te voorkomen. We zullen ook bespreken hoe ze werken en waarom ze samen met functie-naamconventies van belang zijn bij het bouwen van thema's.
Voor nu hebben we echter strategieën voor bestandsorganisatie besproken, die voldoende moeten zijn om je bezig te houden tot het volgende artikel in de serie wordt gepubliceerd.
Zoals gewoonlijk, als je iets toe te voegen hebt, doe dat dan in de comments!
