Språk: বাংলা • Engelsk • Español • 日本語 한국어 • Português do Brasil • Русский • 中文 (简体) •中文 (繁體) • (Legg til språket ditt)

Denne artikkelen handler om å utvikle WordPress-temaer. Hvis du ønsker å lære mer om hvordan du installerer og bruker temaer, kan du gå gjennom Bruke temaer. Dette emnet skiller seg fra å bruke temaer fordi den diskuterer de tekniske aspektene ved å skrive kode for å lage dine egne temaer i stedet for hvordan du aktiverer temaer eller hvor du skal få tak i nye temaer.

Hvorfor WordPress-temaer

WordPress-temaer er filer som fungerer sammen for å skape utformingen og funksjonaliteten til et WordPress-nettsted. Hvert tema kan være forskjellig, og det gir mange valg for nettstedseiere å umiddelbart endre utseendet på nettstedet.

Det kan være lurt å utvikle WordPress-temaer for eget bruk, for et klientprosjekt eller å sende til WordPress Theme Directory. Hvorfor ellers bør du bygge et WordPress-tema?

• For å skape et unikt utseende for ditt WordPress-nettsted.
• Å dra nytte av maler, maletiketter og WordPress Loop for å generere forskjellige nettstedsresultater og utseende.
• Å tilby alternative maler for spesifikke nettstedsfunksjoner, for eksempel som kategorisider og søkeresultatsider.
• For å raskt bytte mellom to nettstedsoppsett, eller for å dra nytte av et tema- eller stilomskifter for å tillate nettstedseiere å endre utseendet på nettstedet ditt.

Et WordPress-tema har også mange fordeler.

• Det skiller presentasjonsstiler og malfiler fra systemfilene, slik at nettstedet oppgraderes uten drastiske endringer i den visuelle presentasjonen av nettstedet.
• Det muliggjør tilpasning av nettstedsfunksjonaliteten som er unik for det temaet.
• Det muliggjør raske endringer av den visuelle utformingen og utformingen av et WordPress-nettsted.
• Det fjerner behovet for at en typisk WordPress-nettstedseier må lære CSS, HTML og PHP for å ha et flott nettsted.

Hvorfor skal du lage ditt eget WordPress-tema? Det er det virkelige spørsmålet.

• Det er en mulighet til å lære mer om CSS, HTML og PHP.
• Det er en mulighet til å sette din kompetanse med CSS, HTML og PHP fungerer.
• Det er kreativt.
• Det er morsomt (mesteparten av tiden).
• Hvis du slipper det for publikum, kan du føle deg bra at du delte og ga noe tilbake til WordPress-fellesskapet (ok, skryterettigheter)

Standarder for temautvikling

WordPress-temaer bør være kodet med følgende standarder:

• Bruk godt strukturert, feilfri PHP og gyldig HTML. Se WordPress-kodingsstandarder.
• Bruk ren, gyldig CSS. Se CSS-koding Standarder.
• Følg designretningslinjene i Site Design and Layout.

Anatomy of a Theme

WordPress-temaer lever i underkataloger til WordPress-temakatalogen (wp-innhold / temaer / som standard) som ikke kan flyttes direkte ved hjelp av wp-config.php-filen. Temaets underkatalog inneholder alle stilene til temaet eet filer, malfiler og valgfri funksjonsfil (functions.php), JavaScript-filer og bilder. For eksempel vil et tema som heter «test» befinne seg i katalogen wp-content / themes / test /. Unngå å bruke tall for temanavnet, da dette forhindrer at det vises i listen over tilgjengelige temaer.

WordPress inkluderer et standardtema i hver nye installasjon. Undersøk filene i standardtemaet nøye for å få et bedre inntrykk av hvordan du bygger dine egne temafiler.

For en visuell guide, se denne infografikken på WordPress Theme Anatomy.

WordPress Temaer består vanligvis av tre hovedtyper av filer, i tillegg til bilder og JavaScript-filer.

1. Stilarket kalt style.css, som styrer presentasjonen (visuelt design og layout) av nettsidene.
2. WordPress-malfiler som styrer måten nettstedssidene genererer informasjonen fra WordPress-databasen din som skal vises på nettstedet.
3. Den valgfrie funksjonsfilen (functions.php) som en del av WordPress Theme-filer.

