Alle mulige HTML-elementer skal utformes etter temaet ditt (med mindre det er et barnetema), både i innlegg / sideinnhold og i co innhold.
- Tabeller, bildetekster, bilder, lister, blokkeringstegn osv.
Det anbefales å legge til utskriftsvennlige stiler.
- Du kan inkludere et utskriftsark med media = «print» eller legge til i en utskriftsmedieblokk i hovedformatet.
Funksjonsfil
Et tema kan eventuelt bruke en funksjonsfil, som ligger i underkatalogen for temaet og får navnet functions.php. Denne filen fungerer i utgangspunktet som et plugin, og hvis den er tilstede i temaet du bruker, lastes den automatisk inn under WordPress-initialisering (både for admin-sider og eksterne sider). Foreslåtte bruksområder for denne filen:
- Enqueue theme stylesheets and scripts. Se wp_enqueue_scripts.
- Aktiver temafunksjoner som sidefelt, navigasjonsmenyer, innleggsminiatyrer, innleggsformater, egendefinerte overskrifter, egendefinerte bakgrunner og andre.
- Definer funksjoner som brukes i flere malfiler i tema.
- Sett opp en alternativmeny som gir nettstedseiere muligheter for farger, stiler og andre aspekter av temaet ditt.
Standard WordPress-tema inneholder funksjoner. php-fil som definerer mange av disse funksjonene, så det kan være lurt å bruke den som modell. Siden functions.php i utgangspunktet fungerer som et plugin, er Function_Reference-listen det beste stedet å gå for mer informasjon om hva du kan gjøre med denne filen.
Merk for å bestemme når du skal legge til funksjoner til functions.php eller til et bestemt plugin: Du kan oppdage at du trenger den samme funksjonen for å være tilgjengelig for mer enn ett overordnet tema. Hvis det er tilfelle, bør funksjonen opprettes i et plugin i stedet for en functions.php for det spesifikke temaet. Dette kan inkludere malmerker og andre spesifikke funksjoner. Funksjonene i plugins vil bli sett av alle temaer.
Malfiler
Maler er PHP-kildefiler som brukes til å generere sidene som de besøkende ber om, og sendes ut som HTML. Malfiler består av HTML, PHP og WordPress maletiketter.
La oss se på de forskjellige malene som kan defineres som en del av et tema.
WordPress lar deg definere separate maler for de forskjellige aspektene på nettstedet ditt. Det er ikke imidlertid viktig å ha alle disse forskjellige malfilene for at nettstedet ditt skal fungere fullt ut. Maler velges og genereres basert på malhierarkiet, avhengig av hvilke maler som er tilgjengelige i et bestemt tema.
Som tema utvikler, kan du velge mengden tilpasning du vil implementere ved hjelp av maler. Som et ekstremt tilfelle kan du for eksempel bare bruke en malfil, kalt index.php som mal for alle sider som genereres og vises av nettstedet. mer vanlig er å ha forskjellige malfiler som genererer forskjellige resultater, for å tillate maksimal tilpasning.
Malfiler Liste
Her er listen over temafilene som er gjenkjent av WordPress. Selvfølgelig Temaet ditt kan inneholde andre stilark, bilder eller filer. Bare husk at følgende har spesiell betydning for WordPress – se Malhierarki for mer informasjon.
style.css Hovedformatet. Dette må være inkludert i temaet ditt, og det må inneholde informasjonsoverskriften for temaet ditt. rtl.css rtl-stilarket. Dette inkluderes automatisk hvis nettstedets tekstretning er fra høyre mot venstre. Dette kan genereres ved hjelp av RTLer-plugin. Index.php Hovedmalen. Hvis temaet ditt har sine egne maler, må index.php være til stede. comments.php Kommentarmal front-page.php Forside mal home.php Startsidemal, som er forsiden som standard.Hvis du bruker en statisk forside, er dette malen for siden med de siste innleggene. single.php Malen for enkeltinnlegg. Brukes når et enkelt innlegg blir spurt. For denne og alle andre spørremaler brukes index.php hvis spørsmalen ikke er til stede. single- {post-type} .php Enkeltpostmalen som brukes når det blir spurt om et enkelt innlegg fra en tilpasset innleggstype. For eksempel vil single-book.php brukes til å vise enkeltinnlegg fra den egendefinerte innleggstypen som heter «bok». index.php brukes hvis søkemalen for den tilpassede innleggstypen ikke er tilstede. page.php Sidemalen. Brukes når en individuell side blir spurt. category.php Kategorimalen. Brukes når en kategori blir spurt. tag.php Tagmalen. Brukes når en kode blir spurt. taxonomy.php Begrepet mal. Brukes når det blir spurt om et begrep i en tilpasset taksonomi. author.php Forfattermalen. Brukes når en forfatter blir spurt. date.php Dato / tid-malen. Brukes når det blir spurt om en dato eller et klokkeslett. År, måned, dag, time, minutt, sekund. archive.php Arkivmalen. Brukes når det blir spurt om en kategori, forfatter eller dato. Merk at denne malen blir overstyrt av category.php, author.php og date.php for deres respektive spørretyper. search.php Søkeresultatmalen. Brukes når et søk utføres. attachment.php Vedleggsmal. Brukes når du ser på et enkelt vedlegg. image.php Vedleggsmal for bilde. Brukes når du ser på et enkelt vedlegg. Hvis den ikke er tilstede, vil attachment.php brukes. 404.php 404-ikke-malen. Brukes når WordPress ikke finner et innlegg eller en side som samsvarer med spørringen.
Disse filene har en spesiell betydning med hensyn til WordPress fordi de brukes som erstatning for index.php, når de er tilgjengelige, i henhold til malhierarkiet, og når den korresponderende betingede taggen returnerer true. Hvis for eksempel bare et enkelt innlegg vises, returnerer funksjonen is_single () «true», og hvis det er en single.php-fil i det aktive temaet, brukes den malen til å generere siden.
Grunnleggende maler
I det minste består et WordPress-tema av to filer:
Begge disse filene går inn i temakatalogen. Index.php malfilen er veldig fleksibel. Den kan brukes til å inkludere alle referanser til topptekst, sidefelt, bunntekst, innhold, kategorier, arkiver, søk, feil og hvilken som helst annen side opprettet i WordPress.
Eller den kan deles inn i modulmal filer, hver enkelt tar på seg en del av arbeidsmengden. Hvis du ikke gir andre malfiler, kan WordPress ha standardfiler eller funksjoner for å utføre jobbene sine. Hvis du for eksempel ikke oppgir en searchform.php malfil, har WordPress en standardfunksjon for å vise søkeskjemaet.
Typiske malfiler inkluderer:
- kommentarer. php
- comments-popup.php
- footer.php
- header.php
- sidebar.php
Ved hjelp av disse malfilene kan du plassere malkoder i index.php-hovedfilen for å inkludere disse andre filene der du vil at de skal vises på den endelige genererte siden.
Her er et eksempel på inkluderer bruk:
<?php get_sidebar(); ?><?php get_footer(); ?>
Standardfilene for noen malfunksjoner kan være utfaset eller ikke til stede, og du bør oppgi disse filene i temaet ditt. Fra og med versjon 3.0 ligger de utdaterte standardfilene i wp-includes/theme-compat. For eksempel bør du oppgi header.php for at funksjonen get_header () skal fungere trygt, og comments.php for funksjonen comments_template ().
For mer om hvordan disse forskjellige malene fungerer og hvordan du genererer forskjellige informasjon i dem, les maledokumentasjonen.
Egendefinerte sidemaler
Filene som definerer hver sidemal, finnes i Tema-katalogen. For å opprette en ny tilpasset sidemal for en side må du opprette en fil. La oss kalle vår første sidemal for siden snarfer.php. Øverst i snarfer.php-filen, legg følgende:
<?php/*Template Name: Snarfer*/?>
Ovennevnte kode definerer denne snarfer.php-filen som «Snarfer» -mal. Naturligvis kan «Snarfer» erstattes med mest hvilken som helst tekst for å endre navnet på sidemalen. Dette malnavnet vises i Theme Editor som lenke for å redigere dette fil.
Filen kan bli navngitt nesten hva som helst med en .php-utvidelse (se reservert temafilnavn for filnavn du ikke bør bruke; dette er spesielle filnavn WordPress reserverer for spesifikke formål).
Det som følger med de ovennevnte fem kodelinjene, er opp til deg. Resten av koden du skriver vil kontrollere hvordan sider som bruker Snarfer-sidemalen vises. Se Maletiketter for en beskrivelse av de forskjellige WordPress-malfunksjonene du kan bruke til dette formålet. Det kan være mer praktisk å kopiere en annen mal (kanskje page.php eller index.php) til snarfer.php og deretter legg til de ovennevnte fem linjene med kode til begynnelsen av filen.På den måten trenger du bare å endre HTML og PHP-koden, i stedet for å lage alt fra bunnen av. Eksempler er vist nedenfor. Når du har opprettet en sidemal og plassert den i temaets katalog, vil den være tilgjengelig når du oppretter eller redigerer en side. (Merk: Når du oppretter eller redigerer en side, vises alternativet Sidemal ikke med mindre det er minst en mal definert på ovennevnte måte.)
Spørringsbaserte malfiler
WordPress kan laste inn forskjellige maler for forskjellige spørringstyper. Det er to måter å gjøre dette på: som en del av det innebygde malhierarkiet, og gjennom bruk av betingede koder i sløyfen til en malfil.
For å bruke malhierarkiet, må du i utgangspunktet gi spesielle malfiler, som vil automatisk bli brukt til å overstyre index.php. Hvis temaet ditt for eksempel inneholder en mal kalt category.php og det blir spurt om en kategori, vil category.php lastes inn i stedet for index.php. Hvis category.php ikke er tilstede, index.php brukes som vanlig.
Du kan bli enda mer spesifikk i malhierarkiet ved å tilby af ile heter for eksempel kategori-6.php – denne filen vil bli brukt i stedet for category.php når du genererer siden for kategorien hvis ID-nummer er 6. (Du kan finne kategori-ID-numre i Administrer > Kategorier hvis du er logget inn som nettstedsadministrator i WordPress versjon 2.3 og senere. I WordPress 2.5 ble ID-kolonnen fjernet fra administratorpanelene. Du kan finne kategori-ID-en ved å klikke på «Rediger kategori» og se på URL-adresselinjen for cat_ID-verdien. Det vil se «… categories.php? Action = edit & cat_ID = 3» hvor «3» er kategorien id). For en mer detaljert titt på hvordan denne prosessen fungerer, se Kategorimaler.
Hvis temaet ditt trenger å ha enda mer kontroll over hvilke malfiler som brukes enn det som er gitt i malhierarkiet, kan du bruke Betinget Merker. Betinget tag sjekker i utgangspunktet for å se om en bestemt tilstand er sant, i WordPress Loop, og så kan du laste inn en bestemt mal, eller legge en bestemt tekst på skjermen, basert på den tilstanden.
For for eksempel, for å generere et særegent stilark i et innlegg som bare finnes i en bestemt kategori, kan koden se slik ut:
Eller ved å bruke et spørsmål kan det se slik ut:
<?php$post = $wp_query->post;if ( in_category( "9" ) ) { get_template_part( "single2" );} else { get_template_part( "single1" );}?>
I begge tilfeller vil denne eksempelkoden føre til at forskjellige maler brukes, avhengig av kategorien til det aktuelle innlegget som vises. Forespørselsbetingelser er ikke begrenset til kategorier, men se artikkelen om betingede merker for å se på alle alternativene.
Definere egendefinerte maler
Det er mulig å bruke WordPress-pluginsystemet til å definere tilleggsmaler som vises basert på dine egne tilpassede kriterier. Denne avanserte funksjonen kan oppnås ved å bruke handlingshaken «template_include». Mer informasjon om å lage plugins finner du i Plugin API referansen.
Inkludert malfiler
Slik laster du inn en annen mal (annet enn topptekst, sidefelt, bunntekst, som har forhåndsdefinerte inkluderte kommandoer som get_header ()) i en mal, kan du bruke get_template_part (). Dette gjør det enkelt for et tema å gjenbruke deler av koden.
Henvise til filer fra en mal
Når du refererer til andre filer innen samme tema, må du unngå hardkodede URI-er og filstier. I stedet refererer du til URI-ene og filbanene med bloginfo (): se Henvise til filer fra en mal.
Merk at URI-er som brukes i stilarket er relativt til stilarket, ikke siden som refererer til stilarket. Hvis du for eksempel inkluderer en bilder / katalog i temaet ditt, trenger du bare å spesifisere denne relative katalogen i CSS, slik:
h1 { background-image: url(images/my-background.jpg);}
Plugin API Hooks
Når du utvikler temaer, er det greit å huske på at temaet ditt skal settes opp slik at det kan fungere bra med alle WordPress-plugins som brukere kan bestemme seg for å installere. Plugins legger til funksjonalitet til WordPress via «Handling Hooks «(se Plugin API for mer informasjon).
De fleste Action Hooks ligger innenfor kjerne PHP-koden til WordPress, så temaet ditt trenger ikke å ha noen spesielle koder for at de skal fungere. Men noen få handlinger Kroker må være til stede i temaet ditt, for at Plugins skal kunne vise informasjon direkte i topptekst, bunntekst, sidefelt eller i sidetekst. Her er en liste over de spesielle koder for Action Hook-mal du må inkludere:
wp_enqueue_scripts Brukes i temafunksjonsfilen. Brukes til å laste inn eksterne skript og stilark. wp_head () Går i < hodet > element i et tema, i header.php. Eksempel på bruk av plugin: legg til JavaScript-kode. wp_footer () Går i footer.php, rett før den avsluttende < / body > -taggen. Eksempel på bruk av plugin: sett inn PHP-kode som må kjøres etter alt annet, nederst i bunnteksten.Svært ofte brukt til å sette inn webstatistikkode, for eksempel Google Analytics. wp_meta () Går vanligvis i < li > Meta < / li > delen av et temas meny eller sidefelt; sidebar.php-mal. Eksempel på bruk av plugin: inkluderer en roterende annonse eller en taggsky. Comment_form () Går i comments.php rett før filen » s lukkemerke (< / div >). Eksempel på plugin-bruk: vis en forhåndsvisning av en kommentar.
For et eksempel på virkelig bruk, vil du finne disse plugin-krokene som er inkludert i standardtemaens maler.
Theme Customization API
Fra og med WordPress 3.4, en ny Theme Customization-funksjonen er tilgjengelig som standard for nesten alle WordPress-temaer. Tema-tilpasningsadministrasjonssiden er automatisk fylt med alternativer som et tema erklærer støtte for med add_theme_support () eller ved hjelp av innstillings-API, og lar administratorer se ikke-permanente forhåndsvisning av endringer de gjør i sanntid.
Tema- og plugin-utviklere som er interessert i å legge til nye alternativer til temaets tema-tilpasningsside, bør se dokumentasjonen på Theme Customization API. Ytterligere veiledninger om Theme Customization API er tilgjengelige på Ottopress.com-nettstedet.
Ikke-klarerte data
Du bør unnslippe dynamisk generert innhold i temaet ditt, spesielt innhold som sendes ut til HTML-attributter. Som nevnt i WordPress kodingsstandarder, bør tekst som går inn i attributter kjøres gjennom esc_attr () slik at enkelt eller doble anførselstegn avslutter ikke attributtverdien og ugyldiggjør XHTML og forårsaker et sikkerhetsproblem. Vanlige steder å sjekke er tittel-, alt- og verdiattributter.
Det er få spesielle malmerker for vanlige tilfeller hvor en sikker utgang er nødvendig. Et slikt tilfelle innebærer å legge ut et innleggstitel til et tittelattributt ved å bruke_title_attribute () i stedet for_title () for å unngå et sikkerhetsproblem. Her er et eksempel på korrekt rømming for tittelattributtet til en innleggstittellink når du bruker oversettbar tekst:
<a href="<?php the_permalink(); ?>" title="<?php sprintf( __( "Permanent Link to %s", "theme-name" ), the_title_attribute( "echo=0" ) ); ?>"><?php the_title(); ?></a>
Oversettelsesstøtte / I18n
For å sikre en jevn overgang for språklokalisering, bruk de WordPress gettext-baserte i18n-funksjonene for å pakke inn all oversettbar tekst i malfilene. Dette gjør det lettere for oversettelsesfilene å koble til og oversette etiketter, titler og annen maltekst til nettstedets nåværende språk. Se mer på WordPress Localization og I18n for WordPress-utviklere.
Temaklasser
Implementer følgende maletiketter for å legge til WordPress-genererte klasseattributter til kropps-, innleggs- og kommentarelementer. For innleggsklasser gjelder bare elementer i The Loop.
- body_class ()
- post_class ()
- comment_class ()
Sjekkliste for malfiler
Når du utvikler et tema, må du sjekke malfilene dine mot følgende malfilstandarder.
Dokumenthode (header.php)
- Bruk riktig DOKTYPE.
- < html > -tag skal inneholde språkattributter (
- < meta > tegnsettelementet skal plasseres før alt annet, inkludert < title > element.
- Bruk bloginfo () til å angi < meta > tegnsett og beskrivelseselementer.
- Bruk wp_title () til å angi < tittel > element. Se hvorfor.
- Bruk automatiske feedlenker for å legge til feedlenker.
- Legg til et anrop til wp_head () før det avsluttende < / head > -tag. Plugins bruker denne handlingskroken for å legge til sine egne skript, stilark og annen funksjonalitet.
- Ikke lenke temastilarkene i topptekstmalen. Bruk handlingen hook wp_enqueue_scripts i en temafunksjon i stedet.
Her er et eksempel på et korrekt formatert HTML5-kompatibelt hodeområde:
Navigasjonsmenyer (header.php )
- Temaets hovednavigasjon skal støtte en tilpasset meny med wp_nav_menu ().
- Menyene skal støtte lange lenketitler og en stor mengde listeelementer. Disse elementene skal ikke bryte designet eller utformingen.
- Undermenyelementene skal vises riktig. Hvis det er mulig, støtter du rullegardinmenystiler for undermenyelementer. Nedrullinger som viser menydybde i stedet for bare å vise toppnivået.
- Temaet bør widgetiseres så fullt som mulig. Ethvert område i oppsettet som fungerer som en widget (tag sky, blogroll, liste over kategorier) eller som kan godta widgets (sidefelt), bør tillate widgets.
- Innhold som vises i widgetiserte områder som standard (hardkodet inn i sidefeltet, for eksempel) skal forsvinne når widgets er aktivert fra Utseende > Widgets.
Bunntekst (bunntekst.php)
- Bruk wp_footer () -anropet for å vises rett før du lukker kroppskoden.
<?php wp_footer();
read more