WordPress template hierarchy er en av de mest innflytelsesrike tingene i livet til temautviklere. Brukere må kanskje forstå det, plugins må kanskje samhandle med det, men generelt er det tema som handler om malhierarkiet.
det er Fordi Det Er WordPress-malhierarkiet som bestemmer hvilken av filene i et tema som brukes på et gitt tidspunkt. Det vil si: malhierarkiet er grunnlaget For WordPress themers gjør sin kunst.
hensikten med denne artikkelen er å belyse denne ideen ytterligere. Vi vil definere hva malhierarkiet gjør, hvorfor du trenger å vite om det å være en effektiv modifikator Av WordPress-nettsteder, og vi snakker om hvordan du skal jobbe med det og (veldig kort) hvordan det fungerer.
Hva er Malhierarkiet?
i hjertet er malhierarkiet valgstrukturen WordPress bruker for å bestemme hvilken fil i temaet som skal brukes til å generere den fulle, endelige HTML for en gitt side på WordPress-nettstedet ditt.
WordPress må ha en måte å vite hvordan å samhandle med temaet. Det ville være mulig at noen kunne skrive ulike typer komplekse PHP logikk for deres tema som forklarte WordPress hvordan å samhandle med det. Det kan kanskje være EN PHP-klasse som matchet Et WordPress-definert grensesnitt (i objektorientert programmeringsforståelse) som hvert tema måtte svare på.
men det er komplisert-å lese, enn si å gjøre. Og det er nettopp poenget med malhierarkiet: For WordPress å kunne bruke forskjellige temaer, men også gjøre det relativt enkelt å lage og endre temaer, var det nødvendig med en enklere løsning. Og det er det som er malhierarkiet.i hjertet er malhierarkiet valgstrukturen WordPress bruker For å bestemme hvilken fil i temaet som skal brukes til å generere den fulle, endelige HTML-KODEN for en gitt side på WordPress-nettstedet ditt.De fleste filer I Et WordPress-tema er faktisk medlemmer av malhierarkiet, Og WordPress vil velge å ringe på en av dem, avhengig av hvilken type informasjon den prøver å vise.
Gå I Malhierarkiet
Hvis WordPress må vise innleggene (eller en hvilken som helst innholdstype) av en bestemt forfatter (bruker) på Et WordPress-nettsted, har Det et par behov. Primært:
- Det må gjøre det enkelt for noen å lage eller endre et tema for å tilpasse en side
- Det må sørge for at hvis ingen tilpasninger var nødvendig, vil det ha noe å bruke
for å oppnå dette, vil malhierarkiet prøve forskjellige filer i det aktive temaet. Hvis de eksisterer, vil de bruke dem. Hvis de ikke gjør det, vil det fortsette.
Så når vi ser etter malen som skal brukes til å presentere alle innleggene for gitt forfatter, la oss gjøre at forfatterne brukernavn «david» som har en numerisk idav3. (Sikkert en tilfeldighet. ; P) WordPress trenger å vite hvilken fil fra ditt nåværende tema som skal brukes. Så her er hvordan det ser ut gjennom temafilene dine:
- Finnes filen
author-david.php? Nei… - finnes filen
author-3.php? Nei… - finnes filen
author.php? Nei… - finnes filen
archive.php? Nei… - finnes filen
index.php? Ja!
Du vil legge merke til at det er fem » nei » s før WordPress får et ja. Hver av dem, og følgende spørsmål er malhierarkiet. Så Snart WordPress kommer til et » ja » på et av disse spørsmålene, er malhierarkiets rolle ferdig. Men dette er veldig viktig.
filen som er funnet er ansvarlig FOR HTML på hele siden. Bokstavelig talt alt Som WordPress gjør eller viser på en side på nettstedet ditt, kommer fra en enkelt malhierarkifil i temaet ditt. (Som du sikkert allerede vet, betyr det ikke at Alle Ting WordPress gjør er fastkjørt i den filen, men måtene som de andre tingene blir trukket inn, er utenfor omfanget av denne artikkelen.)
så det er disse spørsmålene (WordPress bestemte seg for å se etter basert på NETTADRESSEN personen besøker) som utgjør malhierarkiet. Og bare så du vet, hvis du ikke har en index.php, har Du ikke Et WordPress-tema. Det er siste stopp for alle deler av malhierarkiet.
The Ultimate Fallback: Hva og Hvorfor
som jeg nettopp sa, uten en index.php, har Du ikke Et WordPress-tema. Men hvis du har en, trenger du egentlig ikke andre filer du kan bruke fra malhierarkiet. At den andre tingen å innse.
WordPress trenger, som vi sa ovenfor, viss sikkerhet for at det alltid vil kunne lage en side for sluttbrukeren. Et tema må gi det. Så det er hva malhierarkiet er for. Men behovet for en endelig tilbakebetaling er absolutt, Og Derfor Lar WordPress deg ikke aktivere et tema som ikke har enindex.php – fil.
Hvorfor WordPress Malhierarkiet Eksisterer
malhierarkiet eksisterer for å gjøre det enklere for tema designere og utviklere å tilpasse utseendet På Et WordPress-nettsted. Det er veldig vanlig for en klient å gjøre» tag archive » – sidene for bloggen sin forskjellig fra single-post-siden. Så WordPress malhierarki støtter det behovet.
som vi nevnte ovenfor, finnes det alternativer til malhierarkiet som man kan forestille seg. Men få av dem er noe bra. Og det er i utgangspunktet hele grunnen til at malhierarkiet eksisterer.
En Rask Diskusjon Av Barn Temaer
Som du kanskje vet, WordPress har disse tingene kalt barn temaer. Og Virkelig, WordPress barnetemaer er mer enn halvparten av grunnen til å elske malhierarkiet. Barnetemaer er måten designere og utviklere kan lage små tilpasninger til bestemte sider på et nettsted uten å måtte lage et helt tema for seg selv.
den fulle utformingen av barn temaer er et tema for diskusjon langt utover denne artikkelen. For å lære mer om barnetemaer, vil du bli godt betjent av disse to artiklene På WPShout, eller denne på WordPress.org nettstedet.kjernen ting å vite om barn temaer er At WordPress mal hierarkiet er klar over dem og arbeider med dem. Så det jeg tidligere forklarte om å lete etter filer over for en forfattermal, er faktisk litt annerledes hvis et barntema blir brukt. Hvis det gjør det, vil det se ut som:
- finnes filen
author-david.phpi barnetemaet? Nei… - finnes filen
author-david.phpi det overordnede temaet? Nei… - finnes filen
author-3.phpi barnetemaet? Nei… - finnes filen
author-3.phpi det overordnede temaet? Nei… - finnes filen
author.phpi barnetemaet? JA!
Du vil legge merke til at det er flere trinn for å komme så langt inn i malhierarkiet. Du vil også legge merke til at barnetemaet alltid er sjekket først. Dette er en veldig viktig ting om malhierarkiet og barnetemaene – deres filer slår alltid de av en forelder, der malhierarkiet er bekymret.
Hvorfor Du Trenger Å Forstå WordPress Malhierarkiet
Tema uten å ha en god forståelse av malhierarkiet er nesten umulig. Du kan kanskje gjøre det, men det vil føles som forvirrende og mystifiserende magi.
Det vil også hjelpe, hvis du prøver å gjøre det, å vite om noen plugins som gjør malhierarkiet litt klarere: Hvilken Mal Og Vis Gjeldende Mal. Disse gjør begge det samme( som er nyttig hvis du også kjenner malhierarkiet): de forteller deg hvilken malhierarkifil som brukes til å bygge en gitt side. De begge forteller deg faktisk litt mer enn det, men det er deres primære bruk (i hvert fall for meg).
Hvorfor du trenger å vite om malhierarkiet og forstå strukturen—selv Med Hvilken Mal i verktøybeltet—er at du vil bruke den til å » overstyre.»For barn theming, en «overstyring» er like enkelt som å lage en fil med samme navn i barnet ditt tema og kaller det bra. Men når du prøver å være mer spesifikk enn det, må du referere til et diagram over malhierarki. Det er der jeg alltid nå for wphierarchy.com. WordPress.org har et diagram, som gjør Et Google Bildesøk. Men ingenting er raskere å få tilgang fra en inaktiv tilstand enn dette nettstedet.
Hvordan Jobbe Med WordPress Malhierarki
hvis du har lest lineært, tror jeg du allerede har et ganske godt svar på dette spørsmålet. Men dette er internett, og jeg kjenner folk skumme. Du arbeider med malhierarkiet ved å lage et tema. Enten det er et selvbærende tema eller et «barn» som lener seg på en «forelder», er et tema filer fundamentalt hvordan du endrer måten du arbeider med malhierarkiet.
I Utgangspunktet oppretter du filen som samsvarer med hvor i malhierarkiet du prøver å endre måten siden ser ut på. Så hvis DU prøver Å få HTML-EN for en enkelt side til å se annerledes ut, kan du angi en sidemal, eller lage en fil i temaet ditt med innleggets ID rullet inn.
Ingen av disse er perfekte. Men det er fundamentalt hvordan det fungerer.
Hvordan Malhierarkiet Fungerer I WordPress-Koden
» Hvordan Fungerer WordPress-malhierarkiet?»er virkelig et akademisk spørsmål som nesten ingen WordPress-utvikler noensinne trenger svar på. Men, en dag fant jeg meg selv bare tilfeldig lurer, og så jeg så det opp. Denne artikkelen kom ut:
det korte svaret, for de som er interessert i å lese dette, men ikke interessert nok til å klikke, er en haug med ifs og elseifs i php-kode. Ikke mye mer. Det er ikke den mest elegante koden som ligger til grunn for Denne kraftige Og viktige fasetten Av WordPress, men det fungerer bra og gjør det mulig for alle temaene Du noensinne har kjent og elsket I WordPress. Ganske kult!
Videre Lesing på Malhierarkiet
hvis du er ny på noen av konseptene i denne artikkelen, eller bare trenger en oppfriskning, vennligst sjekk ut disse andre artiklene vi har. Først to for nybegynnere:
så, for de som ønsker å dykke dypere og tenke hardere om malhierarkiet og hvordan det fungerer, og hvordan du trenger å jobbe med det:
nå vet du wordpress-malhierarkiet!
Forhåpentligvis med dette under beltet ditt, har du en ganske god følelse Av WordPress-malhierarkiet: At Det Er Måten WordPress samhandler med et tema for å bestemme hvordan man bygger HTML som det vil vise besøkende på nettstedet ditt. Og forhåpentligvis forstår Du også hvorfor WordPress har et malhierarki (for å få temaer til å fungere med det) og hvorfor du vil bruke det (for å tilpasse sidene på nettstedet ditt, via temaet ditt, lettere). Og jeg håper du også vet hvordan du skal samhandle med det: ved å legge til eller slette filene som den samhandler med. Med det, glad hacking!