La oss se på disse individuelt.

Barnetemaer

Det enkleste temaet som er mulig er et barnetema som bare inneholder en style.css fil, pluss eventuelle bilder. Dette er mulig fordi det er et barn av et annet tema som fungerer som foreldre.

For en detaljert guide til barnetemaer, se Barnetemaer.

Tema Stilark

I tillegg til CSS stilinformasjon for temaet ditt, gir style.css detaljer om temaet i form av kommentarer. Stilarket må gi detaljer om temaet i form av kommentarer. Ingen to temaer er lov til å ha de samme detaljene oppført i kommentaroverskriftene, da dette vil føre til problemer i dialogboksen Temavalg. Hvis du lager ditt eget tema ved å kopiere et eksisterende, må du først endre denne informasjonen.

Følgende er et eksempel på de første linjene i stilarket, kalt stilarkhode, for temaet «tjue tretten»:

NB: Navnet som brukes til forfatteren er antydet å være det samme som Theme Author «s wordpress.org brukernavn, selv om det også kan være forfatterens virkelige navn. Valget er temaforfatteren.

Legg merke til listen over koder som brukes til å beskrive temaet. Disse lar brukeren finne temaet ditt ved hjelp av tagfilteret. Du finner en fullstendig liste i Theme Review Handbook .

Kommentaroverskriftslinjene i style.css kreves for at WordPress skal kunne identifisere temaet og vise det i administrasjonspanelet under Design > Temaer som et tilgjengelig temaalternativ sammen med andre installerte temaer.

Retningslinjer for stilark

• Følg CSS-kodingsstandarder når du oppretter CSS.
• Bruk gyldig CSS når mulig. Som et unntak, bruk leverandørspesifikke prefikser for å dra nytte av CSS3-funksjoner.
• Minimer CSS-hacks. Det åpenbare unntaket er nettleserspesifikk støtte, vanligvis versjoner av IE. Hvis mulig, skille CSS-hacks inn i separate seksjoner eller separate filer.
• 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:

• style.css
• index.php

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(); ?></body></html>

Indeks (index.php)

• Vis en liste over innlegg i utdrag eller i full lengde. Velg den ene eller den andre etter behov.
• Inkluder wp_link_pages () for å støtte navigasjonskoblinger i innlegg.

Arkiv (archive.php)

• Vis arkivtittel (tag, kategori, datobasert eller forfatterarkiv).
• Vis en liste over innlegg i utdrag eller i full lengde. Velg den ene eller den andre etter behov.
• Inkluder wp_link_pages () for å støtte navigasjonskoblinger i innlegg.

Sider (page.php)

• Vis sidetittel og sideinnhold.
• Vis kommentarliste og kommentarskjema (med mindre kommentarer er av).
• Inkluder wp_link_pages () for å støtte navigasjonskoblinger på en side.
• Metadata som koder, kategorier, dato og forfatter skal ikke vises.
• Vis en «Rediger» -lenke for påloggede brukere med redigeringstillatelser.

Enkelt innlegg (single.php)

• Inkluder wp_link_pages () for å støtte navigasjonskoblinger i et innlegg.
• Vis innleggstittel og innhold.
  • Tittelen skal være ren tekst i stedet for en lenke som peker mot seg selv.
• Vis innleggsdatoen.
  • Respekter innstillingene for dato og klokkeslettformat med mindre det er viktig for designet. (Brukerinnstillinger for dato- og tidsformat er i administrasjonspaneler > Innstillinger Generelt).
  • For utdata basert på brukerinnstillingen, bruk_time (get_option («date_format»)).
• Vis forfatternavnet (hvis aktuelt).
• Vis innleggskategorier og innleggskoder.
• Vis en «Rediger» -lenke for påloggede brukere med redigeringstillatelser.
• Vis kommentarliste og kommentarskjema.
• Vis navigeringskoblinger til neste og forrige innlegg ved hjelp av forrige_post_link () og neste_post_link ().

• Forfatterkommentar bør fremheves annerledes.
• Vis gravatarer (brukeravatarer) hvis det er aktuelt.
• Støtter kommentarer med tråd.
• Vis trackbacks / pingbacks.
• Denne filen skal ikke inneholde funksjonsdefinisjoner med mindre i avkrysningsfunksjonen () for å unngå redeklarasjonsfeil. Ideelt sett bør alle funksjonene være i functions.php.

