Hoe te werken met WordPress Term Meta begrip van taxonomieën

In een recente serie hebben we alles besproken over hoe we met metadata konden werken voor verschillende van de grote klassen in WordPress. 

Dit omvatte:

  • Post metadata
  • Metadata van gebruiker
  • Metagegevens van reacties

Gedurende de serie hebben we een beetje gesproken over hoe WordPress 4.4 het idee introduceerde van termmetadata. Ik wilde het concept niet presenteren binnen de context van die serie omdat het afhankelijk was van het begrijpen van iets dat beginners vaak een beetje moeite geeft.

Dat is wat deze serie is bedoeld om aan te pakken.

Over WordPress, Taxonomies en Voorwaarden

In WordPress gaan de concepten van taxonomieën en termen samen. Ik zal hier in een ogenblik meer over uitweiden. Maar om goed te werken met termmetagegevens, vind ik het belangrijk om taxonomieën, termen en hun relaties te begrijpen. Anders, hoe kunnen we anders een end-to-end begrip hebben van wat we doen wanneer we op programmatisch niveau met hen werken??

In deze vervolgserie van twee artikelen gaan we kijken naar taxonomieën, wat ze zijn, de rol die ze spelen in WordPress en hun relatie tot termen. Daarna gaan we onze aandacht vestigen op de voorwaarden en werken met de nieuwe term metadata API.

Als u de vorige serie nog niet hebt gelezen, raad ik u aan dit te doen, omdat dit enige basis legt voor de manier waarop de API die we gaan verkennen, werkt. Als u echter ervoor kiest om dit niet te doen, is dat goed. Deze serie moet alles omvatten wat je moet weten.

Wat zijn taxonomieën?

Zoals gedefinieerd in de Codex:

In WordPress is een "taxonomie" een groeperingsmechanisme voor sommige berichten (of links of aangepaste berichttypen).

Toegegeven, het is geen woord dat je vaak hoort en soms raken anderen in de war als ze over taxonomieën en voorwaarden praten. Dat wil zeggen, ze gebruiken een voorbeeldzin als een voorbeeld van een taxonomie, maar wat ze in dat geval doen, is een term gebruiken. Ik zal daar in een klein beetje op ingaan.

Simpel gezegd, denk aan taxonomieën als manieren om dingen samen te groeperen. Out of the box, WordPress wordt geleverd met twee taxonomieën: categorieën en labels. We zullen elk moment in meer detail bespreken.

Nu is er een voorbehoud, tenminste als het gaat om WordPress: taxonomieën kunnen hiërarchisch of niet-hiërarchisch zijn. Misschien is het meest voorkomende voorbeeld van het bovenstaande idee als volgt:

  • Wanneer u een categorie maakt in WordPress, kunt u deze maken als een categorie op het hoogste niveau of als een subcategorie van een bestaande categorie. Bijvoorbeeld, een adelaar kan een subcategorie zijn van vogelstand
  • Wanneer u een tag in WordPress maakt, maakt u een enkel woord of een zin waarmee u uw post wilt (laten) markeren (of letterlijker). Er is geen idee van onderliggende tags of bovenliggende tags.

En dat is het verschil tussen hiërarchische en niet-hiërarchische taxonomieën. Het is gemakkelijk, toch? Degenen die kinderen ondersteunen, zoals categorieën, zijn hiërarchisch; degenen die geen kinderen ondersteunen, zoals tags, zijn niet-hiërarchisch.

Met het werk dat we in deze serie gaan doen, speelt dit niet in het bijzonder een rol anders dan ons te helpen een beter begrip te krijgen van wat deze taal betekent in de context van onze ontwikkelingsinspanningen..

Maar wanneer we beginnen met het programmatisch maken van deze entiteiten en het toevoegen van metagegevens, mag er geen verwarring bestaan ​​over wat we doen.

Wat zijn voorwaarden?

We hebben taxonomie gedefinieerd, maar hoe zit het met termen? Van de Codex:

In WordPress is een term een ​​classificatie, groep of subset van een taxonomie, waarbij de laatste een categorie, tag of aangepaste taxonomie kan zijn. Standaard hebben termen een titel, een naaktslak en een beschrijving. Hiërarchische taxonomieën zoals categorieën kunnen een bovenliggende term definiëren.

Gezien wat we tot nu toe hebben besproken, is dit precies wat we zouden moeten verwachten. Dat wil zeggen, termen worden geassocieerd met taxonomieën. Termen hebben echter verschillende opmerkelijke aspecten waarvan we ons bewust moeten zijn, vooral als we ze gaan maken of programmeren.. 

Dat wil zeggen dat de voorwaarden zijn samengesteld uit:

  • een naaktslak
  • een titel
  • een beschrijving

Onthoud dat als we werken met een hiërarchische taxonomie, zoals een categorie, de term optioneel een bovenliggende term kan bevatten. 

