Begynnerveiledningen til WordPress-taxonomier Temaer eller Plugins?

I denne serien tar vi en titt på hvilke WordPress-taksonomier som er, deres definisjon, når de skal brukes, og hvordan de skal innlemmes i våre temaer. For å sikre at vi dekker dette så mye som mulig, nærmer vi oss dette fra en nybegynners perspektiv.

Som nevnt i første innlegg i serien, er denne serien ikke rettet mot nybegynnere. Kanskje du er en mellomliggende WordPress-utvikler som ser ut til å begynne å forgrene seg inn i nye APIer og implementere nye funksjoner i arbeidet ditt og taksonomiene passer regningen for akkurat det.

Uansett, gjør vi det vi kan for å sikre at du er bevæpnet med så mye informasjon som mulig når det gjelder å inkorporere egendefinerte taksonomier i WordPress-prosjekter.

Hvorfor vs Når

Før vi ser på en faktisk implementering av hvordan å innlemme taksonomier, må vi snakke om noen av utfordringene som følger med å inkorporere taksonomier i arbeidet vårt.

Spesielt bør taxonomier inkluderes som en del av et tema eller i et plugin? Dette spørsmålet er egentlig mer et spørsmål om "hvorfor skal vi inkludere taksonomier på denne måten?" og "når skal vi inkludere taksonomier på denne måten?"

Og for å svare på det, er det viktig å skille mellom de to alternativene vi har og hvordan data lagres.

Hvordan dataene lagres

Først, la oss diskutere hvordan taksonomier lagres internt innen WordPress. Taxonomier består av to komponenter: En taksonomi og et begrep.

  1. En taksonomi representerer hvordan informasjon er gruppert sammen.
  2. Et begrep representerer typen data som tilhører denne taksonomien.

For eksempel, når du tenker på Postformater, er taksonomien Postformat og vilkårene er Standard, video, Bilde, link, og så videre. Tilsvarende kan en annen taksonomi være Photography og betingelsene kan være Film og digitalt.

I det mest grunnleggende tilfellet er standard WordPress taksonomi og term pairing Kategori og Uncategorized som er utstyrt med alle installasjoner.

Nå, herfra, er det viktig å forstå hvordan disse dataene administreres i WordPress-databasen. Det er tre databasetabeller som hver spiller en rolle i forholdet mellom taksonomier og deres tilknyttede vilkår.

Forutsatt at du jobber med standardinstallasjonen (det vil si, er tabellprefikset wp_), så har du følgende tabeller med de tilsvarende ansvarene:

  1. wp_terms representerer betingelsene som tilhører ulike taksonomier. Dette betyr at hvis du har en Photography taksonomi med to ord Film og digitalt og du har en taksonomi kalt Type med Farge og Svart og hvit å være vilkår, da Film, digitalt, og Farge vil alle bo i wp_terms bord.
  2. wp_term_taxonomy er en database tabell som er ansvarlig for å lagre beskrivelsen av vilkårene lagret i wp_terms bord. Si for eksempel at du har en Farge Termen og termen er beskrevet som "Fotografier som er utviklet i levende farger." Da ville denne beskrivelsen ligge i wp_term_taxonomy bord.
  3. De wp_term_relationships er uten tvil den som har den største læringskurven for nye utviklere. Denne tabellen opprettholder sammenhengen mellom hvilke taksonomier som er relatert til hvilke posttyper. For eksempel, gitt en standardinstallasjon, lagrer denne tabellen forholdet mellom kategoribegrepet og hvert innlegg som det er tilknyttet.

Nå som vi har en forståelse for hvordan data lagres, kan vi diskutere når taksonomier gir mening i sammenheng med temaer og innenfor rammen av plugins.

Temaer eller Plugins?

Generelt sett er en god tommelfingerregel å merke seg at WordPress-temaer bør være for presentasjon av data, og plugins bør være for funksjonalitet. Det vil si, temaer gir formatet for hvordan dataene ser ut, og plugins utvider kjernefunksjonaliteten til WordPress.

