Share
In de eerste post in deze serie hebben we een aantal strategieën besproken die beschikbaar zijn als het gaat om het organiseren van onze WordPress-themadirectory's om ze beter te onderhouden.
Concreet hebben we het gehad over het organiseren van:
Uiteindelijk was het doel om een directoryschema te bieden waarin we onze bestanden zo konden organiseren dat we een niveau van samenhang, begrip en onderhoudbaarheid zouden hebben voor het werk dat we doen.
Maar dat is niet alles wat u hoeft te doen om onderhoudbare WordPress-thema's te schrijven. Een andere is om de conventies te volgen die zijn uiteengezet in de WordPress coderingsstandaarden; dit artikel gaat echter niet de normen bekijken. De Codex doet dat prima en we hebben ze in een andere reeks behandeld.
In plaats daarvan gaan we een beetje meer in detail kijken naar enkele van de strategieën en hulpmiddelen die we kunnen gebruiken om ervoor te zorgen dat we onze thema's zo onderhoudbaar mogelijk maken. In deze specifieke post gaan we naar strategieën, waarna we de serie afronden door naar enkele van de beschikbare hulpmiddelen te kijken.
Zoals eerder vermeld, is het één ding om een logische manier te hebben om alle mappen, bestanden en bibliotheken te organiseren die deel uitmaken van uw thema; maar dat is eigenlijk maar de helft van wat er bij het construeren van een thema wordt gebruikt.
Er zijn immers vooraf gedefinieerde sjablonen, functies, naamgevingsconventies en hulpmiddelen die allemaal bijdragen aan het maken van het thema of het testen op het thema om ervoor te zorgen dat het geen verouderde API-aanroepen gebruikt en dat het compatibel is met de meest recente versie. van WordPress.
Daarom denk ik dat het belangrijk is om elk van deze onderwerpen te begrijpen, zowel als iemand die net begonnen is met het bouwen van WordPress-thema's, en als iemand die het al een tijdje doet.
Er is immers nooit een beter moment om te proberen beter te worden in wat je doet. Daarnaast zijn de reacties ook een geweldige plek om door te gaan naar de discussie om alternatieve ideeën te delen.
Maar voordat we daar aankomen, laten we het eigenlijk hebben over enkele praktische dingen die we kunnen doen als het gaat om WordPress-thema's, en dat verhoogt de onderhoudbaarheid van wat we doen.
Ten eerste, als u niet bekend bent met de sjabloonhiërarchie, raad ik u ten zeerste aan de bijbehorende Codex-pagina te lezen voordat u verdergaat met dit artikel.
Kort gezegd, sjablonen kunnen als volgt worden beschreven:
WordPress-sjablonen passen in elkaar als de stukjes van een puzzel om de webpagina's op uw WordPress-site te genereren. Sommige sjablonen (bijvoorbeeld de header- en voettekst-sjabloonbestanden) worden gebruikt op alle webpagina's, terwijl andere alleen onder specifieke omstandigheden worden gebruikt.
Een andere manier om erover na te denken is dit: als het op WordPress aankomt, komt alles wat aan de gebruiker wordt getoond uit de database. Dit omvat de berichttitel, berichtgegevens, berichtcategorieën, berichtinhoud, opmerkingen, enzovoort.
Sjablonen zijn de voertuigen waarmee de informatie aan de gebruiker wordt gepresenteerd. Ze zijn samengesteld uit markup en PHP, gestileerd via CSS, en kunnen enkele effecten hebben die worden toegepast door het gebruik van JavaScript.
Maar, ervan uitgaande dat u niets geavanceerd doet met dingen zoals aangepaste berichttypen en / of aangepaste taxonomieën (een onderwerp voor een andere post, echt), dan is er één uniek ding over de WordPress-sjabloonhiërarchie die zowel als een luxe- als een een probleem met onderhoud, afhankelijk van hoe je het bekijkt.
Merk op dat in het gelinkte Codex-artikel, WordPress standaard zal zijn index.php, header.php, en footer.php sjablonen. De waarheid is, je kunt echt wegkomen met het maken van een heel WordPress-thema door te gebruiken enkel en alleen index.php.
Klinkt nogal aantrekkelijk, toch? Ik bedoel, wie moet zoveel verschillende bestanden maken als je een leuk, klein, lean thema kunt maken dat alles doet wat je nodig hebt.
Maar denk hier eens over na, vanuit het perspectief van het werken met een team van ofwel uw eigen leeftijdsgenoten, van degenen die mogelijk bijdragen aan een open repository, of van degenen die uiteindelijk misschien verdergaan waar u was gebleven.
Als alle code die nodig is om informatie uit de database weer te geven, zich in één bestand bevindt, is de kans groot dat de complexiteit van dat bestand vanaf het begin erg hoog is.
Op het meest basale niveau kijken we naar een enkel bestand met een aantal conditionals, mogelijk enkele switch-instructies enzovoort. En dit alles wordt gedaan omdat u rekening moet houden met de archiefpagina's, de enkele berichtpagina's, de afzonderlijke berichten, de primaire vermelding, enzovoort.
Zie wat ik bedoel?
Maar dan, het creëren van een afzonderlijke bestanden net om die complexiteit te verzachten, kan het een beest op zich zijn. Laten we zeggen dat je dat bijvoorbeeld hebt gedaan single.php voor het weergeven van een enkele post en je hebt page.php voor het weergeven van een pagina en beide sjablonen hebben exact dezelfde informatie behalve single.php heeft bericht metagegevens en page.php doet niet.
Dit is een goed voorbeeld van wanneer u post-metadata kunt extraheren naar zijn eigen gedeeltelijke, zoals we in het vorige artikel hebben besproken. Of misschien haalt u de code uit die verantwoordelijk is voor het weergeven van de inhoud haar gedeeltelijk bezitten.
Hoe het ook zij, het punt dat ik probeer te maken is dat er een evenwicht moet worden gevonden tussen het werken met WordPress-sjablonen en de WordPress-sjabloonhiërarchie..
Ik denk niet dat het een goed idee is om een minimaal aantal sjablonen te gebruiken, maar ik denk ook niet dat het nodig is om elke ondersteunde sjabloon te gebruiken als het leidt tot te veel codeduplicatie. Er is een balans tussen sjablonen en partials.
Uiteindelijk denk ik dat de ervaring over hoe te gebruiken die met de tijd komt, maar van meet af aan deze instelling van geest heeft, kan helpen een niveau van organisatie en onderhoudbaarheid te bieden dat een sprong vooruit is mei begin met niet een klein beetje pre-planning te hebben gedaan.
Als het gaat om het werken met functies en naamgevingsconventies, zijn er meestal twee vuistregels te volgen:
Accentsconagua
terugkeer gegevens en wat zal echo gegevensMaar als u iemand bent die net is begonnen met het ontwikkelen van thema's, of als u iemand bent die zijn vaardigheden wil verbeteren om dit te doen, hoe ziet dit er praktisch uit??
Als het gaat om het uniek benoemen van uw functies, zijn de redenen hiervoor dat u niet per ongeluk botst met een reeds bestaande functie die is gedefinieerd in WordPress of een plug-in die mogelijk in uw omgeving wordt uitgevoerd.
Stel dat u bijvoorbeeld uw eigen functie gaat schrijven die de inhoud filtert voordat deze naar de pagina wordt geretourneerd. De juiste manier om dit te doen is om duidelijk de add_filter functie; noem echter je functie de inhoud?
Nee natuurlijk niet. De reden is omdat WordPress al definieert de inhoud. Als u een functie met die naam hernoemt, krijgt u fouten. Daarom is het altijd het beste om uw functies vooraf te geven met een unieke sleutel, zoals de naam van uw thema of iets dergelijks.
Laten we zeggen dat we een handtekening willen toevoegen aan het einde van onze inhoud en laten we zeggen dat we een thema hebben dat we noemen toppunt. Om dit te doen, raad ik aan een functie genaamd te maken acme_the_content omdat het de naam van het thema identificeert en de naam aangeeft van de functie waaraan het is gekoppeld.
Laten we zeggen dat je elk bericht wilt beëindigen met je naam en Twitter-handvat. Om dit te doen, kunt u dit in uw functions.php het dossier:
'; $ signature. = 'Tom | @tommcfarlin'; $ handtekening. = ''; return $ content. = $ handtekening;
Het is relatief eenvoudig, toch? Het kort is dat ik het volg-formaat probeer te gebruiken bij het maken van mijn eigen verslaafd functies: thema_naam-name_of_hook.
Dit maakt het echt gemakkelijk te begrijpen en te volgen, niet alleen bij het bladeren door de code, maar bij het bekijken van de functies die deel uitmaken van het thema of het bestand dat momenteel actief is in uw IDE.
Zoals eerder vermeld, heeft WordPress nog een andere conventie die het gebruikt en die te maken heeft met als informatie wordt geretourneerd door de aangeroepen functie of wordt geëchood van de aangeroepen functie.
Gelukkig is deze specifieke vuistregel heel gemakkelijk te onthouden:
krijgen_ krijgen_ Je kan vinden sommige afwijkingen, maar dat is de algemene kern van hoe de WordPress API aangeeft hoe hij de gegevens teruggeeft nadat u de functie hebt aangeroepen.
Houd in overeenstemming met ons vorige voorbeeld dat u de gegevens wilt echoën wanneer de functie wordt aangeroepen, dan belt u gewoon de inhoud(); Als u de inhoud van een bericht wilt ophalen, bijvoorbeeld vanuit een aangepaste lus, belt u get_the_content () en sla het op in je eigen variabele.
Misschien iets als dit: $ content_for_later = get_the_content (). Nu heb je de gegevens gelezen voor de inhoud die momenteel gerelateerd is aan het actieve bericht in The Loop en je hebt het in een variabele opgeslagen die je later kunt gebruiken.
Maar weten hoe WordPress zijn functies voor u noemt, is slechts de helft. Je bent immers van plan om een thema of een plug-in te bouwen en je wilt ervoor zorgen dat je consistent blijft met "de WordPress-manier" om dingen te doen, juist?
Voorbeeld: in het bovenstaande voorbeeld, waar we de inhoud hebben gefilterd, hebben we de functie zo voorafgegaan dat deze de naam kreeg acme_the_content, wat aangeeft dat de toppunt thema gaat de inhoud retourneren van waar het ook wordt genoemd binnen het thema.
Wat er zou gebeuren als we de functie een naam zouden geven acme_get_the_content () ?
Nou, technisch gezien zou de functie nog steeds de gegevens echoën waar het ook genoemd werd; het zou echter niet consistent zijn met de WordPress API omdat de ontwikkelaar zou verwachten dat de gegevens naar hen zouden worden teruggestuurd, zodat ze in een variabele zouden kunnen worden opgeslagen of doorgegeven aan een andere functie.
Er is een discrepantie tussen wat de gebruiker verwacht te gebeuren en wat er daadwerkelijk gebeurt.
Als we het hadden over iets in de echte wereld, dan zou dit hetzelfde zijn als een schakelaar op de muur hebben waarvoor de gebruiker verwacht dat wanneer ze de schakelaar omdraaien, er een lampje of een ventilator in dezelfde kamer gaat branden als er in werkelijkheid misschien niets gebeurt of als een lamp of een ventilator in een andere kamer gaat branden.
Daartoe moeten we voorzichtig zijn met het benoemen van onze functies, zodat we niet alleen functies schrijven die niet in botsing komen met andere functies, maar die ook duidelijk worden genoemd, en die aangeven hoe zij zullen de informatie verwerken wanneer de functie wordt aangeroepen.
Zoals vermeld aan het begin van dit artikel, zijn er ook een aantal tools en instellingen die we kunnen installeren en configureren in onze ontwikkelomgeving die ons helpt mogelijke problemen te vangen voordat we uiteindelijk ons thema lanceren..
Dit betekent dat we functies kunnen identificeren die uiteindelijk uit WordPress worden verwijderd, zodat we geen verouderde code schrijven. Daarnaast zijn er manieren om te weten of variabelen die we proberen te openen, bijvoorbeeld geen gedefinieerde indexen of andere vergelijkbare functies hebben.
In het laatste artikel van de serie gaan we daar precies naar kijken. Bekijk in de tussentijd wat hier is behandeld, deel gerust uw vragen en opmerkingen in de onderstaande feed en we zullen proberen deze reeks volgende week weer in te pakken.