Voor alle duidelijkheid, dit betekent niet dat een taxonomie niet beschikt over een reeks informatie. Een taxonomie vereist bijvoorbeeld een naam, een berichttype waaraan het is gekoppeld en een aantal argumenten die buiten de scope van deze artikel. We zullen hier meer in het volgende artikel over lezen.

Hoe zijn ze verwant?

De relatie tussen taxonomieën en termen is enigszins symbiotisch, wat betekent dat de een niet zonder de ander kan bestaan. Dit geldt vooral omdat het betrekking heeft op hiërarchische taxonomieën.

Ten eerste biedt de WordPress Codex voor geïnteresseerden een diagram dat de relatie verklaart:

U hebt bijvoorbeeld misschien een Categorie taxonomie, maar je moet er minstens één term aan koppelen. Dit is de reden waarom WordPress standaard wordt geleverd Uncategorized termijn.

Aan de andere kant is het mogelijk om een Label taxonomie, maar geen tags die in de database voorkomen. 

Maar kunnen we als ontwikkelaars een stap verder gaan? Dat wil zeggen, hoewel al deze programmatisch kunnen worden gemaakt, kunnen gebruikers ze ook maken en toevoegen. Tenminste, als de gebruikersinterface een optie voor hen blootstelt om dat te doen. 

Voorbeeld: als u naar de gebruikersinterface van WordPress kijkt, hebben we allemaal de mogelijkheid om categorieën en tags te maken.

Als u echter een programmeur bent en bepaalde taxonomieën en termen in de database wilt opnemen, dan hebt u de mogelijkheid om dat te doen en te voorkomen dat gebruikers ze toevoegen en verwijderen uit de gebruikersinterface..

Hoe zit het met Term-metadata?

We hebben de definities van taxonomieën en termen uiteengezet, evenals de verschillen daartussen, maar één vraag blijft: waarom hebben we metagegevens over de term nodig? Of, misschien als alternatief, wat is de point of term metadata?

Dat is een goede vraag, en het is waarschijnlijk een deel van waarom deze functie pas in WordPress 4.4 werd geïntroduceerd. Interessant genoeg is het ticket voor deze functie pas zes jaar geleden geïntroduceerd. De primaire reden voor het ticket (rechtstreeks van Trac zelf) luidt:

Op dit moment is er geen speciale manier om extra gegevens op te slaan voor taxonomie. Ontwikkelaars van plug-ins moeten hun eigen methode ontwikkelen voor het opslaan van deze gegevens, b.v. door ze gecodeerd op te slaan in het beschrijvingsveld of met set_option (). Het is goed om hiervoor nieuwe functies toe te voegen, bijvoorbeeld add_taxonomy_data () / get_taxonomy_data ().

Als u een ervaren WordPress-ontwikkelaar bent, is dit volkomen logisch. Maar we zijn nog niet allemaal zover, dus we weten niet zeker welke voordelen dit ons oplevert.

Zoals alle andere API's, kunnen we hier informatie opslaan over elke willekeurige term die in de database aanwezig is. Dit kan alles zijn gerelateerd aan het tijdstip waarop de term is gemaakt, wie de term heeft gemaakt of hoeveel posts zijn getagd met een bepaalde term, of het stelt ons in staat een afbeelding te koppelen aan een term.

Omdat het een niveau van willekeurige informatie ondersteunt, zijn de mogelijkheden extreem breed voor wat we kunnen doen met deze informatie. En vanaf het volgende artikel zullen we precies dat zien.

Conclusie

Op dit moment moet u alles hebben dat u moet weten om met taxonomieën en voorwaarden te werken. Natuurlijk moet je de Codex een paar keer doorlezen terwijl je aan een plug-in, thema of aangepaste oplossing voor een klant werkt, maar dat is niet abnormaal, zelfs voor een ervaren ontwikkelaar.

In het volgende artikel zullen we bekijken hoe we moeten werken met termmetagegevens. In het bijzonder zullen we de voorbeeldcode bekijken, deze aansluiten op een van de standaardthema's in WordPress en de database bewaken terwijl we wijzigingen aanbrengen.

Als je in de tussentijd geïnteresseerd bent in WordPress, softwareontwikkeling of de kruising van de twee, vergeet dan niet om mijn profielpagina te bekijken die links bevat naar alle cursussen en zelfstudies die ik heb gepubliceerd op Envato Tuts+. 

Ten tweede, aarzel niet om mij te volgen op Twitter op @tommcfarlin, waar ik vaak praat over en bronnen deel met betrekking tot WordPress, of mijn blog volg waar ik dagelijks schrijf over het werk dat ik doe met WordPress of onderwerpen die tangentieel gerelateerd zijn ernaar toe.

Tot slot, als u op zoek bent naar andere hulpprogramma's om uw groeiende verzameling hulpprogramma's voor WordPress of voor code te bestuderen en beter bekend te worden in WordPress, vergeet dan niet te zien wat we beschikbaar hebben in Envato Market.

Tot die tijd, aarzel dan niet om vragen of opmerkingen achter te laten, en ik zal doen wat ik kan om ze allemaal te beantwoorden.