Share
In deze serie bekijken we welke WordPress-taxonomieën zijn, wat hun definitie is, wanneer ze moeten worden gebruikt en hoe ze in onze thema's kunnen worden verwerkt. Om ervoor te zorgen dat we dit zo gedetailleerd mogelijk behandelen, benaderen we dit vanuit het perspectief van een beginner.
Zoals vermeld in de eerste post in de serie, is deze serie niet alleen gericht op beginners. Misschien bent u een tussentijdse WordPress-ontwikkelaar die op zoek is naar nieuwe API's en nieuwe functies in uw werk implementeert, en taxonomieën passen precies daar bij.
Hoe het ook zij, we doen wat we kunnen om ervoor te zorgen dat u zoveel mogelijk informatie in handen krijgt als het gaat om het opnemen van aangepaste taxonomieën in uw WordPress-projecten..
Voordat we kijken naar een daadwerkelijke implementatie van hoe we taxonomieën kunnen incorporeren, moeten we het hebben over enkele uitdagingen die gepaard gaan met het integreren van taxonomieën in ons werk.
In het bijzonder, moeten taxonomieën worden opgenomen als onderdeel van een thema of in een plug-in? Deze vraag is eigenlijk meer een kwestie van "waarom zouden we taxonomieën op deze manier moeten opnemen?" en "wanneer moeten we taxonomieën op deze manier opnemen?"
En om dat te beantwoorden, is het belangrijk om onderscheid te maken tussen de twee opties die we hebben en hoe gegevens worden opgeslagen.
Laten we eerst bespreken hoe taxonomieën intern worden opgeslagen in WordPress. Taxonomieën bestaan uit twee componenten: een taxonomie en een term.
Als u bijvoorbeeld aan Post-indelingen denkt, is de taxonomie dat wel Post formaat en de voorwaarden zijn Standaard, Video, Beeld, Link, enzovoorts. Evenzo kan een andere taxonomie zijn fotografie en de voorwaarden kunnen zijn Film en Digitaal.
In het meest basale geval is de standaard WordPress-taxonomie en termpairing Categorie en Uncategorized dat is bij elke installatie inbegrepen.
Vanaf nu is het belangrijk om te begrijpen hoe deze gegevens worden beheerd in de WordPress-database. Er zijn drie databasetabellen die elk een rol spelen in de relatie tussen taxonomieën en de bijbehorende termen.
Ervan uitgaande dat u met de standaardinstallatie werkt (dat wil zeggen, het voorvoegsel van de tabel is wp_), dan heb je de volgende tabellen met elk de bijbehorende verantwoordelijkheden:
Accentsconagua
wp_terms vertegenwoordigt de termen die behoren tot verschillende taxonomieën. Dit betekent dat als u een fotografie taxonomie met twee termen zijn Film en Digitaal en je hebt een taxonomie genaamd Type met Kleur en Zwart en wit als termen zijn Film, Digitaal, en Kleur zullen alle verblijven binnen de wp_terms tafel.wp_term_taxonomy is een databasetabel die verantwoordelijk is voor het opslaan van de beschrijving van de termen die zijn opgeslagen in de wp_terms tafel. Zeg bijvoorbeeld dat je een hebt Kleur termijn en de term wordt beschreven als "Foto's die zijn ontwikkeld in levendige kleuren." Dan zou deze beschrijving in de wp_term_taxonomy tafel.wp_term_relationships is aantoonbaar degene die de grootste leercurve heeft voor nieuwe ontwikkelaars. Deze tabel handhaaft het verband tussen welke taxonomieën gerelateerd zijn aan welke postsoorten. Als u bijvoorbeeld een standaardinstallatie gebruikt, slaat deze tabel de relatie op tussen de categorieterm en elk bericht waaraan deze is gekoppeld.Nu we begrijpen hoe gegevens worden opgeslagen, kunnen we bespreken wanneer taxonomieën zinvol zijn binnen de context van thema's en in de context van plug-ins.
Over het algemeen is het een goede vuistregel om te weten dat WordPress-thema's moeten zijn voor de presentatie van gegevens en dat plug-ins voor functionaliteit moeten zijn. Dat wil zeggen, thema's bieden het formaat voor hoe de gegevens eruit zien en plug-ins breiden de kernfunctionaliteit van WordPress uit.
Er is ook het begrip extensies die lijken op themaspecifieke plug-ins en plug-in-specifieke plug-ins, maar dat valt buiten het bestek van dit artikel. Laten we voorlopig de discussie op het niveau van thema's en plug-ins houden.
Laten we zeggen dat u aan een thema werkt en dat u een aangepaste taxonomie wilt introduceren in het thema. Zorg ervoor dat u, in overeenstemming met onze voorbeelden die in de serie worden gebruikt, een portfoliothema wilt maken en wilt introduceren een fotografie taxonomie. Het thema is immers bedoeld om gebruikers hun werk te laten zien.
Laten we zeggen dat u over een jaar of zo met hetzelfde thema wilt werken, maar dat u een belangrijke upgrade wilt uitvoeren. Misschien wil je de taxonomieën generaliseren zodat mensen het niet hoeven te gebruiken net voor fotografie. In plaats daarvan kunnen ze het gebruiken voor korte gedichten of geschriften, tekeningen, enzovoort.
Het probleem is dat je nu de fotografie taxonomie hardcoded in het thema zodat iedereen die het gebruikt en installeert het die bepaalde taxonomie krijgt ongeacht of ze fotografie willen laten zien of niet.
Natuurlijk is het volledig mogelijk om het thema helemaal opnieuw op te bouwen en de taxonomie-functie te abstraheren in iets meer algemeen, maar wat gebeurt er voor de gebruikers die willen upgraden? Verliezen ze de gegevens waarmee ze maanden of jaren hebben gewerkt? Hoe zullen hun gegevens worden georganiseerd? Zitten ze vast met de huidige versie van het thema waarmee ze werken??
Uiteraard is er veel te overwegen wanneer je aan een thema als dit werkt. Maar daar komt het belang van het segmenteren van presentatie en functionaliteit om de hoek kijken.
Het is volledig mogelijk om een thema te bouwen dat is ontworpen om werk in een portfoliostijl te presenteren zonder dat je echt een type taxonomie in het thema hoeft te coderen. Bouw in plaats daarvan de functionaliteit in een plug-in en installeer vervolgens de plug-in naast het thema waarmee u aan het bouwen bent. U krijgt dan de voordelen van de portfoliobendering zonder dat gebruikers lang vastzitten in het gebruik van uw thema en mogelijk hun gegevens kwijtraken bij het upgraden naar een nieuw thema.
Om veel van de hierboven genoemde redenen is het gemakkelijk te begrijpen waarom het implementeren van aangepaste taxonomieën in de context van plug-ins zinvol is.
Dit wil niet zeggen dat het nooit in thema's zou moeten gebeuren. Immers, daar zijn niche-thema's die zich richten op een zeer specifiek publiek en die een alles-in-een oplossing voor hun klanten willen bieden. Dat is prima, maar als u dit type functionaliteit met een zo breed mogelijke aantrekkingskracht wilt introduceren, is het zinvol om de functionaliteit in een plug-in samen te stellen.
Niet alleen krijg je het voordeel dat gebruikers hun gegevens kunnen overdragen van thema naar thema zonder de categorisering van hun gegevens te verliezen, maar je geeft ze ook het voordeel dat ze de onafhankelijkheid tussen de presentatie van hun gegevens en de opslag kunnen behouden. van hun gegevens.
En als u een thema-ontwikkelaar bent, kunt u nog steeds werken om thema's te maken die specifiek zijn ontworpen rond de plug-in. Misschien zou je een thema willen aanbieden voor fotografen, een voor schrijvers en een voor kunstenaars. Met deze strategie kunt u nog altijd proberen een bepaald type van de markt te veroveren, terwijl uw plug-in compatibel is met de variaties van uw werk, zodat u niet aan verschillende thema's kunt werken en uw klanten de mogelijkheid krijgt om van thema te veranderen terwijl u nog steeds uw producten gebruikt.
Omdat we hebben bekeken hoe WordPress taxonomieën binnen de database beheert, en we hebben gekeken naar enkele redenen waarom thema's en plug-ins in combinatie met elkaar zouden moeten werken om specifieke functies aan te bieden, gaan we kijken naar hoe we dit kunnen maak onze eigen plug-in die aangepaste taxonomie-functionaliteit implementeert die we als voorbeeldgegevens in deze reeks hebben gebruikt.
In de tussentijd kunt u opmerkingen, vragen of algemene feedback achterlaten in het opmerkingenveld hieronder.
