Share
I en nylig serie snakket vi alt om hvordan vi kunne jobbe med metadata for flere av de store klassene i WordPress.
Dette inkluderte:
Gjennom hele serien snakket vi litt om hvordan WordPress 4.4 introduserte ideen om termometadata. Jeg ville ikke presentere konseptet i sammenheng med den serien fordi det var avhengig av å forstå noe som ofte gir nybegynnere litt problemer.
Det er hva dette serier skal adressere.
I WordPress går begreppene om taksonomier og vilkår sammen. Jeg vil utdype mer om dette på et øyeblikk. Men for å jobbe riktig med termometadata, tror jeg det er viktig å forstå taksonomier, vilkår og forhold. Ellers, hvordan ellers kan vi få en slutt-til-ende forståelse av hva vi gjør når vi jobber med dem på et programmatisk nivå?
I denne toartige oppfølgingsserien skal vi ta en titt på taksonomier, hva de er, hvilken rolle de spiller i WordPress, og deres forhold til vilkår. Da skal vi henvende oss til vilkårene og hvordan vi skal jobbe med den nye termen metadata API.
Hvis du ennå ikke har lest den forrige serien, anbefaler jeg at du gjør det slik at det legger grunnlag for hvordan API-en vi skal utforske, fungerer. Hvis du imidlertid velger å ikke gjøre det, er det greit. Denne serien skal dekke alt du trenger å vite.
Som definert i Codex:
I WordPress er en "taksonomi" en gruppemekanisme for enkelte innlegg (eller linker eller egendefinerte innleggstyper).
Admittedly, det er ikke et ord som du ofte hører, og noen ganger vil andre bli forvirret når man snakker om taksonomier og vilkår. Det vil si, de vil bruke et eksempeleksempel som et eksempel på en taksonomi, men hva de gjør, bruker i så fall en term. Jeg vil berøre det med litt.
Enkelt sagt, tenk på taksonomier som måter å gruppere ting sammen. Ut av esken, WordPress leveres med to taksonomier: kategorier og tags. Vi snakker om hver av disse mer detaljert øyeblikkelig.
Nå er det en advarsel, i hvert fall når det gjelder WordPress: taksonomier kan være hierarkiske eller ikke-hierarkiske. Kanskje det vanligste eksemplet på den ovennevnte ideen er som følger:
Og det er forskjellen mellom hierarkiske og ikke-hierarkiske taksonomier. Det er enkelt, ikke sant? De som støtter barn, som kategorier, er hierarkiske; de som ikke støtter barn, som tagger, er ikke-hierarkiske.
Med det arbeidet vi skal gjøre i denne serien, har dette ikke særlig en annen rolle enn å hjelpe oss med å få en dypere forståelse av hva dette språket betyr i sammenheng med vår utviklingsarbeid.
Men når vi begynner å lage disse enhetene programmatisk og legge til metadata til dem, bør det ikke være noen forvirring om hva vi gjør.
Vi har definert taksonomi, men hva med begreper? Fra Codex:
I WordPress er et begrep en klassifisering, gruppe eller undergruppe av en Taxonomy, hvor sistnevnte kan være en kategori, tag eller egendefinert taxonomy. Som standard har vilkårene en tittel, en slug og en beskrivelse. Hierarkiske taksonomier som kategorier kan definere en overordnet term.
Gitt det vi har diskutert så langt, er dette akkurat hva vi bør forvente. Det vil si at vilkårene er knyttet til taksonomier. Vilkårene har imidlertid flere bemerkelsesverdige aspekter til dem som vi bør være oppmerksom på, spesielt hvis vi skal lage dem eller arbeide med dem programmatisk.
Det vil si at vilkårene er sammensatt av:
Husk at hvis vi jobber med en hierarkisk taksonomi, som en kategori, så kan termen eventuelt inneholde en overordnet term.
For å være tydelig betyr dette ikke at en taksonomi ikke har et sett med informasjon knyttet til den. For eksempel krever en taksonomi et navn, en posttype som den er knyttet til, og en rekke argumenter som ligger utenfor omfanget av dette artikkel. Vi får se mer om dette i den neste artikkelen.
Forholdet mellom taksonomier og begreper er noe symbiotisk, noe som betyr at man ikke kan eksistere uten den andre. Dette gjelder spesielt når det gjelder hierarkiske taksonomier.
For det første, for de som er interessert, gir WordPress Codex et diagram som forklarer forholdet:
For eksempel kan du ha en Kategori taksonomi, men du må ha minst ett begrep knyttet til det. Dette er grunnen til at WordPress leveres med standard Uncategorized begrep.
På den annen side er det mulig å lage en stikkord taksonomi, men har ingen merker som finnes i databasen.
Men, som utviklere, kan vi ta dette et skritt videre? Det er, selv om alle disse kan opprettes programmatisk, har brukerne muligheten til å lage og legge til dem også. I det minste, hvis brukergrensesnittet viser et alternativ for dem å gjøre det.
Case in point: Når du ser på WordPress brukergrensesnitt, har vi alle muligheten til å lage kategorier og koder.
Hvis du imidlertid er programmerer, og du ønsker å knytte bestemte taksonomier og vilkår til databasen, har du muligheten til å gjøre det, og for å hindre brukere i å legge til og fjerne dem fra brukergrensesnittet.
Vi har lagt ut definisjonene av taksonomier og vilkår, samt forskjellene mellom dem, men ett spørsmål gjenstår: Hvorfor trenger vi termometadata? Eller, kanskje alternativt, hva er poenget med metadata?
Det er et godt spørsmål, og det er trolig en del av hvorfor denne funksjonen ikke ble introdusert før WordPress 4.4. Interessant nok ble billetten for denne funksjonen introdusert for over seks år siden. Den primære begrunnelsen for billetten (rett fra Trac selv) sier:
For øyeblikket er det ingen dedikert måte å lagre tilleggsdata for taksonomi. Pluginutviklere må utvikle sin egen metode for lagring av disse dataene, f.eks. ved å lagre dem kodet i beskrivelsesfeltet eller ved å bruke set_option (). Det vil være fint å legge til nye funksjoner for dette, f.eks. add_taxonomy_data () / get_taxonomy_data ().
Hvis du er en erfaren WordPress-utvikler, gir dette perfekt mening. Men ikke alle av oss er opp til det nivået ennå, så vi er ikke sikre på hvilke fordeler dette kjøper oss.
Som alle andre APIer, tillater det oss å lagre informasjon om et gitt uttrykk som eksisterer i databasen. Dette kan være alt relatert til tidspunktet da begrepet ble opprettet, som skapte begrepet, eller hvor mange innlegg som er merket med et gitt uttrykk, eller det tillater oss å knytte et bilde med en term.
Fordi den støtter et nivå av vilkårlig informasjon, er mulighetene svært bredt når det gjelder hva vi kan gjøre med denne informasjonen. Og begynner i neste artikkel, vi kommer til å se akkurat det.
På dette tidspunktet bør du ha alt du trenger å vite for å jobbe med taksonomier og vilkår. Visst, du må sannsynligvis lese Codex et par ganger mens du jobber med et plugin, tema eller en tilpasset løsning for en klient, men det er ikke unormalt, selv for en erfaren utvikler.
I neste artikkel tar vi en titt på hvordan man arbeider med termometadata. Spesielt ser vi på eksempelkode, kobler den opp til en av standardtemaene i WordPress, og overvåker databasen når vi gjør endringer.
I mellomtiden, hvis du er interessert i WordPress, programvareutvikling eller skjæringspunktet til de to, husk å ta en titt på min profilside som inneholder lenker til alle kursene og opplæringsprogrammene jeg har publisert på Envato Tuts+.
For det andre, ikke nøl med å følge meg på Twitter på @tommcfarlin, hvor jeg ofte snakker om og deler ressurser knyttet til WordPress, eller følger bloggen min der jeg skriver daglig om arbeidet jeg gjør med WordPress eller emner som er tangentielt relaterte til det.
Endelig, hvis du leter etter andre verktøy for å hjelpe deg med å bygge ut ditt voksende sett med verktøy for WordPress eller koden for å studere og bli mer kjent med WordPress, ikke glem å se hva vi har tilgjengelig i Envato Market.
Inntil da, ikke nøl med å legge igjen spørsmål eller kommentarer nedenfor, og jeg vil gjøre det jeg kan for å svare på hver enkelt av dem.
Accentsconagua