Det er også begrepet utvidelser som er tema-spesifikke plugins og plugin-spesifikke plugins, men det er utenfor rammen av denne artikkelen. For nå, la oss holde diskusjonen på nivå med temaer og plugins.

La oss si at du jobber med et tema, og du vil introdusere en tilpasset taksonomi inn i temaet. I samsvar med eksemplene våre som brukes i serien, la oss si at du vil opprette et porteføljetema, og du vil introdusere en Photography taksonomi. Tross alt vil temaet tillate brukere å vise frem sitt arbeid.

La oss da si at du vil jobbe med samme tema om et år eller så, men du vil utføre en stor oppgradering. Kanskje du vil generalisere taksonomiene slik at folk ikke trenger å bruke den bare for fotografering. I stedet kan de bruke den til korte dikt eller skrifter, tegninger og så videre. 

Problemet er at du nå har Photography taksonomi hardcoded inn i temaet slik at alle som bruker den og installerer den får den spesielle taksonomien, uansett om de vil vise fotografering eller ikke.

Visst, det er helt mulig å gjenoppbygge temaet fra grunnen og abstrahere taksonomifunksjonen til noe mer generelt, men hva skjer for brukerne som vil oppgradere? Mister de dataene de har brukt måneder eller år med å jobbe med? Hvordan kommer dataene til å bli organisert? Er de fast med den nåværende versjonen av temaet de jobber med?

Tydeligvis er det mye å vurdere når du arbeider med et tema som dette. Men det er her viktigheten av segmentering av presentasjon og funksjonalitet kommer inn i spill.

Det er helt mulig å bygge et tema utformet for å vise frem arbeid i en porteføljestil uten å måtte hardkodes noen form for taksonomi i temaet. I stedet skal du bygge funksjonaliteten i et plugin og deretter installere pluginet sammen med temaet du bygger. Derefter får du fordelene ved porteføljepresentasjonen uten at brukerne er låst inn i å bruke temaet ditt for lenge og potensielt mister dataene sine når de oppgraderes til et nytt tema.

Et ord om kompatibilitet

For mange av årsakene som er nevnt ovenfor, er det lett å se hvorfor implementering av egendefinerte taksonomier i sammenheng med plugins er fornuftig.

Dette er ikke å si at det aldri skal gjøres i temaer. Tross alt, der er nisje-temaer som retter seg mot et svært spesifikt publikum, og som søker å gi en alt-i-ett-løsning for sine kunder. Det er greit, men hvis du ønsker å introdusere denne typen funksjonalitet med størst mulig appell, kan det være mye fornuftig å bygge funksjonaliteten i et plugin..

Ikke bare får du fordelene ved å gi brukerne muligheten til å porte data fra tema til tema uten å miste kategoriseringen av dataene sine, men du gir dem også fordelen av å kunne opprettholde uavhengighet mellom presentasjonen av dataene deres og lagringsplassen av deres data.

Og hvis du er en temautvikler, kan du fortsatt jobbe for å lage temaer som er utformet spesielt rundt plugin. Kanskje du ønsker å tilby et tema for fotografer, en for forfattere og en for kunstnere. Med denne strategien kan du fortsatt sikte på å fange en bestemt type markedet samtidig som pluginet ditt er kompatibelt med variasjonene i arbeidet ditt, og frigjør deg til å jobbe på forskjellige temaer og gir kundene muligheten til å flytte mellom temaer alt mens du fortsatt bruker produktene dine.

Neste

Siden vi har vurdert hvordan WordPress administrerer taksonomier i databasen, og vi har sett på noen grunner til hvorfor temaer og plugins skal fungere sammen med hverandre for å tilby spesifikke funksjoner, skal vi se på hvordan vi kan lag din egen plugin som implementerer tilpasset taksonomi-funksjonalitet som vi har brukt som eksempeldata i hele denne serien.

I mellomtiden er du velkommen til å legge igjen kommentarer, spørsmål eller generell tilbakemelding i kommentarfeltet nedenfor.