Søkeresultater (search.php)

JavaScript

• JavaScript-kode skal være plassert i eksterne filer når det er mulig.
• Bruk wp_enqueue_script () for å laste skriptene dine.
• JavaScript lastet direkte inn i HTML-dokumenter (malfiler) skal være CDATA-kodet for å forhindre feil i eldre nettlesere. .

<script type="text/javascript">/* <!]> */</script>

Skjermbilde

Lag et skjermbilde for temaet ditt. Skjermbildet skal hete screenshot.png, og skal plasseres i toppnivåkatalogen. Skjermbildet skal vise temaets design nøyaktig og lagres i PNG-format. Mens .jpg, .jpeg og .gif også er gyldige utvidelser og filformater for skjermbildet, anbefales de ikke.

Den anbefalte bildestørrelsen er 1200 px bred og 900 px høy. Skjermbildet vil vanligvis vises mindre, men det store bildet tillater visning med høy oppløsning på HiDPI-skjermer. Merk at fordi skjermbildet Administrer temaer er responsivt, kan det hende at toppen og bunnen av skjermbildet ikke kan vises, så hold grafikk nær sentrum.

Temaalternativer

Temaer kan valgfritt støtte Tema Tilpass skjerm. For eksempel på en kode, se En eksempel på WordPress-temaalternativside.

Når du aktiverer tilgjengeligheten av temaet Tilpass skjerm for en brukerrolle, bruker du «edit_theme_options» brukerfunksjonen i stedet for «switch_themes» -funksjonen med mindre brukerrollen burde faktisk også kunne bytte tema. Se mer på Roller og evner og legge til administrasjonsmenyer.

Hvis du bruker «edit_themes» -funksjonen hvor som helst i temaet ditt for å få administratorrolletilgang til temaet Tilpass skjerm (eller kanskje noen tilpassede skjermer), Vær oppmerksom på at siden denne versjonen 3.0 ikke har blitt tildelt administratorrollen som standard i tilfelle WordPress Multisite-installasjon. Se forklaringen. I et slikt tilfelle bruker du «edit_theme_options» -funksjonen i stedet hvis du vil at administratoren skal se menyen «Theme Options». Se tilleggsegenskapene til administratorrollen når du bruker WordPress Multisite.

Testing av temaer

1. Løs PHP- og WordPress-feil. Legg til følgende feilsøkingsinnstilling i wp-config.php-filen for å se utdaterte funksjonsanrop og andre WordPress-relaterte feil: definere («WP_DEBUG», sant) ;. Se avviklede funksjoner Hook for mer informasjon.
2. Sjekk malfiler mot sjekklisten for malfiler (se ovenfor).
3. Gjør en gjennomkjøring ved hjelp av temeenhetstesten.
4. Valider HTML og CSS. Se Validering av et nettsted.
5. Se etter JavaScript-feil.
6. Test i alle målleserne. For eksempel IE9, Safari, Chrome, Opera, Firefox og Microsoft Edge.
7. Rydd opp i eventuelle kommentarer, feilsøkingsinnstillinger eller TODO-elementer.
8. Se Theme Review hvis du er offentlig slippe temaet ved å sende det til temakatalogen.

Ressurser og referanser

Kodestandarder

• Kjenn dine kilder
• WordPress-kodingsstandarder
• CSS-kodingsstandarder

Temadesign

• Nettstedsdesign og layout

CSS

• CSS
• CSS Shorthand
• WordPress-genererte klasser

Maler

• Å gå inn i maler
• Maler
• Malhierarki
• Maletiketter
• The Loop
• Betingede koder
• Funksjonsreferanse
• I18n for WordPress-utviklere
• Datavalidering

Funksjonsliste

• Funksjonsreferanse

Testing og QA

• Temaenhet Te st
• Validering av et nettsted
• CSS Fixing Browser Bugs
• CSS Feilsøking
• modern.IE: for testing av IE på forskjellige plattformer med åpen -kildeverktøy

Slipp & Kampanje

• Gjennomgangsprosess for tema